Page 2 of 3
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 10:39 am
by social_experiment
But I also wanted to use incorporate dynamic salting...
I tried dynamic salting, works perfectly for just one user, the problem (for me) is when there are more than one user.
When the user logs in, as soon as the login details have been authenticated, you start changing your salt, and hashes for password / username. The difficulty starts when you have more users and just ONE dynamic salt, because when you generate a NEW salt, the existing usernames and password, that was generated with the old salt, doesn't log you in anymore because the salt has changed. Only your newest password / username will work, and only until you add a new user (and so forth).
Why this is easy with one user is because if you have only 1 salt, in a table (i use mySQL) the salt has a id that is know (to you atleast). If a new table is created, and you add the details, your first row's id will be either 1 or 0 (or the value you assigned it). So when you login, the query that selects the salt looks like :
Code: Select all
<?php $q = mysql_query("SELECT salt FROM salttable WHERE id = 'idValue' "); ?>
If you have multiple salts, each one associated with a matching set of hashed usernames and passwords, how do you get that id for each salt, because when you attempt to login, you have to first select the salt, hash the detai then see if that matches what you have stored inside your database. I think using dynamic salts is superb but i have not yet found a way to use dynamic salting with multiple users. Unless you create a new table for each user which doesn't seem viable.
What i just thought about is that if you have multiple users and just one dynamic salt, on a login you could create new hashes for ALL usernames / passwords?
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 12:47 pm
by flying_circus
Your method seems like a lot of work.
I think I would use something like this:
Code: Select all
/* Psuedo Code */
# Create User Table in Database:
CREATE TABLE `users` (
`user_id` int() unsigned,
`user_name` varchar(),
`user_password` varchar(),
`user_salt` varchar(),
PRIMARY KEY(`user_id`)
)
# Only accept login attempts transmitted over HTTPS
if(!is_https())
return false;
# On login Attempt
$user = "SELECT `user_id`, `user_password`, `user_salt` FROM `users` WHERE `user_name`='$submitted_user_name' LIMIT 1;";
if($user['password'] === hash($submitted_password . $user['user_salt']))
{
# If you're hell-bent on rotating the salt, do it here.
$new_salt = generate_new_salt();
$hot_salty_password = hash($submitted_password . $new_salt);
"UPDATE `users` SET `user_password`='$hot_salty_password', `user_salt`='$new_salt' WHERE `user_id`='$user['user_id']';";
# Log Me In
login($user['user_id']);
}
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 2:11 pm
by social_experiment
Code: Select all
<?php $user = "SELECT `user_id`, `user_password`, `user_salt` FROM `users` WHERE `user_name`='$submitted_user_name' LIMIT 1;"; ?>
This would leave your username as plain text wouldn't it? But with that transfer occuring over https, that probably wouldn't matter, correct?
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 2:51 pm
by flying_circus
Nope, take a look at the next line:
Code: Select all
if($user['password'] === hash($submitted_password . $user['user_salt']))
We are taking the submitted password, hashing it with the users salt, then comparing the new hash to the hash that is stored in the database.
In a practical application, we should also be using a pepper that is not stored in the database. The idea being, if your database became compromised, the attacker does not have the pepper.
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 3:55 pm
by social_experiment
Code: Select all
<?php $user = "SELECT `user_id`, `user_password`, `user_salt` FROM `users` WHERE `user_name`='$submitted_user_name' LIMIT 1;"; ?>
But your username is not being hashed anywhere in the script, you're hashing the password and testing that against the database values. From what i can see it needs to be a plaintext username that makes the selection of the user_salt, user_id and user_password. Only when that is done, does the script begin with hashing. Unless $submitted_user_name is hashed.
Code: Select all
<?php if($user['password'] === hash($submitted_password . $user['user_salt'])) ?>
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 3:59 pm
by flying_circus
You're correct, sorry, I mis-read your previous post.
Yes, the username will remain plain text in the database. Why should you hash the username?
Re: My novice attempt at making a secure login...
Posted: Wed Feb 17, 2010 4:47 pm
by social_experiment
Extra-security? That's how i see it, but the example you gave with the pepper could then 'fill' the gap (if any) left by the plain text password. Also, if someone cracked your db, they would have your username so half the job of getting the login details would be done.
Re: My novice attempt at making a secure login...
Posted: Sat Feb 20, 2010 3:47 am
by kaisellgren
There's a problem with hashing usernames. If the hash ever collides with another username hash, the software can't disguise between the two and thus can not log the user in.
Re: My novice attempt at making a secure login...
Posted: Sat Feb 20, 2010 12:20 pm
by social_experiment
There's a problem with hashing usernames. If the hash ever collides with another username hash, the software can't disguise between the two and thus can not log the user in.
What if you checked usernames at registration to determine that they are not similar to anyone already existing within the database? Also, wouldn't this premise then apply to usernames without hashing?
Re: My novice attempt at making a secure login...
Posted: Sun Feb 21, 2010 5:28 am
by kaisellgren
social_experiment wrote:What if you checked usernames at registration to determine that they are not similar to anyone already existing within the database? Also, wouldn't this premise then apply to usernames without hashing?
Oh yeah, I didn't think of that. As long as you check whether the hash of the username already exists and remember that you can't use the username as a foreign key/primary key as it might change when the user resets his/her username (e.g. he forgets his username). This would bring the username closer to the role of password, and you would essentially move towards a system with two passwords in the log-on. This is not a bad or a good thing, it's just another route you can take.
Re: My novice attempt at making a secure login...
Posted: Sun Feb 21, 2010 8:11 am
by timWebUK
I'm slightly confused as to what the issue with hashing usernames was... you would always check the username wasn't already in the database regardless. And if you hash, no two different usernames would produce the same hash either. So surely in the sign up you just hash it, then SQL query to check it doesn't exist?
Re: My novice attempt at making a secure login...
Posted: Sun Feb 21, 2010 1:23 pm
by kaisellgren
timWebUK wrote:So surely in the sign up you just hash it, then SQL query to check it doesn't exist?
Yup. There's no problem with that (I previously replied too quickly without thinking), but what you must remember is that you should be careful when you use the username as an identifier, because it might change. For example, in Wordpress they used (not sure if they do anymore) usernames as the identifier, thus, if I ever changed the value, it would easily break some things if you haven't thought about it. There were no problems since you couldn't change the username, but if you hash it, and the user forgets it, then you can do nothing but reset it (=change). So, you must treat the username as a password. After all, you now have a two-password system.
Also, it must be realized that you can't salt this username as you wouldn't be able to locate it otherwise. So, the username would just be a simple hash that is probably cracked pretty easily with dictionary attacks. The added strength to your application is quite minimal, but there are no particular problems in this kind of approach.
Re: My novice attempt at making a secure login...
Posted: Tue Feb 23, 2010 5:57 am
by timWebUK
Is there any added security benefit to creating a mixing up algorithm when storing a password?
For example:
User enters password > salt prefixes password, pepper suffixes it > apply mixing algorithm > hash > store.
pass > salt123 + pass + pep123 > tl322311apppess > b1cfaecf7833748f8d501e0121617fecb82aa32d58dbe24fa29cfdb4027c8bab
Any comments?
Re: My novice attempt at making a secure login...
Posted: Tue Feb 23, 2010 6:31 am
by social_experiment
I think it wouldn't make any difference, because although the hash would now consist of multiple parts, the size of the hash is still the same (string length).
Wouldn't taking all those parts from different fields have an effect on performance?
Re: My novice attempt at making a secure login...
Posted: Tue Feb 23, 2010 6:49 am
by timWebUK
Yeah I guess it would impede performance, it was just a curious question seeing as we're on the subject of hashing usernames and other 'different' secure storage ideas.