how secure is password()

[plusnplus]

Hi..,

is there any possible to see what real text after use password()?

example:

insert into table1 values(password(1234));

if somehow someone can access this table, can they see the real word "1234" ?

 

 

[trq]

MySql's password is not meant for public use. Its an internal function used by mysql itself.

[fenway]

In fact, the refman says so.

[Mr Hyde]

It's pretty secure... BUT I would still either salt it by concatenating a secret word on to the front or back of the password before encrypting it, or use php's md5 function and salt it, and then pass it to password() in MySQL.

 

With the wide proliferation of rainbow tables now, you can't be too careful. Of course if you are passing your user's password via clear text then it really doesn't matter that much anyway. Worrying about password security when you pass a password like that would be like worrying about your deposit in the bank, but giving it to a 10 year old to take across the street and drop it off first.

[fenway]

What makes you think it' secure/

[nankoweap]

is there any possible to see what real text after use password()?

 

in a word, yes. exploits for other crypto functions are in the ether too. the mysql docs expressly mention not using the password function in your application. instead, consider using sha2 with a high bit length. all of this and more is covered here:

 

http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html

 

Mr Hyde makes a good point too, though. your app is as secure as its weakest link. if you're passing passwords in clear text, then using the password function is overkill.

[Mr Hyde]

Mr Hyde makes a good point too, though. your app is as secure as its weakest link. if you're passing passwords in clear text, then using the password function is overkill.

 

Here is a good launchpad for building a CHAP login system. Basically, the idea is to store the encrypted password in your table, and when a client tries to login, you encrypt their credentials client side  via javascript (now their password is the same as what you actually have in your database), pass a salt, then you encrypt again on both sides via the shared salt and compare the results. It's certainly not an impervious method, but if ssl is cost prohibitive that's a good way to go.

 

My thinking is that if a client trusts you with their password, the least you can do is try to protect it. It's very likely that they use the same password on their banking website, email etc.