I have implemented an MD5-based scheme similar to what was described. At the time, MD5/hash extension attacks were not as well-known as they are today, at least I had not heard of them and I read up on MD5 before I designed the sytem, so another worry is that what is considered secure today might not be secure tomorrow.
You are dangerously bad at cryptography
31–40 of 174 posts
Re: You are dangerously bad at cryptography
#32I'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 relat…
Author here. A good place to start (mentioned in the article).
http://www.matasano.com/articles/crypto-challenges/
Never met any of them in real life, but they seem like good people to me. I've actually used knowledge I picked up from those exercises to fix vulnerabilities in past clients code, and I'm not yet half-way through them.
Re: You are dangerously bad at cryptography
#33So, sure. I'll admit that I'm bad at cryptography. You win! But the problem is, the world needs more, not less, crypto. We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it. Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves. So too can we use higher-level libraries to help p…
What we really need is a cryptography language, to do for cryptography what SQL does for databases. I should be able to say, "Messages have this form, and they need to be encrypted end-to-end with authentication and without surreptitious forwarding," and have the right components assembled for me. Unfortunately, our understanding of cryptography is not well-developed enough to create such a system, and so we still fu…
Even if we had such a language it would probably not be high level enough because understanding what security you know is still a hard problem. Instead I'd suggest a high level library that gives you a complete security package with defaults that can't be easily changed.
Something like what the CAESAR competition hopes to achieve: http://competitions.cr.yp.to/caesar.html
Re: You are dangerously bad at cryptography
#34I completely agree with this and have just released a session-cache for python that completely ignores encryption and just stores uuid in a cookie, and relies on server side lookups for session work.
Re: You are dangerously bad at cryptography
#35Unless 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'}.
You are of course correct. Thanks! Will fix and rollout once traffic from HN/reddit dies down.
Re: You are dangerously bad at cryptography
#36> 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.
Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure?
And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop.
After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections.
If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)
Re: You are dangerously bad at cryptography
#37Earlier quoted context omitted.
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 p…
The answer is no, but I forget the exact reason why. Will do a little more research and report back.
Re: You are dangerously bad at cryptography
#38I have implemented an MD5-based scheme similar to what was described. At the time, MD5/hash extension attacks were not as well-known as they are today, at least I had not heard of them and I read up on MD5 before I designed the sytem, so another worry is that what is considered secure today might not be secure tomorrow.
> another worry is that what is considered secure today might not be secure tomorrow
If history is anything to go by then what is secure today will definitely be insecure tomorrow. No real solution to this AFAIK. If vulnerabilities in the crypto itself doesn't get you eventually, quantum computing will.
Re: You are dangerously bad at cryptography
#39Earlier quoted context omitted.
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?
A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct?
As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway.
Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.
Re: You are dangerously bad at cryptography
#40His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind: * Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and…
Outside of computing: health and diet. Sure, you get some feedback, but you also can screw up things in some ridiculously slow-acting way. Pharma companies (are supposed to) monitor drug use for decades after introduction for the same reason.
Construction. Just build that chunk out of two steel beams instead of one, and witness it work perfectly until someone decides to throw a party on that balcony. Or witness your construction slowly turn itself from a perfectly normal tower to a major tourist attraction over the centuries.
Parenting. Things like sudden stimuli in early life have been linked to ADD, the way you do attachment can have tremendous consequences, and sometimes singular events you barely have any control over can have unpredictable consequences later in your life.
In fact, I'm tempted to say "life in general".