2 questions...

[Tuxdapenguin]

I have two questions, one about mysql and one about a login system:

 

mysql: when my visiters register on my site, their passwords will be stored on the mysql server and will be visible to me (and i dont want to know their password) is their any way to mark them as * signs in the server?

 

login: how do i keep the login on multiple pages without the use of variables? cookies? and how do i do this?

[sspoke]

you can hash the passwords with md5('password');

 

than check the mysql hash with the hash the person puts in

 

 

clientside masking of password

<input type="password" name="password" size="20">

 

type="password" = masked

 

 

serverside sessions make users stay logged in in conjugation with cookies

[Tuxdapenguin]

you can hash the passwords with md5('password');

 

than check the mysql hash with the hash the person puts in

 

 

clientside masking of password

<input type="password" name="password" size="20">

 

type="password" = masked

 

 

serverside sessions make users stay logged in in conjugation with cookies

 

but in phpmyadmin i will still be able to see the passwords entered. is it impossible to set it as a specific password field so that the entries will be shown as * marks?

[obsidian]

but in phpmyadmin i will still be able to see the passwords entered. is it impossible to set it as a specific password field so that the entries will be shown as * marks?

 

If you are encrypting them with MD5, or even the MySQL PASSWORD, you will not be able to see it. You need to encrypt them when you insert them, and then remember to check against that encryption when you run your login. That's what sspoke is talking about.

[sspoke]

well I think its impossible but encrypting passwords into mysql with md5 or sha1 would make the passwords look like  e8ds89f89sd89f89sdf989sd  or some shit like that

 

you encrypt the password when the user registers to website than when he attempts to login his password gets encrypted again and the encrypted version gets checked with the database encrypted version of that same password so you like never knew the password in the first place only the owner does.. of course md5 can be cracked but its safe enough..

[leeming]

no, would will have do what sspoke said...

 

when saving the password, in the insert query just put md5($password) instead of $password.. this will save a thing called a hash, this means you can only go 1 way to encrypt it (you cant decrypt it)...

 

why do this?

 

well.. when people log in, instead of searching for the loging details using the where clause

 

"WHERE user='$user' AND password = '$password'"

you put

"WHERE user='$user' AND password = '".md5($password)."' "

 

All this basicly means is (using "adam" as the password) its not checking the database for the password typed in by the user (as the hash will be some thing with what seems to be random letters and numbers) but its checking the hash to the user's input for password, and the real hash for the password saved (the hashes will be the same)

[Psycho]

.. of course md5 can be cracked but its safe enough.

 

No, it cannot. MD5 is a hash not an encryption. There are lookup tables that contain the MD5 hashes for millions of MD5 values. But, there is no way to definitively determine what value created any MD5 hash, because an MD5 hash can have many different values that were used to create it.

[sspoke]

ya it can they got rainbow tables for like millions of the most common passwords used so any password around 8 characters or less is listed in the rainbow table everyone uses same salt in md5

[Balmung-San]

.. of course md5 can be cracked but its safe enough.

 

No, it cannot. MD5 is a hash not an encryption. There are lookup tables that contain the MD5 hashes for millions of MD5 values. But, there is no way to definitively determine what value created any MD5 hash, because an MD5 hash can have many different values that were used to create it.

 

It all depends on your definition of cracked. I could easily run an attack against the password hash. If I come up with a successful password, then I'd say it's cracked. However, some people may seem cracked as having reversed the encryption, which you can't do with a hash.

 

I know of at least 1 tool for attacking md5 hashes that simply does dictionary and brute force attacks.

[Psycho]

ya it can they got rainbow tables for like millions of the most common passwords used so any password around 8 characters or less is listed in the rainbow table everyone uses same salt in md5

 

Did you read my entire post? I stated that there are lookup tables. And, if you are looking up a hash that you know was created from a password (e.g. only accepts certain characters and is of a certain length), then if the lookup returns a value that makes sense for a password, then it probably was the password. BUt, that does not mean that the hash was cracked.

 

