Thanks James!
I have pulled the recent changes to my repository and this is
working fine. I have tested with creating a new user
and I tried to login with the recently created user and this works
fine at my end. The entry looks like as follows:
galaxy=# select username,email,password from galaxy_user where email
= 'c...@gmail.com';
username | email | password
----------+----------------
+
-----------------------------------------------------------------------
cbio | c...@gmail.com | PBKDF2$sha256$10000$7CWpfEOjZ3xmRH6b
$ufFHb8Ax9GkVBGmnR5fq159NA3C4F6o0
This works fine.
With this new implementation, the new registration password hashes
are generated in PBKDF2. May be one can force
the existing users to reset the password, so that all users password
will be updated in the table. As you mentioned in the
previous mail, because of random salt generation in the password
hashing step, I don't think I can take all of the existing
user’s SHA-1 hashes, run them through the algorithm and replace them
with the updated hashes. I thought this would
be transparent to the users instead of forcing to reset the password.
any thoughts on this?
Thank you for timely help,
--Vipin
Rather than committing this directly I created the following pull
request:
https://bitbucket.org/galaxy/galaxy-central/pull-request/165/password-security-use-pbkdf2-scheme-with
It would be great if a couple of people could sign-off on it before
merging. I don't think I'm doing anything stupid, but a sanity check
is appreciated.
--
James Taylor, Assistant Professor, Biology/CS, Emory University
On Sun, May 5, 2013 at 12:12 PM, James Taylor
<ja...@jamestaylor.org> wrote:
> Vipin, I think the main problem here is that you cannot treat PBKDF2
> as a hash in this way. Every time you hash the same password you
get a
> different result because you are generating a new random salt.
> Instead, you need to decode the in database representation to
extract
> the salt and then do a comparison on the hashed part.
>
> I have this working in a backward compatible way, and I think it
is a
> good idea so I will be committing it to central shortly.
>
> --
> James Taylor, Assistant Professor, Biology/CS, Emory University
>
>
> On Thu, May 2, 2013 at 2:34 PM, Vipin TS <vipin...@gmail.com> wrote:
>>
>> Thanks James, I have updated the password of one user in
galaxy_user table
>> with the new algorithm,
>> I also adjusted the function "new_secure_hash" in
>> /lib/galaxy/util/hash_util.py in such a way that it returns
>> the new hash instead of sha1. Now I tried to login, it fails to
get the
>> account, I think there is something going
>> wrong in the password hash comparison. Can you please assit here.
>>
>> +++ b/lib/galaxy/util/hash_util.py Thu May 02 14:33:07 2013
-0400
>> @@ -25,13 +25,60 @@
>> Returns either a sha1 hash object (if called with no
arguments), or a
>> hexdigest of the sha1 hash of the argument `text_type`.
>> """
>> + import hashlib
>> + from os import urandom
>> + from base64 import b64encode, b64decode
>> + from itertools import izip
>> + from pbkdf2 import pbkdf2_bin
>> +
>> + SALT_LENGTH = 12
>> + KEY_LENGTH = 24
>> + HASH_FUNCTION = 'sha256'
>> + COST_FACTOR = 10000
>> +
>> if text_type:
>> + #return sha1( text_type ).hexdigest()
>> +
>> + sec_hash_1 = sha1( text_type ).hexdigest()
>> +
>> + if isinstance(sec_hash_1, unicode):
>> + sec_hash_1 = sec_hash_1.encode('utf-8')
>> + salt = b64encode(urandom(SALT_LENGTH))
>> +
>> + return 'PBKDF2${0}${1}${2}${3}'.format(
>> + HASH_FUNCTION,
>> + COST_FACTOR,
>> + salt,
>> + b64encode(pbkdf2_bin(sec_hash_1, salt, COST_FACTOR,
KEY_LENGTH,
>> getattr(hashlib, HASH_FUNCTION))))
>>
>>
>> thanks, Vipin
>>
>>
>>> That should be the only place, it is called from the some
methods of
>>> the User model object. So you could modify it to always hash new
>>> passwords in a different way, but check old passwords with sha1
first,
>>> then something else.
>>>
>>> Although it might be nice to move the functionality into
>>> security.validate_user_input since it is really specific to user
>>> passwords, especially with those changes.
>>>
>>> I'd be happy to see this go into main with sha256 or something
>>> similar. Also, we could consider adding a random per-user salt
field
>>> if you are really concerned about this.
>>>
>>> --
>>> James Taylor, Assistant Professor, Biology/CS, Emory University
>>>
>>>
>>> On Thu, May 2, 2013 at 10:21 AM, Vipin TS <vipin...@gmail.com>
wrote:
>>> > Hello dev-team,
>>> > I would like to add the different type of password encryption
to the
>>> > users
>>> > in my galaxy instance. I started working with the current
password
>>> > encoding
>>> > script:
>>> > /home/apps/galaxy-dist/lib/galaxy/util/hash_util.py
>>> >
>>> > I will keep the current sha1 and add another layer of
encryption to the
>>> > sha1
>>> > hash, otherwise I need to force all my users to change the
password and
>>> > follow the new hashing method.
>>> >
>>> > Can anyone please point me any other place/script which I missed
>>> > regarding
>>> > the encryption/decryption of user authentication.
>>> >
>>> > thanks in advance,
>>> > --/Vipin
>>> >
>>> >
>>> > ___________________________________________________________
>>> > Please keep all replies on the list by using "reply all"
>>> > in your mail client. To manage your subscriptions to this
>>> > and other Galaxy lists, please use the interface at:
>>> > http://lists.bx.psu.edu/
>>> >
>>> > To search Galaxy mailing lists use the unified search at:
>>> > http://galaxyproject.org/search/mailinglists/
>>
>>
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
