Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck <[email protected]>:
> Hi guys. Some time ago I asked about the best way to encrypt a password. Some > of the recommendations I got was: > > 1) Generally for passwords you do not write a decrypt method for security > purposes (eg you do not want people to be able to reverse engineer the > encrypted password easily) > 2) put a little salt > 3) There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI > 4) I should not decrypt password but instead I should compare both encrypted > versions to see if they are equal. > > My scenario is the following. I need to store database passwords in text > files. So I don't want to let them as plain text. And while I understand 4), > I think it's a different scenario than mine. I know that some database driver > may allow you to directly send the encrypted password. But still...I have > another similar scenario in which I have to store a password and then send it > (unencrypted)...so I kind of really need a bi-directional encryption. > > Now..I would try to avoid having an external library + FFI. Any ideas what is > the best thing I can do? And how could I solve 1) if I want bidirectional > like in my case? > "I know that some database driver may allow you to directly send the encrypted password". That would be the same as having no encryption at all. Everyone knowing the encrypted password could authenticate. I'm not sure I understand the complete requirements. Do you really don't want to store them as plain text files or do you want to prevent others from being able to read them? Basically a password that is decryptable would be useless because in order to make it secure you would need to store some other information to decrypt it somewhere thus shifting the same problem from the password to the "something else". Assuming you have encrypted password files I can also assume that the process reading it is to be considered trusted. Otherwise it won't work because the password needs to be in its decrypted form somewhere in this process and this only works if you can trust the process. This problem is often solved using filesystem permissions. Often programs are started as root and so they can read files where root is the only one having read permisson. After doing priviledged stuff the program drops its priviledge and acts as a normal user. In case of a pharo image that wouldn't be to easy. You could have a small program started as root reads the information from the file and starts pharo as normal user passing the information in. Or you could start pharo and another priviledged program that reads the password file and sets the information in the pharo image via socket or something similar. Or you are able to start the pharo process with a dedicated user and arrange the filesystem permission in a way that only this user has read access. Basically they are all the same. If those are no options than it will be hard. Of course you can encypt the password file itself but that won't work without extra measurement. That is always the trap in thinking about security. The encryption of the password file would be possible only if you have something you can decrypt it with. And that information would have exactly the same security implications as the password itself. Thus it solves nothing but only shifts the responsibility for security to another piece of information. Maybe you can specify your problem a bit more so. Norbert
