1

i'd like some opinions about the flow i'm building for any mobile application that needs to send a combination of user and password. My idea is to encrypt the password using AES-256, generating a random passphrase and IV to generate the key. The idea is that when the password is first generated, it send to the server the encrypted password, and the IV. the IV and encrypted password will be stored at server, in a redis DB and the key, and the encrypted password, will be on the mobile device only (the IV will not be stored on the device). So each time the user needs to login, sends the to the server, the encrypted password and the key, with the IV stored, the server decrypt both encrypted password sent and the one saved in the DB, using the key just sent and the IV already on server.

In case the user wants to change their password, encrypted password, key and IV is generated again and is sent the old one too (key and encrypted password) if they match, the values are updated in server and send a notification to the client to update them too.

All of this transactions will take place inside a SSL tunneling too.

Do you think this is secure? if not why? any other option to encrypt/decrypt passwords in a secure way from a mobile device to a server?

Regards.

shadow_of__soul
  • 429
  • 1
  • 8
  • 19
  • why do you need to store the encrypted password? what's wrong with storing a hash? – Eric Feb 14 '13 at 19:42
  • you mean use blowfish? why sha1 is not secure as far i know – shadow_of__soul Feb 14 '13 at 19:53
  • what? both blowfish and sha1 are hashing algorithms, not encryption ciphers. I would recommend using pbkdf-2, bcrypt or scrypt to store a password hash instead of storing an encrypted password. – Eric Feb 14 '13 at 20:07
  • so i just send the hash of password to the server and compare it with the one saved in the DB? – shadow_of__soul Feb 14 '13 at 20:08
  • you are right, i'm overthinking this stuff, and even there is no need to hash the password in the device as [this](http://stackoverflow.com/questions/7626914/using-jbcrypt-to-salt-passwords-in-android-app-causes-a-long-hang) question say, even having a SSL in the middle, is better to send the password in plain text and hash it in the server to compare it with the hash already stored. – shadow_of__soul Feb 14 '13 at 20:20
  • gonna post as an answer because my answer is too long for this – Eric Feb 14 '13 at 20:28
  • "blowfish" is an encryption algorithm, not a hash. – zaph Feb 17 '13 at 21:52

1 Answers1

0

The best way to do it would be to do a hash of the password on the client side before sending the data and send the hash. Then have the server do it's own hashing on that hash so that the password never has to leave the client and the plain text password can not be derived from bruteforcing the stored hash.

The KDFs (pbkdf2, scrypt, bcrypt) that i listed before are time consuming so you probably don't want to do it on the client and then on the server unless security is more important than normal. A KDF is used to prevent someone from bruteforcing the password from the hash. This means that if your table storing the users hashes are compromised, the plain text of your users password is still safe. If for example, you do the KDF on the client and say a simple salted MD5 of the KDF produced hash on the server, then the users plain text password will be safe but it may be easy for someone who was able to get access to the stored hash (meaning the server is compromised) to log in as that user. If your site/app is stackoverflow it may not matter if a user account gets compromised if the server itself is already compromised. On the other hand if you're paypal, someone who gets access to an account can get access to the users bank account which they would not be able to do simply by gaining access to the hash table. In this case doing a KDF on both client and server would be optimal.

As for using SSL, that's good if you have a method of verifying that the server is actually your server and there is no MITM going on. If either of those are compromised, then sending the password in plain text will allow an attacker to gain access to the plain text password

Eric
  • 2,056
  • 13
  • 11
  • Thanks for the detailed answer, hashing it 2 times would be the best (even if is consuming, i will save the hash so i just do it once). My apps are not paypal, but i take the user credential security very serious, and i want to avoid if this ever get compromised in some way (trying to take every precaution i can, but like everyone knows, there is no system that is 100% secure), the attacker would be able to get the password not used in my site, but used by the user in other places (something that usually happens) – shadow_of__soul Feb 14 '13 at 20:50
  • Yeah, that's the main concern with most sites is that you don't want to let the attacker get the plain text version of the password which is what those key derivation functions (KDF) prevent. Not sure if you followed the all of the security breaches of sites last year, but they were all storing passwords in either plain text or a simple hashing algorithm that could be easily bruteforced. As long as you're using a KDF somewhere, your users will still be safe even if your password hashing table gets stolen. – Eric Feb 14 '13 at 20:56