Question

I’m implementing a login mechanism for a mobile device using bcrypt and AES. The user will have to login using a password, which will then be hashed with bcrypt and compared to the hash in the database. The login transaction will, of course, take place over SSL, and the server will be configured to only serve SSL. That part is pretty straightforward.

However, I will also want to store a cookie so the user does not have to log in each time. The cookie will be automatically deleted from the device after 24 hours. I was planning on storing an AES encrypted string comprised of a date-time stamp and the bcrypt hash. The AES implementation is where I’m having difficulty. I was planning on using Encryptamajig , which is “a simple wrapper to the .NET AES encryption algorithm functionality,” but then I saw this issue posted on it which has not yet been fixed. (The issue has to do with using the same derivation function to generate the IV as the key).

My question is, is this a huge issue that should prevent me from using this wrapper?
(my cryptography knowledge is increasing, but still relatively low; however, if I understand correctly, this is close to the same issue that makes WEP so easy to crack)

If it is, is there a best/better practice for using .Net’s AES Class? It seems that most of the answers currently on SO are older, and don’t deal with the AES class at all.

Answer 1

IMO the cookie should be a random token stored in a autologin table in the database. Then you can invalidate those tokens without changing the user’s password.

When using AES on .net, I’d use one of the built in classes, either Rijndael with a block-size of 128 or Aes. I’d only use other implementations, if I need the additional speed(The build in crypto classes are often slow).