On Fri, Jul 12, 2013 at 2:41 PM, Mariano Martinez Peck < [email protected]> wrote:
> >> 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? > > I guess I need something like this: http://stackoverflow.com/questions/1132567/encrypt-password-in-configuration-files-java A two-way encryption algorithm for Pharo. That, besides with the filesystem permissions thingy :) Anyone knows what we have? Thanks, > 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 > -- Mariano http://marianopeck.wordpress.com
