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 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 interesting explanation! > > Dietrich > 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 :) > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
