Yii2 Password Encryption(For Sending Through The Network)

Yii 2.0 General Discussions
1

Hi,

I am developing a yii2 website that also has a connected mobile app. I would like to know what is the recommended way in the client side, both the mobile and the web page to send the password during authentication? Obviously sending clear text is not a recommended way, so I would like to know what’s the standard ways of doing it.

  1. In the login form when the user login’s with a plain password, do we encrypt and send it? if so what is the encyption standard that we should use?

  2. In the mobile(IOS and Android), what encryption standard’s they should use in the REST Api? (Im using yii2 REST API framework)

2

Use HTTPS.

3

Send and store hash, not plain password. And of course, HTTPS.

4

Thanks bis. The password is stored in the server using bcrypt and not in plain text. My question was whether we should be using the same bcrypt in the view form to encrypt the password and also in mobile?

And in Yii2 the password is hashed using a random generated number as salt and if we use the same encyption in mobile we have to change the encryption login in the web site to use a fixed salt. Just wanted to know what the standard is? (assuming we use HTTPS)

5

Then you would make the bcrypt hash a common secret. Not a good idea.

Why would you have to or even want to use a fixed salt? The dynamic salt should be unique to a hashed password, thus making attacks via rainbow tables unfeasible. Yii 2 (and Yii 1.1 since v1.1.14 as well) are implementing bcrypt correctly, which is a widely acknowledges standard. If you want something more secure, look out for scrypt.

For your innitial problem: You’ll have to transmit the users password unencrypted but over a secure channel at least once, so your app can store it via bcrypt. The only alternative were a solution involving SSL client certificates. Either way, ensure your webserver is properly configured for HTTPS. This online test should help you with that.

6

No, the idea is you send some hash (nothing sophisticated, just something that could not be easily cracked with md5/sha1 dictionaries) from signup/signin form (just to be sure that user’s precious master password won’t leak even if you say goodbye to SSL when you’re on a tight budget) and then cook it with salted bcrypt on the server side.

Overkill, you say, I answer, ‘Heartbleed’.