Re: My novice attempt at making a secure login...
Posted: Wed Feb 24, 2010 2:53 am
Hashing usernames or trying to obscure hashing scheme is a poor man's solution.
If you try to mix with the preimage, you are creating security based on obscurity. This is pretty much useless. The thing is, if you construct hashing scheme properly, cracking the hash basically means that the intruder already has a greater access to your entire system. A mix-up will not stop him. This approach is also useless in case of Open Source.
It's not the first time someone thinks that using multiple "passwords" or hashing the username in the authentication process is a perfect idea. Traditionally, there was only one field to fill: the PIN code field. This still exists in cellphones and similar devices. The reason why it works on them is because they are one-user systems and often in the hands of the owner. In case of websites, there are many users. Giving just a password field is not enough, because we can't know who is trying to log in. Web applications utilize databases a lot. The user table in the database has a field called ID. This is used by the application to determine/locate the specific user/row. However, expecting users to remember the ID is bad in terms of usability, thus, we created the username -field. It allows the program to locate the row and see if the password matched.
When you hash the username, which must be assumed to be weak, you need to salt it. If you salt it and the salt is kept on the database, then how are you going to locate the correct user row? You can't SELECT the salt from the user's table, because you can't locate the row. You can't hash the username with a salt because you can't get the salt before you hash the username with the salt. It won't work. If you leave the salt, the hash is so weak that it makes me vomit. It's not really worth the shot. The password is going to be way harder to break than the username. If someone can break the password within a day, he will break the username. If he spends a year to break the password, he will break the username. If he never breaks the password, then it won't matter if the username is hashed.
Hashing usernames and obscuring the hashing scheme? I vote down.
If you try to mix with the preimage, you are creating security based on obscurity. This is pretty much useless. The thing is, if you construct hashing scheme properly, cracking the hash basically means that the intruder already has a greater access to your entire system. A mix-up will not stop him. This approach is also useless in case of Open Source.
It's not the first time someone thinks that using multiple "passwords" or hashing the username in the authentication process is a perfect idea. Traditionally, there was only one field to fill: the PIN code field. This still exists in cellphones and similar devices. The reason why it works on them is because they are one-user systems and often in the hands of the owner. In case of websites, there are many users. Giving just a password field is not enough, because we can't know who is trying to log in. Web applications utilize databases a lot. The user table in the database has a field called ID. This is used by the application to determine/locate the specific user/row. However, expecting users to remember the ID is bad in terms of usability, thus, we created the username -field. It allows the program to locate the row and see if the password matched.
When you hash the username, which must be assumed to be weak, you need to salt it. If you salt it and the salt is kept on the database, then how are you going to locate the correct user row? You can't SELECT the salt from the user's table, because you can't locate the row. You can't hash the username with a salt because you can't get the salt before you hash the username with the salt. It won't work. If you leave the salt, the hash is so weak that it makes me vomit. It's not really worth the shot. The password is going to be way harder to break than the username. If someone can break the password within a day, he will break the username. If he spends a year to break the password, he will break the username. If he never breaks the password, then it won't matter if the username is hashed.
Hashing usernames and obscuring the hashing scheme? I vote down.