[PHP] Re: why are passwords stored encrypted in databases even when thedatathey protect is stored in the same database?
Dietrich Bollmann wrote: 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? Thanks for your
Re: [PHP] Re: why are passwords stored encrypted in databases even when thedatathey protect is stored in the same database?
On Fri, Jun 13, 2008 at 8:20 AM, M. Sokolewicz [EMAIL PROTECTED] wrote: Dietrich Bollmann wrote: 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
[PHP] Re: why are passwords stored encrypted in databases even when thedatathey protect is stored in the same database?
On Fri, 2008-06-13 at 14:20 +0200, M. Sokolewicz wrote: Considering you're already jailing access by linking a specific url to a specific password you're making the impact of a hacked password pretty small. Which is a good thing :) I would recommend, if you go this way, to add an expiry date to the url/password combo. So for example you can only use that url/password combo for 3 days before it expires, after that, you need a new combo. Doing it this way (with server-generated passwords) you make sure that _if_ it were ever to fall into hands-it-should-not-be-in, it won't be there for long. - Tul P.S. in other words, sounds fine to me :) Thank you again! ...so finally I can get to work :) Best wishes, Dietrich On Fri, 2008-06-13 at 14:20 +0200, M. Sokolewicz wrote: Dietrich Bollmann wrote: 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
Re: [PHP] Re: why are passwords stored encrypted in databases even when thedatathey protect is stored in the same database?
Taking into mind that email addresses extracted out of hacked databases is one of the main spam industry seeders, I always wonder why web application developers don't consider encrypting emails the same way they consider encrypting password! Once a hacker has full access to a database, an encrypted password becomes like locking the door while keeping the window open! Say a user has an account in some discussion forum, that uses an open source, or visible-source software. She has about 5000 posts in which she has expressed her personal opinions on just about many things. Now what a hacker has to do is to dump the database into a local server running the same software, and begin analyzing the data, creating well-crafted lists of potential customers for which he's going to deliver very well-targeted mailing newsletters! Regards, Usamah -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
