[yid]

Whenever I see "base64" mentioned in a security article, I get cautious.

The "split token" password reset is snake oil. Just store the hash of the token (ideally stretched like any password) in the database and mail the original token out. No need for "split tokens". A password reset token is a temporary password and should be treated like one.

[CiPHPerCoder]

> The "split token" password reset is snake oil.

One of two things just happened:

  1. You're being intentionally offensive where it's not really warranted
     by calling this proposed strategy snake oil.
  2. You don't know what snake oil means.

I'm going to assume the latter. Here's the thing:

  - Hash functions are deterministic. You'll make timing attacks more
    difficult, but you aren't removing the underlying timing leak.
  - You database engine almost certainly doesn't compare strings in
    constant time in SELECT queries, so there's almost always going
    to be a timing leak in SELECT queries.
  - Separating the timing leak from the authentication (and making the
    latter constant-time) properly alleviates this risk.

Other solutions (relying on the avalanche effect of hash functions, using a random sleep, or sleeping until a minimum amount of time has passed) are brittle and harder to reason about than solving the problem directly, which is what the article proposes.

See also: http://stackoverflow.com/a/28486617/2224584

You might disagree with the technical details and arguments laid out, but it isn't snake oil.

[johnnydoebk]

>> Just store the hash of the token (ideally stretched like any password) in the database and mail the original token out

If I understand it correctly, that's exactly what they propose. You mail the original token out, store its hash. The second string is used as an ID (there should be a secondary index on it).

[UnoriginalGuy]

base64 is just a data storage format and something that is required if you want to push data via GET. They're talking about pseudorandom numbers using a CSPRNG, with appropriate length, that's normally adequate for this scenario.

Can you explain in more detail why base64 makes you "cautious?"

> Just store the hash of the token (ideally stretched like any password) in the database

That's actually LESS secure. Their scheme has an ID (or "selector") and a hash ("verifier"). This means you can limit attempts against a single ID/account and also aren't going to compare a hash entered to every record in that table.

What you're proposing is massively weaker than what they propose. It also has timing attack problems.

[tinus_hn]

Base64 is an implementation detail so it is kind of strange to see it mentioned here. It also obfuscates things so you often see it used in insecure solutions.

That is why the use of base64 makes this look suspect even though on close inspection the ideas are probably valid.

[CiPHPerCoder]

The other post that was linked in the snippet that mentions base64 is far more likely to make people nervous: https://paragonie.com/blog/2016/06/constant-time-encoding-bo...

It's about an implementation of RFC 4648 encoding (including base64, base32, etc.) that doesn't index based on secret data.

Consequently, if a practical cache-timing exploit is ever demonstrated in existing implementations of encoding functions, the open source library we wrote will be immune.