[PHP] Re: why are passwords stored encrypted in databases even when the datathey protect is stored in the same database?

2008-06-13 Thread M. Sokolewicz

Dietrich Bollmann wrote:

Hi,

As far as I remember, in all books I read about PHP and SQL, the
password was stored in an encrypted form, even when all the data which
should be protected by the password was stored in the same database.

Can anybody tell me what is the motivation behind this approach?
If somebody hacks the database, he has the data anyway; if he doesn't,
he can't retrieve the password, encrypted or not.

I am asking because I would like to implement a simple file server.
A user would upload his files and get them listed on his user page.  If
he wants to allow some other person to download the file, he pushes a
button beside the file entry in the listing and a page opens where he
can enter the email of the other person.  An email is send with the link
where the file can be found and a password included...

The person who asked me to write this file server wants everybody who to
receive the same link together with the same password for the same file.
In order to implement this approach, the password has to be stored
somewhere...

I thought about storing the password as it is in the database - but
somehow wonder why this never was done in any of the books I read...

By the way: in most cases, when pushing the I forgot my password
button, an email with a user name and a link to activate the password is
generated.  Anybody who gets into the possession of the email could
access the data...  Should I rather send two emails, one with the link,
one with the new password?

Thanks for your help :)

Dietrich


Assuming that noone will ever get direct access to your database or is 
able to access the password directly: there is no need for any type of 
encryption. However, people usually write code which may (and will most 
of the time) containt exploitable sections which might give a malicious 
user the ability to get a dump of the database. A password dump is 
always interesting, since it gives a LOT of information. People usually 
don't use 1 password per login, but rather have a standard password 
for most things.
Now, if it were unprotected, the person getting the information can 
instantly log in as that user, or if he wants might even take over that 
person's identity in other places (rare, but it happens). If it were 
protected by encryption of some kind then it would first need to be 
decrypted to be usable (unless there is a designflaw which makes this 
unnecessery as has been the case in a few messageboards a few years ago).
Now, you can either encrypt or hash your passwords. Hashes are one-way, 
encryption two-way. If the malicious user gets hold of a hash: he'll 
still not have anything useful in his hands. He might make a reverse 
lookup table and figure out the password from that (though there's an 
infinite number of possible inputs for each single [hash] output), but 
add a salt and don't put that in the database and the user has a low 
chance of ever finding out what it was. But, just as the malicious user 
can't figure out what the password was, neither can you: so goodby 
lost-password feature. Instead you'd have to regenerate a new password 
and send that over, or do some other fancy magic which doesn't involve 
sending the current password as-is, since you don't know it either.
If you were to use encryption there, you could always decrypt it. If you 
have the key. Storing the key separately from the encrypted password 
would make this quite safe. enctpyed_string = (data + key), if you know 
neither the data nor the key, things get very tough. Because you know 
the key, you can figure out the password and make a forgot-password 
feature easily which sends out the actual password.
But, because your key is publicly available (if your page has to use it, 
then it's automatically publicly available, maybe not easily, but a 
malicious user which managed to get hold of a full password table, could 
just aswell get hold of the key for the encryption)!
Putting in neither, so just keeping the passwords in their plain form is 
safe. As long as noone _ever_ sees them. Guarantee that and you won't 
have to bother with hashing/encrypting. If you can't guarantee it, build 
in some extra safety in the form of hashing and/or encrypting.


hope that explains it all a bit,
- tul


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Re: why are passwords stored encrypted in databases even when the datathey protect is stored in the same database?

2008-06-13 Thread Dietrich Bollmann
Hi tul, 

So this was a very long and informative answer :)
Thank you very much!

On Fri, 2008-06-13 at 12:02 +0200, M. Sokolewicz wrote:
 [...] However, people usually write code which may (and will most 
 of the time) containt exploitable sections which might give a malicious 
 user the ability to get a dump of the database. A password dump is 
 always interesting, since it gives a LOT of information. People usually 
 don't use 1 password per login, but rather have a standard password 
 for most things.

So if the user is allowed to change his password, it should be encrypted
always as there are chances that the same password is used at some other
place?  That makes a lot of sense to me :)

If all passwords are generated by the system on the other hand and the
user is not allowed to change his password, if further all the protected
data is in the same database as the password, there would be no need for
encrypting the passwords following your argumentation?

But if some information is stored outside the database - in my case
(simple file server) for example, the database only contains the file
meta-data while the files themselves are stored in some data directory
on the server - some malicious user who would have broken into the
database could get hold of the files if the passwords are stored
unencrypted;  if some encryption scheme would have been used on the
other hand the data found in the database wouldn't be of any use at all?

And if the password should be recoverable some encryption with a key
stored somewhere else would force the hacker to break into two systems,
the database itself and the system which is used to store the key.

That makes sense also.  I didn't think about the fact that database and
a directory on the server are two different things which would have to
be hacked separately.  So I am happy about writing my mail and getting
such a nice answer before implementing some stupid password logic
myself :)

 Now, if it were unprotected, the person getting the information can 
 instantly log in as that user, or if he wants might even take over that 
 person's identity in other places (rare, but it happens). If it were 
 protected by encryption of some kind then it would first need to be 
 decrypted to be usable (unless there is a designflaw which makes this 
 unnecessery as has been the case in a few messageboards a few years ago).
 Now, you can either encrypt or hash your passwords. Hashes are one-way, 
 encryption two-way. If the malicious user gets hold of a hash: he'll 
 still not have anything useful in his hands. He might make a reverse 
 lookup table and figure out the password from that (though there's an 
 infinite number of possible inputs for each single [hash] output), but 
 add a salt and don't put that in the database and the user has a low 
 chance of ever finding out what it was. But, just as the malicious user 
 can't figure out what the password was, neither can you: so goodby 
 lost-password feature. Instead you'd have to regenerate a new password 
 and send that over, or do some other fancy magic which doesn't involve 
 sending the current password as-is, since you don't know it either.
 If you were to use encryption there, you could always decrypt it. If you 
 have the key. Storing the key separately from the encrypted password 
 would make this quite safe. enctpyed_string = (data + key), if you know 
 neither the data nor the key, things get very tough. Because you know 
 the key, you can figure out the password and make a forgot-password 
 feature easily which sends out the actual password.
 But, because your key is publicly available (if your page has to use it, 
 then it's automatically publicly available, maybe not easily, but a 
 malicious user which managed to get hold of a full password table, could 
 just aswell get hold of the key for the encryption)!
 Putting in neither, so just keeping the passwords in their plain form is 
 safe. As long as noone _ever_ sees them. Guarantee that and you won't 
 have to bother with hashing/encrypting. If you can't guarantee it, build 
 in some extra safety in the form of hashing and/or encrypting.
 
 hope that explains it all a bit,
 - tul

Yes.  A bit.  I am actually impressed.  But I better read some more
redundant book about intelligent malicious users as I still feel like
not understanding everything of what you said completely.

...any nice book recommendation for naive people like me :?

So how about the following solution to my simple file-server problem:

I generate a new url for every user who is allowed to download a file
and a private password for every new url.  Using this approach, the same
file will be downloaded by different users via different urls and
passwords.  The password for an url is stored in the database encrypted
and send over to the user unencrypted per email.  Of course this makes
some more logic and tables necessary - and a new row for every user also
- but who cares :)  What do you think?