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:
- 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) - put a little salt
- There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI
- 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:
- 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)
- put a little salt
- There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI
- 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.euwrote:
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:
- 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) - put a little salt
- There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI
- 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:
- 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)
- put a little salt
- There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI
- 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
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
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-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