Hi,
> 1. The author of the patch clearly thinks that security consists of
> sprinkling magic SHA-1 HMAC challenge response pixie dust over the code
> in a random fashion. This means that any revised patch must be viewed
> with suspicion.
>
I don't know why you feel the need to be so rude. Let m
Doug's analysis of the patch is right on, but he doesn't go far enough.
1. The author of the patch clearly thinks that security consists of
sprinkling magic SHA-1 HMAC challenge response pixie dust over the code
in a random fashion. This means that any revised patch must be viewed
with suspicion.
Hi,
> I've had a look at your patch, and I've noticed a couple of security
> holes... If your only desire is to prevent eavesdropping of passwords, I
> suggest you use SSL, as this is a system that actually works (if used
> correctly).
Although it has limitations, some people want this feature.
I've had a look at your patch, and I've noticed a couple of security
holes... If your only desire is to prevent eavesdropping of
passwords, I suggest you use SSL, as this is a system that actually
works (if used correctly).
For each issue, I'll address the problem as if it stands apart to gi
Hi,
Your timing is interesting, I'm just about to submit a patch to
support JavaScript hashing of passwords, which interacts with this.
If you use random per-user salts, which is the common approach, JS
hashing requires an Ajax request at login. Not an enormous problem,
but not ideal either.
If
Okay, done... I recommend the base64 version, as it's backwards
compatible and standards compliant...
Doug
On May 19, 2009, at 4:36 PM, Douglas Mayle wrote:
> So, I've finished it off and submitted the patch to issue 85:
> http://bugs.repoze.org/issue85
>
> In absence of comments, I decided fo
So, I've finished it off and submitted the patch to issue 85:
http://bugs.repoze.org/issue85
In absence of comments, I decided for backwards compatibility over
standards compliance and used hex storage for the data. I could
modify this to switch to base64 for both, since the unsalted SHA1 has
On further inspection, it uses a hex form of the digest. Is there any
preference between that and RFC 2307 schemes, which use base64 for
encoding?
Doug
On May 19, 2009, at 1:57 PM, Douglas Mayle wrote:
> Hello all,
> I've noticed that the default_password_compare in sql.py uses
> unsa
Hello all,
I've noticed that the default_password_compare in sql.py uses
unsalted hashes, and so I was planning to submit a patch to fix that.
I figured, however, that it might be a good idea to provide a
default_password_hasher so that users of repoze.who could just import
that in
