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
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
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
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
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
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
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
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
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
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
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
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.
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/
That should be "for those who do not use ssl".
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
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
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,
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
+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
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
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
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
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
23 matches
Mail list logo