Do we really need an entire library to encapsulate http://docs.python.org/library/hmac.html and string.rsplit?
Yes, because Python's "hmac" library doesn't provide a secure "verify" method.
It's Dangerous, a Python cryptographic signing module
41–50 of 60 posts
Re: It's Dangerous, a Python cryptographic signing module
#42Earlier quoted context omitted.
I forked the project and updated the hashing algorithm: https://github.com/andrewconner/itsdangerous
> I forked the project and updated the hashing algorithm: https://github.com/andrewconner/itsdangerous That is not necessary, I adjusted the API so that you can easily subclass it and change the digestmod.
It should default to a SHA-2 hash and you should deprecate the branch that defaulted to SHA-1.
Re: It's Dangerous, a Python cryptographic signing module
#43Earlier quoted context omitted.
There should be no password at all involved. You're doing key signing, not password authentication. You should have a tool, like OpenSSL or GPG, generating your key pair for you. And people, STOP USING CRYPTOGRAPHIC PRIMITIVES FROM THINGS THAT ARE NOT OPENSSL.
Aroo? OpenSSL is usually a terrible place to pull crypto primitives from; the string "OpenSSL" in a Python or Ruby file is a decent predictor of crypto bugs. Also, OpenSSL has a relatively poor track record of algorithm-level bugs. I'd like your sentence more if it read "STOP USING CRYPTOGRAPHIC PRIMITIVES" and then ended with a period.
I took that from cperciva when he did his crypto talk.
Edit: Found quote:
Website security: Use OpenSSL. OpenSSL has a horrible track record for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available. UPDATE: For added security, terminate SSL connections in restricted environment and pass the raw HTTP over a loopback connection to your web server.
And yes, I'd always recommend using the highest-level possible API. If you have SHA in your code you are probably working at too low a level.
Do you have any recommendations for a better toolkit? Tarsnap uses Colin's own implementations so it's not a very good resource. There are other problems I've found with cryptlib, etc., (e.g., cryptlib is commercial).
Re: It's Dangerous, a Python cryptographic signing module
#44Earlier quoted context omitted.
Aroo? OpenSSL is usually a terrible place to pull crypto primitives from; the string "OpenSSL" in a Python or Ruby file is a decent predictor of crypto bugs. Also, OpenSSL has a relatively poor track record of algorithm-level bugs. I'd like your sentence more if it read "STOP USING CRYPTOGRAPHIC PRIMITIVES" and then ended with a period.
I took that from cperciva when he did his crypto talk. Edit: Found quote: Website security: Use OpenSSL. OpenSSL has a horrible track record for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available. UPDATE: For…
I agree that one thing that is actually worse than directly pulling AES or SHA-2 out of OpenSSL and fucking with it in your code is actually implementing AES or SHA-2 yourself. :)
Re: It's Dangerous, a Python cryptographic signing module
#45Re: It's Dangerous, a Python cryptographic signing module
#46Earlier quoted context omitted.
Yes, because Python's "hmac" library doesn't provide a secure "verify" method.
Is == not good enough for you?
Sigh.
http://codahale.com/a-lesson-in-timing-attacks/
Preemptively:
* Yes, a realistic attack.
* Yes, very difficult over the Internet.
* Still difficult but not implausible if the attacker can colocate near your app; ie, if you deploy anywhere on EC2.
* Measurement bounds are high nanoseconds LAN, tens of usecs WAN.
* HMAC verification, unlike password hash comparisons, is a place where timing actually does matter.
Not to suggest that I occupy the high road when it comes to snarky comments, but consider whether your snarky comment in this case suggests an unearned (and thus dangerous) level of confidence about crypto app security. This problem (HMAC timing) is so well known that it's generated many hundreds of comments over the years on HN.
Re: It's Dangerous, a Python cryptographic signing module
#47Earlier quoted context omitted.
Is == not good enough for you?
Sigh. http://codahale.com/a-lesson-in-timing-attacks/ Preemptively: * Yes, a realistic attack. * Yes, very difficult over the Internet. * Still difficult but not implausible if the attacker can colocate near your app; ie, if you deploy anywhere on EC2. * Measurement bounds are high nanoseconds LAN, tens of usecs WAN. * HMAC verification, unlike password hash comparisons, is a place where timing actually does matter.…
That's still a lot of code just to import a single 6 line function...
Re: It's Dangerous, a Python cryptographic signing module
#48Earlier quoted context omitted.
Sigh. http://codahale.com/a-lesson-in-timing-attacks/ Preemptively: * Yes, a realistic attack. * Yes, very difficult over the Internet. * Still difficult but not implausible if the attacker can colocate near your app; ie, if you deploy anywhere on EC2. * Measurement bounds are high nanoseconds LAN, tens of usecs WAN. * HMAC verification, unlike password hash comparisons, is a place where timing actually does matter.…
That's still a lot of code just to import a single 6 line function...
The fact that he knew about that function and you (standing in as "representative Python developer") did not seems to justify the library pretty nicely from what I can tell.
But, obviously, this code does more than Python's hmac library does, beyond just knowing how to properly verify the MAC itself.
Re: It's Dangerous, a Python cryptographic signing module
#49Earlier quoted context omitted.
I took that from cperciva when he did his crypto talk. Edit: Found quote: Website security: Use OpenSSL. OpenSSL has a horrible track record for security; but it has the saving grace that because it is so widely used, vendors tend to be very good at making sure that OpenSSL vulnerabilities get fixed promptly. I wish there was a better alternative, but for now at least OpenSSL is the best option available. UPDATE: For…
I agree that one thing that is actually worse than directly pulling AES or SHA-2 out of OpenSSL and fucking with it in your code is actually implementing AES or SHA-2 yourself. :)
My inclination for doing this kind of thing would be to use PyOpenSSL or a similar wrapper to do an S/MIME sign/verify on each side. Encryption using AES if necessary. I'd be inclined to do this for a couple reasons:
1) If there's anything my grad crypto class taught me it's that RSA, specifically padding, is the most god-forsaken idea ever created by man and you will never, ever, ever, ever get it right. If the words RSA are in your code you are in deep shit.
2) S/MIME seems to be a simpler system than any certificate system I have seen. X.509 is an unholy mess. In fact, all PKI is just a complicated disaster waiting to happen.
3) Super simple API -- it can even be done on the command line.
Is there something different you'd recommend?
Edit: Actually, I just thought of another option. GPG has a --sign and --verify option. If GPG can be installed on the system it may be worth trying to integrate that.
Re: It's Dangerous, a Python cryptographic signing module
#50Earlier quoted context omitted.
That's still a lot of code just to import a single 6 line function...
The fact that he knew about that function and you (standing in as "representative Python developer") did not seems to justify the library pretty nicely from what I can tell. But, obviously, this code does more than Python's hmac library does, beyond just knowing how to properly verify the MAC itself.
I wasn't criticising the security of this library, I was criticising it's reason to exist in the form that it does.