Since the delimiters are removed before computing the signature (so each is just "ABCDEFGHIJLM"), the signatures for the following two query strings are the same:

    ?A=B&C=D&E=FHIJKLM

    ?A=B&C=D&E=F&H=I&J=K&L=M

Clever.

Would you say that driving is hard because people have to remember which side of the road to drive on?

Have you ever, in your whole career, worked with a team that wrote their own crypto and got it right in version 1? Because I haven't.

As far as I know, I got the crypto right in tarsnap. If I didn't, please let me know. :-)

Similarly, the one cryptographic complaint I have about OpenSSL (as opposed to non-cryptographic security bugs) is their lack of attention to side channels, and the same applies here -- we KNOW that side channels are bad. The fact that the OpenSSL developers haven't made any systematic attempt to prevent them doesn't mean that cryptography is hard; it just means that the OpenSSL developers are careless.

By default, OpenSSL has: RSA blinding, constant time montgomery multiplication, careful review and correction of the conditional branches which were attacked in that amazing series of branch prediction papers.

Doesn't seem to me that OpenSSL developers are careless and indifferent about side-channel attacks.

No, I don't know of any better cryptographic library. (This is why I said a few days ago that writing a better cryptographic library was something I'd like to do if I was rich.)

Doesn't seem to me that OpenSSL developers are careless and indifferent about side-channel attacks.

They're playing whack-a-mole. There are over a thousand conditional branches in the large integer arithmetic code alone. The fact that nobody has pointed out how to exploit them yet doesn't mean that they're not exploitable.

Inviting crypto to the party invites a whole host of new security bugs that you simply cannot have if you don't go down that road in the first place.

This sort of problem is one of the reasons that I made the crypto in tumbler (http://tumbler.sf.net/) as simple as possible because I was sure that if I did anything but total simplicity I would screw it up.

You told people to pick good "passwords"; you should change the language to say "generate good 128 bit random strings".

An attacker monitoring the deletion can with impunity wipe out your data at a later date.

Only within the next 15 minutes. Beyond that point, AWS will reject the request for having excess clock skew.

As for "wonderful heisenbugs" -- the AWS services return a clear "hey, your clock is broken" error, so it wouldn't be very hard to developers to figure out what was going on.

I wonder if this is just the random luck of who happened to see the post on reddit first, or if news.ycers are innately more interested in security-related stories than programming.redditers.

PGP seems to be a popular 'primitive' to try to roll your own broken crypto protocol out of.

Exhibit A: http://enigform.mozdev.org/

Exhibit B: http://web.monkeysphere.info/

Even SSL/TLS is not easy to use correctly (while understanding all the risks) for purposes other than what it was originally designed for: Preventing credit card numbers from being sniffed between a browser and a web merchant.

SSLv1 may have been originally designed for securing credit cards, but I'm not sure that argument survives a close read of TLS; why waste time with mutual authentication, with forward secrecy, with a custom record layer, with arbitrary length certificate signing chains, etc etc etc. You might be surprised at the number of systems that leverage TLS successfully on ports other than 443.

We probably agree; no matter how you choose to implement crypto security in a system, you're probably worse off for trying.

Verifying certificates correctly is not so easy to get right either, if you can even figure out what PKI means for your particular application in the first place.

Enterprise apps make good use of certificates. A common use case is to set up a private CA (a three-line shell script) and issue internal certs to all endpoints in a system; you can then do crypto-strong access control just by checking signatures. This is approximately to PKI what "using git just like you used Subversion" is to git.

Another place where TLS has been a huge win is in wireless security; EAP-TLS with mutual certificate auth is the de facto corporate wireless security standard now.

Even if null data is submitted and someone sniffs the salt, it's still 30-chars long and last I checked rainbow tables don't work too well on SHA-256 hashes of that length.

I ask because I use a system similar to this to just do a basic check to ensure that a form POST is coming from a user clicking an action and not just some random spammers' form just posting the needed vars. It's nothing particularly secure (I think), just a nuisance to any spammer.

Second, the vulnerability here isn't password cracking; it's that AMZN verifies the signature on canonicalized data, but operates on non-canonicalized data.

It's not an issue though because I don't do the key/value pair splitting as they do.

The "dumb" developers just use OpenSSL and PGP, and they usually come out ahead in the end.

Also: I doubt the Amazon implementers here were dumb. I bet they were pretty smart. They just forgot about canonicalization; this is a classic problem in signature systems. Building crypto features is a good way to get screwed.

(PS: I feel qualified to take a contract breaking systems like this, but probably not qualified enough to engineer my own crypto protocol.)