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 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 <[hidden email]>:
"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 <[hidden email]> 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 <[hidden email]> wrote:
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 <[hidden email]>:
I'm curious about your reply to my mail :) Norbert
|
In reply to this post by NorbertHartl
On Fri, Jul 12, 2013 at 11:44 AM, Norbert Hartl <[hidden email]> wrote:
Indeed.
I want to prevent others from being able to read them.
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 :)
yes
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.
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 <[hidden email]>: 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. 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.
My pleasure! Norbert |
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?
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.
I understand.
Mariano http://marianopeck.wordpress.com |
In reply to this post by NorbertHartl
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?
Mariano http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
On Fri, Jul 12, 2013 at 2:41 PM, Mariano Martinez Peck <[hidden email]> wrote:
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,
Mariano http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
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. |
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 <[hidden email]> 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-tp4698499p4698608.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Thanks Paul! 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 <[hidden email]> wrote: Hi paul Mariano http://marianopeck.wordpress.com |
In reply to this post by Stéphane Ducasse
I added it here:
MCHttpRepository location: 'http://smalltalkhub.com/mc/Cryptography/Blowfish/main' user: '' password: '' And added you and Mariano as contributors.
|
In reply to this post by Mariano Martinez Peck
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. |
On Sun, Jul 14, 2013 at 9:46 PM, Paul DeBruicker <[hidden email]> wrote:
ohh what a pity :( I was planning to use it!
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 |
In reply to this post by Mariano Martinez Peck
Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <[hidden email]>: 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
|
On 15 Jul 2013, at 16:29, Norbert Hartl <[hidden email]> wrote: > > Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <[hidden email]>: > >> >>> >>> 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 > |
In reply to this post by Mariano Martinez Peck
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_chaining_.28CBC.29) 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 |
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 :)
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,
Mariano http://marianopeck.wordpress.com |
Free forum by Nabble | Edit this page |