Improve Basic Identity Validation
Posted 29 March 2013 - 08:55 AM
I'm currently looking at the default IUserIdentity implementation CUserIdentity, which operates on a username/ password base. Since the framework ships with no alternative implementations and the class is used by the skeleton app generated by yiic, I bet a lot of people stick with that approach.
"THE DEFINITIVE GUIDE TO YII" already talks about the problem with plain text passwords and why it is a bad idea to save them to DB. But why not take this a step further and discourage devs to send plain text passwords over the net in the first place?
Instead of using a username/password based identity default implementation, yii2 could encourage the use of a username/password-hash based default implementation. It might be a bit problematic to turn the password entered by the user into his browser into a hash before sending it. Seems like this required a client side script (would have been better if there was a standard embedded in the browsers, but I couldn't find anything). And of course, relying on scripts in turn means there needs to be a fallback to plain text passwords in case the user disabled scripts. So a second identity implementation like the current CUserIdentity would be needed as well. But at least this one wouldn't be used as the default then.
Of course, this would make it more complicated to understand how yii's authentication flow works. I'm not sure what is more important: Making it easy for yii beginners to become comfortable with the framework or adding a bit of default security. One could argue that yii as a framework only provides the infrastructure to implement whatever one needs (including auth mechanisms). But on the other hand, setting a good example wouldn't hurt, would it?
Posted 29 March 2013 - 09:21 AM
Without using SSL, even if you do the password hash as you suggested above, users still have the danger of having his session cookie being intercepted.
Posted 29 March 2013 - 09:30 AM
I agree with this.
I think that this approach makes the authentication harder to understand for newcomers, but since the generator will have multiple application templates, it could be enabled for all but the most basic one.
EDIT: I was talking above about saving the hashed/salted passwords on the database, not hashing them on the client. I agree with ekerazha, the right way to solve this problem is with SSL.
This post has been edited by Rodrigo Coelho: 30 March 2013 - 05:47 AM
Check my extension
giix: a code generator for Yii.
The complete beginner's study guide for the Yii Framework
Posted 29 March 2013 - 09:45 AM
Besides the session id, all other data in cookies can be encrypted, right?
Posted 29 March 2013 - 11:11 AM
Reading through the digest specification, I wonder what remains if we reduce it to a login aproach. A lot of the spec seems to address replay attacks. Since we authenticate only once, not every request, it might really shrink down to the nonce...
Posted 30 March 2013 - 05:10 AM
Today, the de facto standard for password hashing with PHP is crypt() http://php.net/manua...ction.crypt.php with CRYPT_BLOWFISH.
Instead of trying to reinvent the wheel, if you really care about MITM attacks you should use a SSL certificate. You can buy COMODO PositiveSSL certificates for less than 8 dollars/year. If you don't use things like HTTPS, it's obvious that network traffic isn't protected, that is why HTTPS exists. Moreover, if users use the same password on every site it's their fault (and their password could be stolen from another unprotected website).
Posted 30 March 2013 - 10:07 AM
And this is all I'm talking about. I certainly make no claims that sending hashed passwords for login is as secure as using SSL. And I don't try to reinvent anything. In fact, these are two reasons why I mentioned HTTP digest auth. It has been written down, because people realized that sending plain text passwords is a bad idea. Still, it does not claim to be a secure solution compared to other authentication mechanisms like kerberos . The issues it addresses and its limitations are clearly written down.
Besides that, I think using password hashes instead of plain text passwords is an enhancement, even if using SSL. I've seen too much poorly written code - sometimes bugs, other times design flaws - that simply exposed a users password, for example in log files. If those systems used an authentication mechanism which wouldn't have made the users password available in first place, such things couldn't have happened.
Some more thoughts about digest auth:
- I read it back and forth yesterday and have to admit that I don't understand it completely. Sometimes they just seem to do too much hashing and I couldn't figure out for what reason.
- The whole concept can't be adopted 1:1, because it handles another scope. HTTP auth authenticates every request, we only want a user to authenticate himself once. So a lot of stuff like using request methods, accessed resources or nonce counters as part of the digest don't seem to make sense in our use case.
- Another thing we don't need imo is the support of realms .
- Using the MD5 algorithm as done throughout the RFC is probably nothing I would recommend. Even from the RFC point of view, it only acts as a default and can be replaced with any other algorithm .
- Despite the last point, wikipedia claims that digest auth "prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable)"  - need to elaborate on that.
- There is a js crypto library from the Stanford Computer Security Lab . Does anyone know details about it? How good or bad it is, if there are better alternatives?
Posted 30 March 2013 - 12:39 PM
But you are not going to use the built-in HTTP digest auth (which has many limitation), are you?
Posted 30 March 2013 - 01:23 PM
Even if you require your users to send a password (plaintext, encrypted, ...) during authentication, this is still not as dangerous as requiring them to send it over and over again every time they log in. Registration is a one time process and if you want to close that gap, there are possibilities. However, that is another story, I'm talking about authentication.
One interesting thing I've found is SRP . Sadly, I couldn't find any production level libraries one could use.