Workaround for encoding issues

[Surerocks]

Since this encoding issue is proving to be challenging to fix, I was thinking of some other ways we could get around it. We originally decided to do the nfc auth value the way we are currently doing it because it seemed like a quick and easy solution, and it is not quick or easy anymore.

My thought is that we could have the nfc value be a generated string of numbers and characters, that way the encoding shouldn't give us the same problems. However, this value will need to be generated and stored a bit differently to keep it secure. I think it would work like this:

When the App logs in, it will also generate this string to be the nfc password. It will then use PUT or POST to either create or update the appropriate nfc authenticator on the server. Then it can send that nfc password to the pi, and it should all work nicely.

The extra work with this would be in doing the PUT/POST to update the value, since it will require two separate calls to the server (one to check if there is an existing nfc authenticator, one to set it).

I think this solution has benefits overall, since the nfc value is not as susceptible to attacks, but it also requires more calls to the server on each login. What do you guys think about this?

[richardperryman]

I think it is a good idea to try this out if we are still stuck after the weekend. But I think the problem may remain, as the only real difference is the character restriction. While that may solve all of our problems, we still will basically have all the same steps, and we still don't really know what's going on between some of them.

Anyway right now I think the problem was that the NFC shield wasn't sending the message after it got it from the card. This will obviously bottleneck both approaches, so I think we need to get that fixed first.

[jessicamorris]

And NFC is back to working again! I'm not entirely sure what part of the logic was locking up before, but after doing some long-overdue refactoring, it's working fine again. I'm going to try to find ways to break it before I push.

I rather like this idea because it means that a user's lock won't even have a key existing unless they have a session running. So the only way an attacker could fudge their way into the lock is to get the user's credentials; brute-forcing will only (possibly) work if the user has a session going.

[richardperryman]

Just as a note, the current system should also have the same protection against brute forcing. The server would only make keys when you make a session, and they will time out similarly. The only real differences are that the phone makes the key and that the characters are restricted. (Unless I'm missing something)

[Surerocks]

In the current system, the key does not ever time out on the server side for the nfc value, but you will need to be logged in to access the value (or have somehow gotten past the authentication). But if the server is compromised and someone can access it completely, currently they would be able to open any lock that is only secured by nfc if they know where to look.

In terms of brute-forcing alone, I agree with Richard and don't think it provides any major difference.