Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Sep 2016 16:36:50 -0400
From: Scott Arciszewski <>
Subject: Re: Blog Post about Password Resets

On Wed, Sep 21, 2016 at 4:53 AM, Per Thorsheim <> wrote:

> Den 20.09.2016 21.39, skrev Scott Arciszewski:
> > Hello,
> >
> > I'll not make a regular habit of doing this, but I thought this blog
> > post might be of interest to the readers of this mailing list:
> >
> >
> knot-secure-account-recovery-made-simple
> >
> > It discusses the common design flaws with password reset features and
> > proposes how to implement them securely. There's a TL;DR at the end.
> >
> > I'd greatly appreciate any feedback or criticism anyone can offer.
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises <>
> <top or bottom quoting - that's the eternal question!>
> Ok, I really like your split-token idea. Bonus points for applying
> constant-time to remove a potential timing leak.
> Agree with Evan Johnson
> that opt in password
> reset is NOT something you would do by default, but as opt out I say
> "yes please!". With proper explanations of what it actually means for
> your security.
> patpro also has a
> point on the odds of SQLi into tokenDB vs email account takeover. My
> take is that if your split-token idea can easily (cost/time) be
> implemented, and chances of FUBAR by junior.devs are small, I say its a
> quickwin.
> Something to add for the OWASP pwd reset cheat sheet as soon as this
> list is done debating and attacking your proposal?
> --
> Best regards,
> Per Thorsheim
> Founder of
> Phone: +47 90 99 92 59 (Use Signal!)
> Twitter: @thorsheim

​Following the Twitter discussion (which ended up largely being moved to a
gist because tweets were unsuitable for one of my replies), I added an
addendum to the post:

​The question that was raised was, rephrased, "You talked about read-only
SQL injection mitigation, but what about read-write exploit mitigation?"

In general, I believe "read/write SQL injection" is game over for your

The problem should be solved upstream (i.e. by preventing the SQL injection
vulnerabilities) rather than in the account recovery process.

​If you want to go the extra mile, switching SHA256(verifier) for
HMAC-SHA256(userid || verifier, SOME_SECRET_KEY) where SOME_SECRET_KEY is
accessible only by the application code (not stored in a database), but
also not checked into version control software​
​, is probably the most practical enhancement you could make. It's an
appropriate use of these cryptography primitives, and it reliably ties the
value stored in the database to the user ID.

Anything further most likely isn't worth it.
I don't see any practical gain in adding encryption to the mix, and JWT
seems like a risky proposition given the protocol flaws (e.g. alg header)
that have surfaced since its standardization.

The other noteworthy response, from Egor Homakov, ​was that he couldn't see
most applications adopting the split-token approach. A bit cynical, but
most incumbent web application platforms have great inertia towards
adopting better security practices (i.e. WordPress still uses 8192 rounds
of salted MD5 [1]), so at least for the short term, that's probably true.

​The question is: ​do we want to make this prediction false in the

Per mentioned updating the OWASP password reset cheat sheet; I still have
an active Wiki account due to having volunteered for the Orlando, FL
chapter (during Tony Turner's leadership), so I can already make the
necessary changes. However, I'd like to hear more feedback and criticism
before I'd even feel comfortable recommending an amendment to their cheat

 - [1]:

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <>​

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.