(Un)conscious (in)competence reminds me of Donald Rumsfeld's trichotomy of known knowns, known unknowns and unknown unknowns.
(highlighted here: http://www.youtube.com/watch?v=2Ex8EEv-WPs)
You are dangerously bad at cryptography
21–30 of 174 posts
Re: You are dangerously bad at cryptography
#22Saying 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 cur…
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…
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.
Re: You are dangerously bad at cryptography
#23> This means that as long as you have one example of a signed message, you can forge signatures for that message plus any arbitrary request parameters you like and they will authenticate under the above described scheme. If all requests are made over HTTPS, how could a third party intercept a signed message? How is this any greater of a risk than a third party intercepting user login information? (This is a serious q…
If you do not manage SSL certificate properly (trust only your server's certificate), a MITM attack can break the system easily. Otherwise I don't think you can intercept the signed message if everything is over TLS.
Re: You are dangerously bad at cryptography
#24When he is saying >Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right. I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend a…
Hi, author here, I'm glad you found it useful! > I didnt know for example that you can basically extend an MD5ed string and keep the original MD5 value Thank tptacek for that knowledge, I think I picked it that up in a talk he did that's somewhere on Vimeo (will link to it). > Then again, I know that MD5 isn't a secure cryptographic hash function so I wouldn't have used it from the start. Nice to know why thats the c…
> It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends. Even if MD5 were cryptographically secure, this vulnerability would still present itself if used in the way I described.
Thanks for pointing that out, didn't know that.
Just for fun, if they had written message+secret instead of secret+message it would have been ok (although bad practice)?
calculated_mac = OpenSSL::Digest::MD5.hexdigest(message+secret)
Re: You are dangerously bad at cryptography
#25> This means that as long as you have one example of a signed message, you can forge signatures for that message plus any arbitrary request parameters you like and they will authenticate under the above described scheme. If all requests are made over HTTPS, how could a third party intercept a signed message? How is this any greater of a risk than a third party intercepting user login information? (This is a serious q…
If you do not manage SSL certificate properly (trust only your server's certificate), a MITM attack can break the system easily. Otherwise I don't think you can intercept the signed message if everything is over TLS.
Is the risk any greater with APIs (like described in the article) compared to typical username/password login systems?
Re: You are dangerously bad at cryptography
#26Earlier quoted context omitted.
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…
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.
Re: You are dangerously bad at cryptography
#27How is the shared secret generated, stored and shared? (There are lots of ways to do this wrong, and the code and algorithm for that were not even shown.)
Re: You are dangerously bad at cryptography
#28Unless I'm missing something, the example code will just calculate the checksum of "key:value&key:value&key:value", so actually anything with the same number of parameters will pass.
Assuming "key:value" is supposed to read "#{key}:#{value}", this may be vulnerable to a delimiter attack -- you couldn't tell the difference between {foo: 'bar', bar: 'baz'} and {foo: 'bar&bar:baz'}.
Re: You are dangerously bad at cryptography
#29I'm bad at crypto. I'm well aware that I'm bad at crypto. In fact, I would venture to guess that I know next to nothing about it. The problem isn't that I don't know what I don't know...the problem is that I don't know what (or whom) I can trust. And that is the bigger problem with crypto.
It would be nice if we had resources that could tell us not only the best practices, but what their downfalls are and their relative difficulties of cracking. Some common sense tells me that there is a combination of techniques that are simple and robust enough that I would have to worry about phishing before I had to worry about better security. But I don't know what that combination is, and I don't know if I can trust anybody that tells me.
Re: You are dangerously bad at cryptography
#30I didn't know about Matasano's Crypto challenges. Looks like fun, going to give it a try!