3 ms·

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 (ideal

by yid 10y ago

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.

johnnydoebk 10y ago
>> 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).
CiPHPerCoder 10y ago
> 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 http://stackoverflow.com/a/28486617/2224584 You might disagree with the technical details and arguments laid out, but it isn't snake oil.
UnoriginalGuy 10y ago
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 10y ago
  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 10y ago
    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-boring-cryptography-rfc-4648-and-you 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.

by yid 10y ago

johnnydoebk 10y ago

>> 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).

CiPHPerCoder 10y ago

> 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 http://stackoverflow.com/a/28486617/2224584 You might disagree with the technical details and arguments laid out, but it isn't snake oil.

UnoriginalGuy 10y ago

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 10y ago
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 10y ago
  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-boring-cryptography-rfc-4648-and-you 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.