Password Hash explanation and Username case-sensitivity #35
Conversation
|
I was heavily downvoted once on Stack Overflow by providing a PHP 5.4 way to emulate (or cook) password_hash() using crypt(), manually setting the blowfish, as well as salt's prefix and suffix. At least I earned the "peer pressure" badge. |
|
@amenadiel couldn't imagine why you would geht downvoted on that. Crypt() is the legit predecessor of password_hash() which should geht used before PHP 5.5 (although there are a few drawbacks to crypt ). Nevertheless I only mentioned crypt() because many password hash generators on the Internet don't provide support for password_hash() but for crypt(). BTW you are able to use other hash algorithms than blowfish with password_verify(). That's the reason you have to provide the used hashing algorithm in the hash. |
|
I will pull the change for the comment about
I do have a service (mostly for myself) which does that, but didn't include a link to in the file because using a service from random guy x on the web to generate password hashes is... scary :-) About the case insensitivity of the username I am willing to pull that one if everyone agrees that is what should happen. |
|
I guess if you're using opCache you're using PHP 5.5, so you ought to have password_hash. |
|
@PeeHaa I plead guilty, I have never read the install instructions :D You should add them as an "INSTALL" file to the repository. This way nobody has to search for the instructions here. @amenadiel it is very common for amateur administrators to generate password hashes on websites like @PeeHaa 's (although it isn't recommended of course). Therefore we can not assume the respective webservice uses PHP 5.5 or supports the usage of password_hash(). |
|
A request for case sensitivity for the username? is this trolling? (well that post is less for details but more for amusement) @Syquel You wrote:
This lacks reference. Please provide it. |
|
The article you provided is right in the direction it is aming. But I am aiming in a completly different one. In this case I don't see username and password as an authentification tupel but as a concatenated key. This is mainly because we don't have a multi user environment here (if OpCache would provide a multi-user environtment the article you cited would be correct, because of the improvement of the user experience). But enough words. Let's go down to the facts.
I hope you see the vast difference. As long as OpCache doesn't provide a bruteforce protection (in my opinion Opcache is a security critical application, so I don't rely on their authentication but use HTTP Basic Auth) case-sensitivity is capable to strengthen the authentication in a significant way. So I gave you a reason "Why" we should use it. I would be pleased to hear an argument for "Why not". |
|
@Syquel I have not asked for math. I asked for reference. Let me repeat your bold made statement:
This lacks reference. Please provide it. I'm was not asking whether or not that you
but for reference on the claim you've made. I have to admit, for me you've just created the impression that next to sheer numbers you have no actual reference to provide. so all you want to place here is your personal opinion. please keep in mind that PeeHaa is not that type of guy who bases security related stuff on personal opinion only. so if you really want to bring your point forward, just provide some reference. he will love that. |
|
@hakre I don't even know what to say... I am totally speechless... I just stared for a couple minutes on my screen and I still don't understand what you are trying to say... really no offense but I am completely starteled. @PeeHaa what would you like as proof / reference? What would help you with your decision? I know my comment sounds really offensive, but be assured it isn't meant to be. I just don't know how to write it in another way. I apologize in advance! |
You didn't provide a proof. It's perhaps better labled as describing properties. Wether these shown properties have actual security implications or not has not been said by that. One could say, you're believing the numbers too much. That's also the reason I asked for reference. Even with those properties, what are the security implications? Does it really lower security if the username is not case sensitive? If so, why? These much more interesting questions can't be answered with a 6th grade math calculation. Hence I asked for reference. You still didn't provide any. As I have asked already two times, it seems obvious that you can not provide reference to any security literature which is about that topic. Hence there is not much argument for a change request. Especially as with every change comes with risk of introducing errors. Therefore security wise, the most secure option is to keep things unchanged unless there is an actual flaw with case-sensitivity in usernames for which reference is still missing despite asked for. |
|
Okay this will be my last comment on this topic, because it is starting to frustrate me... As you mentioned this is simple math. Everybody who is able to analyze simple mathematical data should see in which way a case sensitive username would (statistically) significantly slow down a bruteforce attack. In my opinion using case-insensitive usernames are as bad as using case-insensitive passwords, because it is a single authentication tuple. The more combinations are possible with this authentication tuple the more secure the authentication is (just the math I showed you...). This is the basic principle of authentication. I don't know if someone ever wrote about why "more complexity == more security", because at Uni they just assume you understand that concept. I seriously don't know how to react to your comment. Hopefully the following is satisfying for you otherwise I don't know what to say anymore: https://stackoverflow.com/questions/20094473/password-case-sensitive-check (ah well he does the same math... maybe a coincidence?) About your panic about introducing errors: Look at my commit. I already implemented it. But would you be kind enough to answer my question? Why should someone implement case-insensitive usernames? |
I don't speculate about the reason here, all I know is that it has been implemented case insensitive. And from what I know this does not qualify as a flaw. According to the math you did, no code change is even necessary, just increase your password length. If you ask for my personal opinion: I don't have a specific preference. If email addresses are accepted as usernames, the domain part must be case-insensitive to conform standards. |
|
Pulled in the config comment about the password hashes and released in v1.0.0-rc2. Still thinking about the case sensitivity issue. |
|
-1. Usernames should not be considered a secret. Therefore, case sensitivity adds nothing but potential confusion on the user side while adding no value. Additionally, it was intentionally not documented that |
|
Thanks @ircmaxell for your feedback and for the |
|
After getting feedback I have implemented the following two things±
https://github.com/PeeHaa/OpCacheGUI/releases/tag/v1.0.0-rc3 |
I added an explanation which hashes can be used as passwords (Not everyone knows that the example hash was generated by password_hash() ...).
Also I removed your case-insensitive comparision of usernames.
Why would we want to loosen our security by reducing the complexity of a username? Currently there is no bruteforce protection, so it couldn't hurt to have a strong strong username-password-pair.