Welcome Guest, Not a member yet? Register   Sign In
Best practices for secure passwords
#1

[eluser]Bramme[/eluser]
Hi all

Another quick question (though it deserves some attention, that's why I put it in a separate topic).

What are some best practices to have a secure log in for a website?

Here's the (current) plan:

- When a user account is created, the user chooses his password (min length, etc)
- The backend prefixes it with a set salt from a config file and then hashes the entire string (salt + chosen pw) with sha1().
- the hash is saved in a mysql database.
- when the user logs in a query is sent in the form of "SELECT * FROM users WHERE username = 'username' AND password = 'hashedpw'" (where the hashedpw is ofc the one from the login screen, prefixed with the salt)
- if num_rows=1 the username and hash are saved in a session (using the session library, with $config['sess_use_database'] = TRUE)
- every refresh the auth library checks the username and hash saved in the session if they exist in the database.


In the past I used to replace the last two steps with: if num_rows=1, make a session called $_SESSION['loggedin'] = TRUE. with every refresh, i would merely check if $_SESSION['loggedin'] == TRUE.

I now realise that probably wasn't that safe :p However, is my current method okay, or should I add a random salt to the passwords too (that is then also saved in the database)?
#2

[eluser]adamp1[/eluser]
I do exactly what you say in the first part, add a salt and hash it. If you add a random salt then surely you can never check the password since the salt is random and you will never be able to generate the same salt again as the time it was first set.
#3

[eluser]Bramme[/eluser]
that's why the second (random) salt also has to be stored in the database. I noticed phpbb does this, but never really considered it a safe option...
#4

[eluser]Yash[/eluser]
If session get hacked some how everything is useless ...else do_hash like simple function of n combination will give you strong session.

I just feel ...may be I'm wrong Smile
#5

[eluser]Adam Griffiths[/eluser]
Dynamic salts should never be used on their own, for the very reason stated above, if somebody had a hold of the database, then they have the dynamic salt. So dynamic salts (in my opinion) should always be used with a static salt.

But of course even if somebody did have a hold of the database, they wouldn't necessarily be able to find the suers password because they have no idea how you used the salt. You could have split the password into three parts, put the dynamic salt in the first break and the static salt in the second break.

You should never be limited to just putting salts on the end or at the beginning of strings.
#6

[eluser]Bramme[/eluser]
At the moment, I split the password and the static salt in it. I was just wondering if it was worth the trouble of adding dynamic salts too. Is it that much safer?
#7

[eluser]Adam Griffiths[/eluser]
[quote author="Bramme" date="1249498493"]At the moment, I split the password and the static salt in it. I was just wondering if it was worth the trouble of adding dynamic salts too. Is it that much safer?[/quote]

It's merely security through obscurity. Given enough time and resources any hash can be reversed into the cleartext. So adding a dynamic salt too just adds a bit more obscurity to the hash.




Theme © iAndrew 2016 - Forum software by © MyBB