[web2py] Re: password storage with per-user salt

2011-11-01 Thread Massimo Di Pierro
I have a pending patch for per-user last. it is in my todo list On Nov 1, 10:32 pm, Eli Collins wrote: > I'm coming slightly late to this thread, but wanted to add a note... > > > If we did implement this approach, the next question is, could we also > > implement a scheme whereby if the algo

[web2py] Re: password storage with per-user salt

2011-11-01 Thread Eli Collins
I'm coming slightly late to this thread, but wanted to add a note... > If we did implement this approach, the next question is, could we also > implement a scheme whereby if the algo is changed, when someone goes to > change their password, the system can confirm that the old password is > pr

[web2py] Re: password storage with per-user salt

2011-09-29 Thread Dave
I have the patch. I wasn't sure where to put the file, so I emailed it directly to you Massimo. The only thing that seems to be missing is updating the login_bare method to use the new hashing. The code is backward compatible with pre-exiting non-salted passwords. On Sep 29, 1:38 pm, Dave wrot

[web2py] Re: password storage with per-user salt

2011-09-29 Thread Dave
Hm. yeah, good point. Let me do some cleaning up on what I have... and make sure it will be backward compatible with people doing requires=CRYPT on the password field. Then I'll send you a diff and see what you think. On Sep 29, 1:38 am, Massimo Di Pierro wrote: > Perhaps the safer bet is t

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Massimo Di Pierro
Perhaps the safer bet is to continue along your original idea of tweaking auth. In general it may not be a good idea to have validators access the record before validation, it could cause DoS problems. Massimo On Sep 28, 9:47 pm, Dave wrote: > I struggled with that a little bit as I was followi

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Dave
I struggled with that a little bit as I was following the application flow particularly in the login method. All the other methods (well, except the reset request method) are after login and there is already a user object. That's why it was so easy for me to just put onvalidate modifications in t

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Massimo Di Pierro
Anyway, I have not looked into this with sufficient detail to know what is cleaner (or dirtier). I we pass an optional record argument to validate we will need to change sqlhtml as well. Massimo On Sep 28, 8:11 pm, Dave wrote: > That may be an even better way to accomplish this task.  I actually

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Dave
That may be an even better way to accomplish this task. I actually considered using some sort of self-reference first, but didn't find it there. On Sep 28, 9:00 pm, Massimo Di Pierro wrote: > I was thinking about this... how about editing the validate function > in dal.py and allow it to pas

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Massimo Di Pierro
I was thinking about this... how about editing the validate function in dal.py and allow it to pass the current record to the validators? We cannot change the APIs but a validator is an object so we can just pass the current record by attaching it as an attribute to the validator object. CRYPT coul

[web2py] Re: password storage with per-user salt

2011-09-28 Thread Dave
I've made this work. I still need a little bit of time to make it backward compatible with non-salted passwords though. First things first, I had to disable the CRYPT validator. Although it makes handling passwords easier, encrypting them at the validator level really limits a lot of account enf

[web2py] Re: password storage with per-user salt

2011-09-21 Thread Dave
Well clearly I've sparked plenty of discussion. I am working on this to fit my app need. Once I have a working model that doesn't break other applications that use the default hashing and CRYPT functions I'll post my work. As others have commented, the typical way for storing the password would

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread pbreit
I think if you were going to do client side hashing you would send out a unique "secret" on each request. I don't think this is necessary at this time. At least SSL gives those who want to be secure the option.

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread Michele Comitini
Doing as in the article above, if x compromises the server x can login since the hashed password *are the secret* . To do things right the hash of a secret arriving from the client must be computed every time on the server before comparison. SSL hides the secret so it's a good choice. mic 2011/

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread pbreit
That should be "for those who do not use ssl".

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread pbreit
Sending passwords over SSL should be sufficient in most cases. Hashing the password on the client side is slightly better and would provide better protection for those who use SSL (wouldn't want to encourage that, though). I think the only immediate need, though, is support for per-password sal

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread David J
Why double salt. That's the point of SSL. we should only be concerned with application level details not transport On Sep 21, 2011 10:27 AM, "Anthony" wrote: > Yes, I think the salting and hashing we're discussing is meant to protect > the passwords once on the server (i.e., if the server/database

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread Anthony
Yes, I think the salting and hashing we're discussing is meant to protect the passwords once on the server (i.e., if the server/database is compromised). We'd need additional protection to protect them in transit. Another option would be login over SSL, no? Anthony On Wednesday, September 21,

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread Michele Comitini
Plain WRONG. Even the guy knows it: " Note that a hacker could still sniff the hashed password going over the network, and use that hash later to send to the server and impersonate you. But at least the hacker can't use your real password for other purposes." You can try with two salts. One of t

[web2py] Re: password storage with per-user salt

2011-09-21 Thread Anthony
+1 On Wednesday, September 21, 2011 2:43:20 AM UTC-4, pbreit wrote: > > It might not be a bad idea to improve password handling at this time. I > think the biggest problem is that password hases are not currently salted. > The hmac_hash function appears to take a salt but I didn't see any eviden

[web2py] Re: password storage with per-user salt

2011-09-21 Thread Ross Peoples
If we are talking about improving security a bit, I would recommend that we also hash passwords in the browser before sending them to the server. I just read about this here: http://dustwell.com/how-to-handle-passwords.html Basically, when a user logs in, registers, or otherwise enters a passwo

Re: [web2py] Re: password storage with per-user salt

2011-09-21 Thread João Gulineli
I had the same problem as you, I think. We wrote a cutomize login method ,attached, to check if the entered password was the same that was stored in the database, we use the http://packages.python.org/passlib/lib/passlib.hash.sha512_crypt.html. If you wish you could write a new validator to encrypt

[web2py] Re: password storage with per-user salt

2011-09-20 Thread pbreit
It might not be a bad idea to improve password handling at this time. I think the biggest problem is that password hases are not currently salted. The hmac_hash function appears to take a salt but I didn't see any evidence that is ever actually used. The Django model seems sufficient: https://d

[web2py] Re: password storage with per-user salt

2011-09-20 Thread Massimo Di Pierro
This will be useful put presents a technical difficulty because of the way CRYPT works. CRYPT is the validator that check is a password is valid, and it does not know what is stored in db therefore it does not know the salt. Anyway, let me know if you have a suggestion. Massimo On Sep 20, 9:25 pm