41–50 of 174 posts
Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!
Earlier 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.
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 le…
With libcurl, I think you have to set CURLOPT_SSL_VERIFYHOST to 2. If you set it to TRUE (i.e. 1), it skips part of the certificate check, rendering the whole thing trivially insecure.
Most (all?) crypto libraries have terrible APIs, or have APIs that are far too low-level to be safely used by most developers. SSL shouldn't be the easiest thing to attack, but in the current state of affairs, it often is.
The HMAC timing attack illustrates this well, "classical" systems as I will call them, e.g. Enigma and how it was used, are not subject to zillions of known plaintext attacks (although I've read one bit of known plaintext from an out of the way base ("I have nothing to report"...) regularly helped the Enigma decryptors when the key changed).
1) End user level: You want to buy things online, you should know to check for the padlock icon.
2) Deployment level: You run an online shop using an off the shelf eCommerce system. You should buy an SSL cert and know how to install it on your web server of choice. You should also know the difference between a public and private key (and hence why you should never give the private key out) and roughly what a certificate and digital signature are for.
3) Integration level: You are building a custom application/API which uses crypto for security/privacy. You should know the difference between symetric/asymmetric encryption, what things like HMACs are and what the purpose of a password hash is.
You should know how to choose a good library or ensure that your framework is integrating a good library. You should also be mindful of which information you should never leak over cleartext channels and also things like MITM attacks.
4) Implementation level: You are using existing crypto primatives to develop a new use for encryption, maybe a crypto currency or a new type of auth protocol for example.
You should know a lot of deep computer science related to crypto, like the difference between AES CBC and ECB modes, various issues related to padding, how to generate secure random numbers and countless other issues. Here be dragons, you probably need significant peer review before your work is "production ready".
5) Design level: You are trying to improve an existing crypto algorithm or develop an entirely new one. Here you are going to need a very deep understanding of mathematics and cryptography research, probably to PHD level. So all kinds of stuff about number theory and being able to formally prove everything.
I would guess that most developers should stay at around level 2 as much as possible, delving into level 3 only when required and never further.
When we do web development, the admins take care that the application runs over https, and authentication is handled by some LDAP thingy in the web server. The only other cryptography we use is ssh, and signing submissions to the RIPE database with PGP, and stuff transparently done by some database client libraries.
It seems to be a sweet spot where we're still flexible enough for what we do, and don't present too much attack surface.
His 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…
XSS vulnerabilities. Maybe Content Security Policy will help some here when it becomes ubiquitously available.
Integer overflow. This is a particularly insidious problem because your well-formed test cases often won't catch it.
His 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…
And a question on the timing attack - how real it is? Because in the response time you have a lot of random variables which with the current fast servers will take more time than the calculation itself.
You receive request - how fast it will go trough the loadbalancer is random, then you must read the shared secret, then you must log the request somewhere and the whole hmac calculation is milisecond or less.
I'm just curious: the obvious response to the first problem (message extension attack) is to include the message length in the message. If this wouldn't work, could an expert please tell me why? Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!
Secret: secret Message: foo&bar Let's include the length and hash 'secretfoo&bar13'
What you actually hash is 'secretfoo&bar130x80...padding...0x20'. What the attacker sees as the 'known hash' includes this padding. When you perform an extension attack, the attack message would look like: secretfoo&bar130x80...padding...0x02&evil . At this point you're adding on the length and hashing it, so what you compare with is 'secretfoo&bar130x80...padding...0x02&evil93' ... but the attacker can precompute that hash just as easily as the one with just 'evil' appended.
You could argue that your hashes would be constructed a bit differently (eg make messages that appear to have internal padding illegal; still vulnerable, btw), but the point is - you're still tinkering with the same basic structure, and are likely to make more mistakes. You're better off switching to HMAC for this application.