Hi guys. I need to be able to store a password as part of a method. Say I need to be able to do
'thisIsMyPassword' encrypted -> 'dasdafjewrhjk34wh5435345345345ewfsfs' Then I can write the method: MyClass >> myPassword ^ 'dasdafjewrhjk34wh5435345345345ewfsfs' decrypted It should have a kind of public key somehow so that someone cannot easily decrypt it. How can I do that in Pharo? I am totally newbie with all this stuff. Thanks, -- Mariano http://marianopeck.wordpress.com |
Hi Mariano,
I've made a FFI library on Squeaksource that works on Linux. http://www.squeaksource.com/Cryptography/PasswordHashingFFI-PaulDeBruicker.8.mcz You need to install the 32 bit versions of libcrypt and libxcrypt if you're using a 64 bit linux os. Using crypt can hash passwords using MD5, DES, SHA256, SHA512. Using libxcrypt can hash passwords using bcrypt. If its for a new installation use bcrypt or SHA512 to hash the passwords. bcrypt is better because its slower, and allegedly future proof. to get a hashed password use BCryptLinuxFFI bcrypt:'mypassword' to check it against a stored hash use: BCryptLinuxFFI check:'mypassword' against: storedHash |
Thanks Paul. It looks interesting.
On Mon, Oct 24, 2011 at 6:38 PM, Paul DeBruicker <[hidden email]> wrote: Hi Mariano, -- Mariano http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
Someone may have already replied as I am writing this on a plane but 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)
You just compare encrypted passwords to see if they are equal. eg password:= SecureHashAlgorithm new hashMessage: aClearTextPass. then later on you check password = SecureHashAlgorithm new hashMessage: aPasswordAttempt. On Oct 24, 2011, at 11:44 PM, Mariano Martinez Peck wrote: Hi guys. I need to be able to store a password as part of a method. Say I need to be able to do |
On 25 October 2011 04:43, mail list <[hidden email]> wrote:
To make it slightly more secure, you can put a little salt in it:
salt := 'Some random string I just cam up with 123' password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. check: password = SecureHashAlgorithm new hashMessage: salt, aPasswordAttempt.
That way you make it more difficult for the attacker to brute-force guess the password when the user supplies a weak password. Milan Mimica http://sparklet.sf.net |
Thanks for your answers, I am learning.
Alexandre On 25 Oct 2011, at 03:40, Milan Mimica wrote: > On 25 October 2011 04:43, mail list <[hidden email]> wrote: > Someone may have already replied as I am writing this on a plane but 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) > > You just compare encrypted passwords to see if they are equal. > eg > password:= SecureHashAlgorithm new hashMessage: aClearTextPass. > > then later on you check > password = SecureHashAlgorithm new hashMessage: aPasswordAttempt. > > > To make it slightly more secure, you can put a little salt in it: > > salt := 'Some random string I just cam up with 123' > > password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. > > check: > password = SecureHashAlgorithm new hashMessage: salt, aPasswordAttempt. > > That way you make it more difficult for the attacker to brute-force guess the password when the user supplies a weak password. > > > -- > Milan Mimica > http://sparklet.sf.net -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by Mariano Martinez Peck
"Milan Mimica"<[hidden email]> wrote:
> To make it slightly more secure, you can put a little salt in it: > > salt := 'Some random string I just cam up with 123' > > password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. > > check: > password = SecureHashAlgorithm new hashMessage: salt, aPasswordAttempt. > > That way you make it more difficult for the attacker to brute-force guess > the password when the user supplies a weak password. Note though that if the intent is to hardcode the hash (and presumably the salt as well) in the code it kinda defeats the purpose of the salt. Salt doesn't need to be secret, but it should be sufficiently unpredictable, so that the attacker cannot pre-compute the hashes easily. If the salt is fixed and well known, then it doesn't help. I guess my main point is that hardcoding the password in any shape or form is nearly useless, you may as well not bother. What is the goal ? What are you trying to protect against ? Answers to these questions should guide you to a solution. Once you pick a solution you should then think about how it fails and what can you do when it happens (What will you do when your hardcoded password becomes compromised ?). False security is often worse than no security. HTH, Martin |
In reply to this post by Mariano Martinez Peck
"Milan Mimica"<[hidden email]> wrote:
> Yes, having the salt randomly generated and storing it with a hash is a > better idea. Note taken. Combining it with a fixed salt (and trying to keep > it secret) is even better. Keeping a hardcoded salt in the image running on > the remote machine serving WEB pages makes it quite secret IMO. I was referring to Mariano's intent (at least how I understand it) to hardcode it "in code". If he's confident he'll be able to keep the code secret then hey may as well have the password in it in plain text, hashing it with or without salt, doesn't make much difference IMO. Generating random salt and keeping a hashed password on a deployed system is a different scenario. In this case it's different and unpredictable with every deployment. When it's hardcoded it's the same everywhere. |
On Wed, Oct 26, 2011 at 12:36 AM, <[hidden email]> wrote: "Milan Mimica"<[hidden email]> wrote: Yes, indeed. I didn't give details. It was something very very stupid and simple. All I wanted to do is to commit a class I use to build my images and such class sets my username/password for squeaksource repotistories. But I didn't want to put such password in the code... at the end what I did (because my scenario is really stupid and only for me), is to read the password from a file in my machine :) hahahahha Anyway, I learn from the thread :) Generating random salt and keeping a hashed password on a deployed system is a different scenario. In this case it's different and unpredictable with every deployment. When it's hardcoded it's the same everywhere. -- Mariano http://marianopeck.wordpress.com |
> But I didn't want to put such password in the code... at
> the end what I did (because my scenario is really stupid and only for > me), is to read the password from a file in my machine :) hahahahha > That would be the kind of thing that belongs to a .pharoconf file in your /home directory ;) |
Off topic, but is the use of a .pharoconf file documented somewhere?
On Wed, Oct 26, 2011 at 05:12, Francois Stephany <[hidden email]> wrote: >> But I didn't want to put such password in the code... at >> the end what I did (because my scenario is really stupid and only for >> me), is to read the password from a file in my machine :) hahahahha >> > > That would be the kind of thing that belongs to a .pharoconf file in your > /home directory ;) > > -- ~JT |
On Wed, Oct 26, 2011 at 5:54 PM, John Toohey <[hidden email]> wrote: Off topic, but is the use of a .pharoconf file documented somewhere? No at all. Pharo does know nothing about it. It is just a plain file you can create and read stuff from there...just as any other file in any other language :)
-- Mariano http://marianopeck.wordpress.com |
If anyone is interested we have some stuff that can
read/write KeyedTrees as XML files (registry type of configs but with proper
objects (storeString based)).
Regards, Gary
|
In reply to this post by Mariano Martinez Peck
I guess the next question then, is it possible to define variables via
the VM command line, as with the Java VM, i.e. -Dhome=/home/cat and have a properties class that make these available to the applications. On Wed, Oct 26, 2011 at 12:05, Mariano Martinez Peck <[hidden email]> wrote: > > > On Wed, Oct 26, 2011 at 5:54 PM, John Toohey <[hidden email]> wrote: >> >> Off topic, but is the use of a .pharoconf file documented somewhere? > > No at all. Pharo does know nothing about it. > It is just a plain file you can create and read stuff from there...just as > any other file in any other language :) > >> >> On Wed, Oct 26, 2011 at 05:12, Francois Stephany >> <[hidden email]> wrote: >> >> But I didn't want to put such password in the code... at >> >> the end what I did (because my scenario is really stupid and only for >> >> me), is to read the password from a file in my machine :) hahahahha >> >> >> > >> > That would be the kind of thing that belongs to a .pharoconf file in >> > your >> > /home directory ;) >> > >> > >> >> >> >> -- >> ~JT >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- ~JT |
In reply to this post by Paul DeBruicker
Hi Paul,
I resume this old thread because it's not clear to me which package download to make BCryptLinuxFFI work In an other thread you point to: MCHttpRepository location: 'http://smalltalkhub.com/mc/Cryptography/Blowfish/main' user: '' password: '' but there is no BCryptLinuxFFI there. Can you help me please? Cheers Davide
|
Hi Davide, You need to be on Linux and On pharo or squeak - have a 32bit version of libxcrypt installed. - use this mcz http://www.squeaksource.com/Cryptography/PasswordHashingFFI-PaulDeBruicker.16.mcz or http://www.smalltalkhub.com/mc/Cryptography/Cryptography/main/PasswordHashingFFI-PaulDeBruicker.16.mcz (they're the same file) On GemStone - have a 64bit version of libxcrypt installed - use this mcz http://seaside.gemtalksystems.com/ss/Cryptography/PasswordHashingFFI-PaulDeBruicker.10.mcz The Blowfish stuff is an implementation of the cipher (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29). BCrypt uses blowfish as its encryption mechanisim, calling it tens to hundreds of thousands of times. The PasswordHashingFFI package also includes support for accessing the crypt(3) library so you can use SHA512 password hashing too if you like (or other mechanisms it supports like DES, MD5, etc) Hope this helps Paul |
Hi Paul, and just to be sure I understand...none of them could work as a two-way encryption, right? The only one is your Pharo's version of Blowfish but that only works with 8 chars long. Is it like this? Or is there any other two-way encryption?
Thanks! On Thu, Nov 21, 2013 at 1:35 PM, Paul DeBruicker <[hidden email]> wrote: Davide Varvello wrote Mariano http://marianopeck.wordpress.com |
Yes that's right. The PasswordHashingFFI stuff is all one way encryption. Blowfish is two way, and the current implementation only works for 8 byte chunks. I stopped working on it when the Smalltalk bcrypt implementation I wanted proved to be 5000x times slower than the FFI version. Someone needs to add the CBC part to Blowfish to encrypt longer strings. I do not know of another in image two way encryption scheme, but there may be something in the Cryptography repo. I'm not sure. |
In reply to this post by Paul DeBruicker
Paul,
I've already tried to load PasswordHashingFFI-PaulDeBruicker.16.mcz, but a warning shows: This package depends on the following classes: ExternalStructure You must resolve these dependencies before you will be able to load these definitions: BCryptLinuxFFI bcrypt: bcrypt:with: bcrypt:with:for: bcrypt:withSalt: checkPassword:against: defaultRounds ffiCrypt:with: generateBCryptIterations: generateBCryptSalt: generateRandomSalt iterationString: randomBCryptSaltData saltDataLength saltOutputLength CryptLinuxFFI checkPassword:against: des: des:with: ffiCrypt:with: md5: md5:with: prepareSalt: randomSalt randomSalt: saltDataLength sha256: sha256:with: sha512: sha512:with: Select Proceed to continue, or close this window to cancel the operation. Cheers Davide
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
Hash functions are one way (http://en.wikipedia.org/wiki/Cryptographic_hash_function) that's because usually you don't want someone can decrypt password. Cheers Davide
|
Free forum by Nabble | Edit this page |