On Fri, Jun 13, 2008 at 8:20 AM, M. Sokolewicz <tularis@xxxxxxx> 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 > > What I would consider here is to send a link to a specific access page with a new hash for each user requesting a file. That hash could point to a db record that has the file name and access grants for the file. then nothing is exposed and if you create the hash based on a time value it should be unique -- Bastien Cat, the other other white meat
