Hacker News Reader

Comment by mithaler | Hacker News Reader

I'm working for a client right now that's requiring us to collect no less than three "shared secrets" from users who are signing up to buy a product. I can't imagine they'd have less than a 90% dropoff at that point in the sale process.

Oh, they're also requiring that we encrypt the answers in the database. With encryption keys stored on the same server. But that's a separate (and arguably sillier) issue.

View on HN

Oh, they're also requiring that we encrypt the answers in the database. With encryption keys stored on the same server. But that's a separate (and arguably sillier) issue.

Well, that's fine. Just keep the decryption key somewhere else, or don't use an algorithm that can be decrypted.

While one-way encryption would be the obvious way to properly handle it, there is a need in this project for customer support to be able to see the answers to secret questions to verify them over the phone. And if we're automating that, then anyone who's into the system already has everything they need to recover the decryption key, even if it's elsewhere.

To verify the correctness, they can type provided answers and the computer will do its job, checking the hashes. That is, in case phone support person has immediate access to the computer (which is probably the case) and can type fast enough.

The only thing required is a well-designed text normalization algorithm, which will neglect all variations in case, spacing, punctuation, spelling (i.e. "color" vs "colour") and other similar sort of issues.

(In edge cases, where this may fail, the plaintext answers could be recovered by authorized person from off-site write-only-API "secret storage" server, where the data should lay encrypted with asymmetric crypto. Less convenient, but more secure.)

Reply on news.ycombinator.com