Recommendation for password encryption?
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? Thanks in advance, -- Mariano http://marianopeck.wordpress.com
Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
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
On 12 Jul 2013, at 16:44, Norbert Hartl <norbert@hartl.name> wrote:
Maybe you can specify your problem a bit more so.
I think what he basically means: the app needs to access the db, for which it needs a db password. How should he store it ? It also depends if there is only one db password, or one for each user, and in the latter case, if it is the same as the one entered by the user. But maybe, I am guessing wrong.
On Fri, Jul 12, 2013 at 11:56 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 12 Jul 2013, at 16:44, Norbert Hartl <norbert@hartl.name> wrote:
Maybe you can specify your problem a bit more so.
I think what he basically means: the app needs to access the db, for which it needs a db password. How should he store it ?
Yes, exactly. Answering also to Norbert...that's the case. Say someone hacks the server and has access to files. It would be too simple to browse a .txt file with data and get the password as plain text. (I will answer more in Norbert mail)
It also depends if there is only one db password, or one for each user, and in the latter case, if it is the same as the one entered by the user.
No, the db password is not supplied by the user. But it's not only one password either. There are a few (because there are a few databases). But all the users will use the same DB password/username. Thanks! -- Mariano http://marianopeck.wordpress.com
Am 12.07.2013 um 18:57 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Fri, Jul 12, 2013 at 11:56 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Jul 2013, at 16:44, Norbert Hartl <norbert@hartl.name> wrote:
Maybe you can specify your problem a bit more so.
I think what he basically means: the app needs to access the db, for which it needs a db password. How should he store it ?
Yes, exactly. Answering also to Norbert...that's the case. Say someone hacks the server and has access to files. It would be too simple to browse a .txt file with data and get the password as plain text. (I will answer more in Norbert mail)
If you can do it with filesystem permissions you are safe. If someone hacks your server it is important which priviledge he is able to gain. If you store the password file for root read-only there is no way around it. Either the intruder gains priviledge of the user of your image and won't be able to read the password file but still is under control of your image that has the password stored internally. If the intruder gains root priviledge it isn't important to protect the password fail because he has complete access to the database if the database runs on the same machine. I'm curious about your reply to my mail :) Norbert
It also depends if there is only one db password, or one for each user, and in the latter case, if it is the same as the one entered by the user.
No, the db password is not supplied by the user. But it's not only one password either. There are a few (because there are a few databases). But all the users will use the same DB password/username.
Thanks!
-- Mariano http://marianopeck.wordpress.com
On Fri, Jul 12, 2013 at 11:44 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck < marianopeck@gmail.com>:
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.
Indeed.
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?
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 :)
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.
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. -- Mariano http://marianopeck.wordpress.com
Am 12.07.2013 um 19:05 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Fri, Jul 12, 2013 at 11:44 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
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.
Indeed.
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?
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.
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. 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. 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
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
On Fri, Jul 12, 2013 at 2:41 PM, Mariano Martinez Peck < marianopeck@gmail.com> 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... 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
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. 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. 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.
Norbert...just curious...I guess it's a good idea if I have no ssh access for the user that runs the Pharo image and that will likely have read access to such file, right? So that way they only way to get inside the system is with another user and then jump to the one than runs Pharo. So there are at least 2 users there and not one. It makes sense right?
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
Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
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. 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. 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.
Norbert...just curious...I guess it's a good idea if I have no ssh access for the user that runs the Pharo image and that will likely have read access to such file, right? So that way they only way to get inside the system is with another user and then jump to the one than runs Pharo. So there are at least 2 users there and not one. It makes sense right?
Not to me :) It's like I tried to explain lately with the password encrypted with a password. If it comes to security you can always make things more complicated and building chains. In the end the security is defined by its weakest link. So you need to find out where are weaknesses. Assuming that if you can login via ssh it doesn't mean anyone else can. Basically there are two possibilities. Either ssh has a security hole or you loose your key with password. What else should happen? If ssh has a security hole it doesn't matter which user tries to log in. And using another user means that someone is on the machine. I think getting access to a machine is a _much_ more difficult than to get root access if you are loggend into a machine. So my advise would be: Smalltalk and security are the two ends of the productivity scale. While smalltalk can make you really productive, security can keep you from achieving anything. Btw. that is the reason why I decided to go for programming instead of security 15 years ago. So instead making it complicated for yourself without gaining anything you need to define exactly what is the scope that you want to protect and against which measuements you want to protect yourself. If you don't trust ssh order a KVM switch with remote capabilities at your provider. With that you can have access to the console of the computer and you can turn off ssh completely. But how do you copy files to the machine thenâ¦.??? Ah and btw. while we are at it. I hope you don't use linux. Why designing a tight security strategy if you put it on top of an immature operating system? Use OpenBSD instead! I hope you can see what I'm trying to tell you. There is no such thing as security. There is only a probability that someone breaks into your machine. Lowering this probability means most of the time making the system a lot more cumbersome. So for every project there is a setting that leverages best for the needs. But before that you have to know what is really necessary so put a probability onto every measurement and not try to be too paranoid. Norbert
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
On 15 Jul 2013, at 16:29, Norbert Hartl <norbert@hartl.name> wrote:
Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
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. 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. 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.
Norbert...just curious...I guess it's a good idea if I have no ssh access for the user that runs the Pharo image and that will likely have read access to such file, right? So that way they only way to get inside the system is with another user and then jump to the one than runs Pharo. So there are at least 2 users there and not one. It makes sense right?
Not to me :) It's like I tried to explain lately with the password encrypted with a password. If it comes to security you can always make things more complicated and building chains. In the end the security is defined by its weakest link. So you need to find out where are weaknesses.
Assuming that if you can login via ssh it doesn't mean anyone else can. Basically there are two possibilities. Either ssh has a security hole or you loose your key with password. What else should happen? If ssh has a security hole it doesn't matter which user tries to log in. And using another user means that someone is on the machine. I think getting access to a machine is a _much_ more difficult than to get root access if you are loggend into a machine.
So my advise would be: Smalltalk and security are the two ends of the productivity scale. While smalltalk can make you really productive, security can keep you from achieving anything. Btw. that is the reason why I decided to go for programming instead of security 15 years ago.
So instead making it complicated for yourself without gaining anything you need to define exactly what is the scope that you want to protect and against which measuements you want to protect yourself.
If you don't trust ssh order a KVM switch with remote capabilities at your provider. With that you can have access to the console of the computer and you can turn off ssh completely. But how do you copy files to the machine thenâ¦.??? Ah and btw. while we are at it. I hope you don't use linux. Why designing a tight security strategy if you put it on top of an immature operating system? Use OpenBSD instead! I hope you can see what I'm trying to tell you. There is no such thing as security. There is only a probability that someone breaks into your machine. Lowering this probability means most of the time making the system a lot more cumbersome. So for every project there is a setting that leverages best for the needs. But before that you have to know what is really necessary so put a probability onto every measurement and not try to be too paranoid.
I also don't understand the fuss, unless it is for a banking application that needs to adhere to some hard standard for certification (in which case you need help from people specialised in that area anyway). Having critical information in config files (/etc, ~/.ssh, the server's HTTPS private certificates and so on) is almost unavoidable and why should you not trust your machine ? The next question then is, can you trust keeping a password in RAM ? If security is managed well on the machine and you don't do stupid things, you should be OK. Some sysadmin friend could do an audit, for example. If someone gets (root) access to the machine that would be a catastrophic event anyway ;-) Sven
Norbert
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
I made a Smalltalk implementation of the Blowfish cipher (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29) here: http://www.squeaksource.com/Cryptography/Blowfish-PaulDeBruicker.8.mcz It would benefit from being NativeBoost-ified but it works and would do what you want. Also I haven't tried it in Pharo 2 or 3 but it works in Squeak, Pharo 1.4, & Cuis. -- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi paul could you migrate the code to SmalltalkHub because this would be good to have a good set of packages available? Is there tests? Because I could port it on Pharo 2.0 and 3.0. Stef On Jul 13, 2013, at 4:54 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:
I made a Smalltalk implementation of the Blowfish cipher (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29) here: http://www.squeaksource.com/Cryptography/Blowfish-PaulDeBruicker.8.mcz
It would benefit from being NativeBoost-ified but it works and would do what you want.
Also I haven't tried it in Pharo 2 or 3 but it works in Squeak, Pharo 1.4, & Cuis.
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Thanks Paul! THere are test and they all pass (7 tests) in Pharo 2.0! Excellent. It would be nice to have a ConfigurationOf also? I guess my use-case if the one of #testEncryptDecrypt, right? If we put it to SmalltalkHub we can also write a quick tutorial :) Btw..for my scenario I don't care at all about speed ;) On Sun, Jul 14, 2013 at 8:16 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi paul
could you migrate the code to SmalltalkHub because this would be good to have a good set of packages available? Is there tests? Because I could port it on Pharo 2.0 and 3.0.
Stef
On Jul 13, 2013, at 4:54 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:
I made a Smalltalk implementation of the Blowfish cipher (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29) here: http://www.squeaksource.com/Cryptography/Blowfish-PaulDeBruicker.8.mcz
It would benefit from being NativeBoost-ified but it works and would do what you want.
Also I haven't tried it in Pharo 2 or 3 but it works in Squeak, Pharo 1.4, & Cuis.
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
Hi Mariano, You shouldn't use it. Its broken. I didn't realize until just now. But I also haven't been using it. To encrypt the db password do enc:=Blowfish encryptString:'myDbPassword' with: 'mySecretKey' and to decrypt it later do Blowfish decryptToString: enc with: 'mySecretKey' But if you decrypt it with the key '1234' you get 'ë "~ýãîfword' which shows its only encrypting the first 8 bytes. And if your db password is 30 chars long like this one: '123456789012345678901234567890' then the leaked info is the last 22 numbers. The tests aren't covering this error yet. I'll mess with it sometime soon and get it sorted but for now its broken and shouldn't be used. Unless your DB password is 8 bytes or less. -- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Sun, Jul 14, 2013 at 9:46 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:
Hi Mariano,
You shouldn't use it. Its broken. I didn't realize until just now. But I also haven't been using it.
ohh what a pity :( I was planning to use it!
To encrypt the db password do
enc:=Blowfish encryptString:'myDbPassword' with: 'mySecretKey'
and to decrypt it later do
Blowfish decryptToString: enc with: 'mySecretKey'
I tried that. But..in my case, the "enc" I should store it in a file, so I need the string rather than the bytearray. So I did: | enc encryptedString decr decrString | enc:=Blowfish encryptString:'test' with: 'mySecretKey'. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. and encryptedString is that I would store in the file. And then to decrypt: decr := Blowfish decryptString: encryptedString with: 'mySecretKey'. decrString := decr asByteArray asString. Transcript show: ' decrypted: ', decrString; cr. but there are several problems: 1) I cannot encrypt passwords smaller than 8 characters neither bigger (as you noted). Not a big problem. But I may be using this same algorithm for something else in where I may have smaller paswords (but I am not sure). 2) I am not sure I am doing fine with the encoding and the strings... (conversion between bytearray and string) 3) the decryption doesn't work for me... :( If you fix, please let me know!! If I can help/test, also. Thanks,
But if you decrypt it with the key '1234' you get
'ë "~ýãîfword'
which shows its only encrypting the first 8 bytes. And if your db password is 30 chars long like this one:
'123456789012345678901234567890' then the leaked info is the last 22 numbers.
The tests aren't covering this error yet. I'll mess with it sometime soon and get it sorted but for now its broken and shouldn't be used. Unless your DB password is 8 bytes or less.
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote
On Sun, Jul 14, 2013 at 9:46 PM, Paul DeBruicker <
pdebruic@
> wrote:
Hi Mariano,
You shouldn't use it. Its broken. I didn't realize until just now. But I also haven't been using it.
ohh what a pity :( I was planning to use it!
To encrypt the db password do
enc:=Blowfish encryptString:'myDbPassword' with: 'mySecretKey'
and to decrypt it later do
Blowfish decryptToString: enc with: 'mySecretKey'
I tried that. But..in my case, the "enc" I should store it in a file, so I need the string rather than the bytearray. So I did:
| enc encryptedString decr decrString | enc:=Blowfish encryptString:'test' with: 'mySecretKey'. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr.
and encryptedString is that I would store in the file.
And then to decrypt:
decr := Blowfish decryptString: encryptedString with: 'mySecretKey'. decrString := decr asByteArray asString. Transcript show: ' decrypted: ', decrString; cr.
but there are several problems:
1) I cannot encrypt passwords smaller than 8 characters neither bigger (as you noted). Not a big problem. But I may be using this same algorithm for something else in where I may have smaller paswords (but I am not sure). 2) I am not sure I am doing fine with the encoding and the strings... (conversion between bytearray and string) 3) the decryption doesn't work for me... :(
If you fix, please let me know!! If I can help/test, also.
Thanks,
-- Mariano http://marianopeck.wordpress.com
Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad the byte array, and for longer strings I'll need to make it use cipher block chaining: (https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_c...) If you change #decryptString:with: to: Blowfish class>>decryptString: aString with: aKey |decryptedData | decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey asByteArray ). ^String fromByteArray: decryptedData asByteArray . Then this workspace code should work: | enc encryptedString dkey decrString | key:='mySecretKey'. enc:=Blowfish encryptString:'12345678' with: key. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. decrString:=Blowfish decryptString: encryptedString with: key. Transcript show: ' decrypted: ', decrString; cr. But with the password 'test' it will always fail because I'm not yet padding the byte array to a multiple of 8 bytes before encrypting it. Thanks for your patience Paul -- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad the byte array, and for longer strings I'll need to make it use cipher block chaining: ( https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_c... )
Ok, I imagined something like that. Thanks for the explanation. For my usecase, I think this is not the more critical thing since I would use a 8 character password for sure :)
If you change #decryptString:with: to:
Blowfish class>>decryptString: aString with: aKey |decryptedData | decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey asByteArray ). ^String fromByteArray: decryptedData asByteArray .
Then this workspace code should work:
| enc encryptedString dkey decrString | key:='mySecretKey'. enc:=Blowfish encryptString:'12345678' with: key. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. decrString:=Blowfish decryptString: encryptedString with: key. Transcript show: ' decrypted: ', decrString; cr.
Thanks!! That worked. Now...there is no problem with the encoding then? Because I would need to store/retrieve the string from a file stream...so I didn't know if I should use a TextConverter or not. Thanks in advance,
But with the password 'test' it will always fail because I'm not yet padding the byte array to a multiple of 8 bytes before encrypting it.
Thanks for your patience
Paul
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? or it make sense to put a "salt" together with the string to ecnrypt? Thanks On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad the byte array, and for longer strings I'll need to make it use cipher block chaining: ( https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_c... )
Ok, I imagined something like that. Thanks for the explanation. For my usecase, I think this is not the more critical thing since I would use a 8 character password for sure :)
If you change #decryptString:with: to:
Blowfish class>>decryptString: aString with: aKey |decryptedData | decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey asByteArray ). ^String fromByteArray: decryptedData asByteArray .
Then this workspace code should work:
| enc encryptedString dkey decrString | key:='mySecretKey'. enc:=Blowfish encryptString:'12345678' with: key. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. decrString:=Blowfish decryptString: encryptedString with: key. Transcript show: ' decrypted: ', decrString; cr.
Thanks!! That worked. Now...there is no problem with the encoding then? Because I would need to store/retrieve the string from a file stream...so I didn't know if I should use a TextConverter or not.
Thanks in advance,
But with the password 'test' it will always fail because I'm not yet padding the byte array to a multiple of 8 bytes before encrypting it.
Thanks for your patience
Paul
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Am 15.07.2013 um 22:42 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? or it make sense to put a "salt" together with the string to ecnrypt?
That is up to you. That is what I was trying to explain to you. You always need a key/secret to encrypt. A salt is just a little more of information that diverses that outcoming value of a hash. A hash is a one way calculation from an input string to an output string in a uniform way. Meaning the same input with same algorithm is always the same output. One way to test a cryptographic string is using rainbow tables. These are big tables consisting of the outcome of hash calculations (fast compare vs. slow calculate). By adding a salt you make it harder to have these tables because you still need to calculate or need to expand the tables of results. But as a salt is an input to the hashing function it only works if the salt is included in the input _and_ the output. Meaning you need to add the salt to the output. In the unix passwd file for instance the first two character of the password hash is the salt. You take it from encrypted string and encrypt the password with the salt to get the output you can compare with the encrypted string (the string with salt stripped off). So in any algorithm you can add a salt and prefix the output with the same salt. The difference between algorithms is how expensive they are to calculate. The best algorithm takes an awful time to compute. In this case if you send the right password it takes an acceptable amount of time to verify (one calculation) but if someone tries to brute force your password it will take way too long to make it feasible to try. To encrypt something between two parties some information needs to be shared. If the algorithm use is shared you need to tranfer the password in cleartext to the second instance and the second instance can encrypt it the same way and compare. Sharing a secret between the parties you can transfer the encrypted string because the other part can decrypt the string and can compare the password (but you have to transfer the secret somehow). In an asymmetric environment where there is a key pair where everything one key encrypts the other key can decrypt you just can share the other key to the second instance and you are able to transfer an encrypted string. So whatever you do you need to decide what approach to use and what information is best to share. If you look on SSL you have everything in combination. First there is an asymmetric key exchange (expensive) that is used to exchange a shared secret. After the negotiation the network will be encrypted using the shared secret which is much less expensive saving CPU cycles. Norbert
On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad the byte array, and for longer strings I'll need to make it use cipher block chaining: (https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_c...)
Ok, I imagined something like that. Thanks for the explanation. For my usecase, I think this is not the more critical thing since I would use a 8 character password for sure :)
If you change #decryptString:with: to:
Blowfish class>>decryptString: aString with: aKey |decryptedData | decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey asByteArray ). ^String fromByteArray: decryptedData asByteArray .
Then this workspace code should work:
| enc encryptedString dkey decrString | key:='mySecretKey'. enc:=Blowfish encryptString:'12345678' with: key. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. decrString:=Blowfish decryptString: encryptedString with: key. Transcript show: ' decrypted: ', decrString; cr.
Thanks!! That worked. Now...there is no problem with the encoding then? Because I would need to store/retrieve the string from a file stream...so I didn't know if I should use a TextConverter or not.
Thanks in advance,
But with the password 'test' it will always fail because I'm not yet padding the byte array to a multiple of 8 bytes before encrypting it.
Thanks for your patience
Paul
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Jul 15, 2013, at 10:42 , Mariano Martinez Peck wrote:
Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? or it make sense to put a "salt" together with the string to ecnrypt?
Thanks
No. Salts (and one-way hashed passwords) only make sense when you're the one authenticating login credentials, not when you're the one tasked with providing said credentials. There is *no* good way of securely "remembering" passwords for a client, other than (as Norbert said) restricting access to the place the password is stored using permissions. As such, you could just as well store the password in-image, and keep it in a restricted location/run as separate user with access to that location. Keeping a blowfish key in a separate file, used to decrypt some in-image value to get the actual password, only buys you safety against 1. Someone gaining access to the image, but not the file 2. Reading cleartext passwords from the process memory directly. For 1), it should be obvious that it is mostly a moot point, if you place the image in a similarly restricted location anyways. For 2), I *think*, no modern OS lets you read another users process' memory (on purpose *) unless they have root access/logged in as same user, in which case, well, you're already screwed. Sure, there might be exploitable bugs that lets an attacker read memory of other processes, but such usually have a high fix-priority. It also means, in order to never end up keeping the plaintext password in memory for prolonged durations (and vulnerable to being read), you have to re-read the file every time you provide the password, so the image must be run as a user with access to the files location anyways. A usable alternative exists if you already use client-side credentials for your app, provided manually when a user signs in. Then, in addition to salt + hashed password value for your users, you can store the db-passwords encrypted with a symmetric cipher (like blowfish) using the users password as key. At login time, after authenticating, you then also decrypt the db-passwords, and keep them available while the application runs. This of course, is still vulnerable to potential memory dumps, but you never store the passwords in an easily reversible form if an attacker ever gains access to the files. If introduced to an existing application , it also means you'd have to keep the db-passwords around in plantext for awhile, to create encrypted values for users on first login (if non-existing), after that passwords should already be available in memory for calculation of new encrypted values when changing passwords/ adding new users. (due to those being allowed to do so, being logged in already) If it's a non-deployed app, the encrypted value for some super-user can be calculated before deployment, and the data required to decrypt the db-passwords never kept on disk in production. Cheers, Henry
I feel compelled to revive this old (almost 10 years!) thread because Iâm faced with a similar problem and certain points seem unresolved. Assuming that one needs the actual password in the image (in my case to authenticate via IMAP), Norbertâs suggestion to have a helper app that runs with elevated privileges makes sense, but Iâm wondering about a few other comments: * Sven mentioned that itâs common to have sensitive info âlying aroundâ on the filesystem, with .ssh being an example. However, my (non-expert) understanding is that the best practice to add a passphrase to oneâs private key protects against just such situations as we consider here, no? * There seems to be a hard distinction drawn between memory and disk storage. However, this being Smalltalk, this seems only to be the case if the image is guaranteed never to be saved, otherwise its memory, including any plaintext sensitive information, would end up on disk. As I was thinking through my use case, I was considering, for example, storing the password in a non-string collection e.g. ByteArray, so that I could use the password and zero it out in memory right afterward.
If you use OpenSSL (or any other crypto library) they provide secure memory allocation that can be used to store sensitive data such as keys, initialization vectors, etc. You can even encrypt the data stored there. Once freed, that allocation wipes the memory used. Of course there would still be the case of the String/ByteArray in the image or in method contexts when passed as arguments, for that there isn't much to do except if you pass that "allocation object" as parameter and convert it right to a String at the moment of using it, or better, map it and pass it to another FFI call. Also there is the risk of stack traces leaking sensitive information. It would be convenient to have a "SecureString" that is never dumped (and also has its secure allocation outside of the heap). Depending on where you run your software, having a password in the heap that is read from a file with the right permissions is all you need. I never needed to do any of the above, but I know some people that do, especially for desktop apps. YMMV. Best regards! Esteban A. Maringolo On Tue, Sep 20, 2022 at 11:59 AM <sean@clipperadams.com> wrote:
I feel compelled to revive this old (almost 10 years!) thread because Iâm faced with a similar problem and certain points seem unresolved.
Assuming that one needs the actual password in the image (in my case to authenticate via IMAP), Norbertâs suggestion to have a helper app that runs with elevated privileges makes sense, but Iâm wondering about a few other comments:
Sven mentioned that itâs common to have sensitive info âlying aroundâ on the filesystem, with .ssh being an example. However, my (non-expert) understanding is that the best practice to add a passphrase to oneâs private key protects against just such situations as we consider here, no?
There seems to be a hard distinction drawn between memory and disk storage. However, this being Smalltalk, this seems only to be the case if the image is guaranteed never to be saved, otherwise its memory, including any plaintext sensitive information, would end up on disk.
As I was thinking through my use case, I was considering, for example, storing the password in a non-string collection e.g. ByteArray, so that I could use the password and zero it out in memory right afterward.
Ron Teitelbaum made a clever solution to resisting memory-scanning attacks when using private keys in an image. Upon asking KeyHolder holdKey: yourPrivateKey, it forks off a while loop which generates a random sequence of bytes (ByteArray) to encrypt yourPrivateKey with it. It then delays 100ms, decrypts the key and immediately re-encrypts it with a new set of random bytes (two new memory locations), and wiping the old random and old key ByteArray's. Repeat. The result: a memory-scanner attack needs to find both pieces of information (the random number and the encrypted key) in the image memory within 100ms. Obviously this consumes some processing power and garbage collection, but it's not noticeable. On shutdown, all instances are automatically wiped, saved images are clean of private keys. It's part of the CryptographyCore package on SqueakSource. http://www.squeaksource.com/Cryptography/CryptographyCore-cmm.9.mcz On Tue, Sep 20, 2022 at 9:59 AM <sean@clipperadams.com> wrote:
I feel compelled to revive this old (almost 10 years!) thread because Iâm faced with a similar problem and certain points seem unresolved.
Assuming that one needs the actual password in the image (in my case to authenticate via IMAP), Norbertâs suggestion to have a helper app that runs with elevated privileges makes sense, but Iâm wondering about a few other comments:
-
Sven mentioned that itâs common to have sensitive info âlying aroundâ on the filesystem, with .ssh being an example. However, my (non-expert) understanding is that the best practice to add a passphrase to oneâs private key protects against just such situations as we consider here, no? -
There seems to be a hard distinction drawn between memory and disk storage. However, this being Smalltalk, this seems only to be the case if the image is guaranteed never to be saved, otherwise its memory, including any plaintext sensitive information, would end up on disk.
As I was thinking through my use case, I was considering, for example, storing the password in a non-string collection e.g. ByteArray, so that I could use the password and zero it out in memory right afterward.
I added it here: MCHttpRepository location: 'http://smalltalkhub.com/mc/Cryptography/Blowfish/main' user: '' password: '' And added you and Mariano as contributors. Stéphane Ducasse wrote
Hi paul
could you migrate the code to SmalltalkHub because this would be good to have a good set of packages available? Is there tests? Because I could port it on Pharo 2.0 and 3.0.
Stef
On Jul 13, 2013, at 4:54 PM, Paul DeBruicker <
pdebruic@
> wrote:
I made a Smalltalk implementation of the Blowfish cipher (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29) here: http://www.squeaksource.com/Cryptography/Blowfish-PaulDeBruicker.8.mcz
It would benefit from being NativeBoost-ified but it works and would do what you want.
Also I haven't tried it in Pharo 2 or 3 but it works in Squeak, Pharo 1.4, & Cuis.
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp469... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (9)
-
Chris Muller -
Esteban Maringolo -
Henrik Johansen -
Mariano Martinez Peck -
Norbert Hartl -
Paul DeBruicker -
sean＠clipperadams.com -
Stéphane Ducasse -
Sven Van Caekenberghe