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