ANY hashing/encryption method can be used to create a database of "common" values. But, the mere fact that you have an MD5 hash does not mean you can figure out what was used to create the hash. There are an infinite number of values that can create the same hash. They are called collisions. This site has an example of two different documents that will create the same MD5 hash: http://www.cits.rub.de/MD5Collisions/

 

Plus, you should always be using a unique salt when creating your hash anyway. In that case there really is no way to unencrypt the hashed value.

[Jessica]

A little off topic, but how do you guys do salt? I know of a few different ways to do it, just wondering what people use?

[obsidian]

A little off topic, but how do you guys do salt? I know of a few different ways to do it, just wondering what people use?

 

I typically come up with a fairly lengthy string that has meaning to me or to my site and then write it up in 3l1t3 sp34k or something similar. That way, I can remember it fairly easily, but it would be nearly impossible for someone to just guess.

[Psycho]

I prefer to use a unique salt for each user as that makes it almost inpenetrable.

 

If the username cannot be changed then I might use something like this:

 

$salt = sha1($username);

$secure_password = md5($salt . md5($password));

 

This page has a nice routine that is very secure although perhaps a bit verbose: http://www.phpit.net/article/handling-passwords-safely-php/

[Jessica]

obsidian: But where do you use it?

 

Edit: I guess my question is how does salt stop the dictionary attacks on user's accounts? It seems like it only does any good if the "hacker/cracker" somehow gets access to the database - so the articles that tell you to store the salt per user in the db don't make any sense - if they have access to the password column, they have access to the salt.

[Psycho]

obsidian: But where do you use it?

 

Edit: I guess my question is how does salt stop the dictionary attacks on user's accounts? It seems like it only does any good if the "hacker/cracker" somehow gets access to the database - so the articles that tell you to store the salt per user in the db don't make any sense - if they have access to the password column, they have access to the salt.

 

With obsidian's method you would just use it in the source code itself. With respect to your 2nd question, just having access to the database would not be enough. The hacker would also need to have access to the source code to detemine how the salt and the password were hashed. The salt does you no good if you don't know how it was used.

 

But, for the sake of argument, lets say the hacker was able to get ahold of the secure password and the salt. So what? Those MD5 lookup tables aren't created in a couple days. Even with the method of hashing the password and the salt(s) it could take days, months, even years to find a value that fit.

 

That is why having strong passwords is so important. If someone chooses the password "apple" a quick dictionary attack would find it in no time. However "@pp1e" would take considerably longer. Of course, it wouldn't be difficult to replace letter in common words with 133t letters when runing the attack, but do you do that before or after going through all the words with regular letters? If you do it first, it could take a very long time to crack the password "zebra". But, dictionary attacks are the reasons many sites will lock you out after three failed attempts.

 

So, with "good" security in place the hacker would have to gain access to the database and the source code. Then he/she would need the time and processing power to crack the passwords. If the site requires strong passwords (upper & lowercase letters, numbers and special characters) the hacker would need a lot of time and processing power to make any real progress.

[Jessica]

The method of having a single salt and using it in the code itself seems fine, but all the tutorials I've read that mention it have it as a random salt PER user, and the salt is stored in the DB too. That's why it confuses me.

 

I like the idea of only having so many attempts per day, to help stop brute force attacks on the login screen itself. Because the salt doesn't stop those attempts.

[Tuxdapenguin]

okay i choose md5 to secure the passwords but how do i secure the login with cookies?

[Psycho]

I don't know what you mean by "securing" the login with cookies. Typically cookies are used to auto-login users on return visits.

 

If that is the case, store the username and the hashed password as it exists in the database in a cookie, plus set the expiration time accordingly. When a user attempts to load a page that requires login, first check if they are logged in (session variables), if not then check for the cookie values. If they exists attempt to authenticate with those. If that fails send them to the login page. This is typically done with a script that is included at the top of every secure page.