Hacker News Reader

Comment by davidw | Hacker News Reader

Saying stuff is hard is easy, and as far as I can tell, very correct about cryptography.

More useful would be actual suggestions to enable average developers to do more things with some degree of confidence. In other words, libraries, recipes and other documentation, and so on.

"Hire an expensive security guy" is probably not a feasible solution for many small startups, nor very scalable in any case.

Also, out of curiosity, in his timing attack example, the difference in time caused by the string being equal seems like it'd get absolutely swallowed up by the random nature of the universe - do those things actually work in the real world, on real servers with varying loads and numbers of users and network traffic?

View on HN

Hi, author here. I would have liked to have made useful suggestions, but having made so many errors with cryptography in the past, I don't really feel qualified to do so.

I do however recommend getting in touch with tptacek and co and doing the crypto challenges. I mentioned this at the bottom of the post.

Edit: re: timing attacks, it helps if you're in the same data centre. I've never personally implemented a timing attack, so I'm hesitant to make any assertions further than that either way.

I am doing this. It looks fun.

btw: isn't the scheme you posted vulnerable to replay attacks too? Much easier than the timing attack.

edited to add: don't mean this as a nitpick. I've seen that very mistake made by two S&P 500 companies that had 'homebrew' SSO we had to integrate with.

> btw: isn't the scheme you posted vulnerable to replay attacks too? Much easier than the timing attack.

Yep, probably. In fact now that I look at it definitely, I should have gone with that instead!

I forget who said this but basically any feature that exists in TLS that doesn't exist in your hand-rolled authentication scheme is a vulnerability.

Does peer review count as a feature?

>Also, out of curiosity, in his timing attack example, the difference in time caused by the string being equal seems like it'd get absolutely swallowed up by the random nature of the universe - do those things actually work in the real world, on real servers with varying loads and numbers of users and network traffic?

You could make each request many times, and then average them together. I don't know how many requests you'd have to make to overcome the random fluctuations though -- probably a lot.

Also, this random behavior will be significantly amplified if the host is running inside of a VM.

Reply on news.ycombinator.com