> > > I 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". >> >> > Yes, but it would make things A LITTLE bit more complicated. One thing is > to browse a simple .txt editor with ssh and another one is find the Pharo > .image, open the image, search the code that decrypts, decrypt the password > etc... So at least it adds some effort to the hacker :) > > > Ok. What I meant is that if you encrypt the password, there is some > password2 you need to encrypt the first password. I was assuming you don't > want to keep a secret inside the image. And then it would be hard because > password2 would need to be stored secure as well. If you are able to keep a > secret in the image then this is a good idea and provides a different type > of safety than the filesystem stuff. Well, you could add the filesystem > protection as well and then you're ok. > > mmmm sorry I didn't get it. password2 would be a "salt" in this case? you could explain a bit more?
But imagine that at some point I DO need to decrypt in the image side. Which algorithm should I use in Pharo? > 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. >> >> > yes > > >> 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. >> >> > mmm i understand. Doesn't look easy. The last one "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" sounds one more > thing to do that could help. The only thing this can fail is if the user > the hacker use to get inside is the same that runs Pharo or one with root > provilegies. > > > Exactly. If someone is able to gain root priviledge there is not much left > you can do. > Indeed. So the only particular concern for this case is if it get access to the user than runs Pharo and that has read access to such files. > That is one of the reasons why programs should have no special priviledges > or drop them after doing important stuff. Writing a C application that > starts your image, read password file and drops priviledge is not as hard > as it sounds. Probably the way you pass the information to the image is a > bit more. > I understand. > You certainly can not pass it as an argument to the image without further > measurement because it would be visible by programs like ps. But there are > ways to hide it or you can you use a pipe. > > 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. >> >> > yes, but as I wrote a bit, it will make it a bit more complicated! > > > > Thanks Norbert for the ideas. > > My pleasure! > > Norbert > > > -- Mariano http://marianopeck.wordpress.com
