Autho.me API And Python Demo • Hacker News Board

Re: Autho.me API And Python Demo

#21

Post by tptacek » Sat, Jan 08, 2011, 4:00 AM UTC

zedshaw wrote: post #19

tptacek wrote: post #16

Earlier quoted context omitted.

Why not read Nate Lawson's blog post? This will be the second time I've recommended it to you. One of the reasons I'm not going into too much depth is, why would I recap all of Nate Lawson? You're doing crypto dev, you should be reading him already. Your invocation of SJCL is also a bit of a straw-man. SJCL doesn't do straight-up number-theoretic crypto; even the AE cipher modes it offers avoids it. You're doing SRP…

I did read his post, but there isn't a single actual demonstration of his claims that javascript math is flawed: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... All of his exploits talk about attacks that are just browser attacks, but nothing that says what you're saying about an actual exploit in the math of javascript. His attacks also assume an infinitely capable attacker who can always alter conte…

No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read?

You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser is relevant.

Nate does talk about "the math of Javascript", by the way.

Re: Autho.me API And Python Demo

#22

Post by zedshaw » Sat, Jan 08, 2011, 4:01 AM UTC

tptacek wrote: post #18

zedshaw wrote: post #12

Earlier quoted context omitted.

Actually, he's incorrect. The crypto is calculated in javascript, and in a C library written by the author of SRP: http://srp.stanford.edu/download.html I'm using 2.1.2 with one slight modification to use SHA256 instead of SHA1+MGF1. That means that, should there be a failure in the javascript, it has a chance of getting caught in the C code written by the author of SRP.

I'm not incorrect. I did actually read your code, Zed. You think I've made a claim that I haven't made: that you wrote a serverside implementation of SRP. I know you're using the original SRP library. That was a good call. You know SRP is mutual auth, right?

Yes, I do, but claiming I wrote the crypto in javascript is false. I wrote one part in javascript, and the other part is in C. That means, if there's an attack against the Javascript cryptography not the browser environment, then the mutual aspect of the cryptography will mean that the C side will catch the error.

That's why you're wrong when you say I did in javascript. Only 1/2 of it is in javascript, and I only wrote a minimal amount of that.

Re: Autho.me API And Python Demo

#23

Post by zedshaw » Sat, Jan 08, 2011, 4:09 AM UTC

tptacek wrote: post #21

zedshaw wrote: post #19

Earlier quoted context omitted.

I did read his post, but there isn't a single actual demonstration of his claims that javascript math is flawed: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... All of his exploits talk about attacks that are just browser attacks, but nothing that says what you're saying about an actual exploit in the math of javascript. His attacks also assume an infinitely capable attacker who can always alter conte…

No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read? You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser…

I know he talks about it, but he doesn't really. He starts talking about it, and then switches to a browser environment attack.

The main crux of my disagreement with you is that you say: Doing javascript in the browser makes it more vulnerable to an exploit than just doing bcrypt+ssl passwords. However, if someone can exploit the browser (XSS, content modification, etc) then no login system is safe.

In other words, you're pimping bcrypt+ssl as a better alternative because it's NOT vulnerable to browser environment exploits, but it is. Every browser is.

A browser environment exploit is all the things you keep bringing up: cache poisoning, SSL exploits, phishing, XSS attacks, content modification, etc.

Re: Autho.me API And Python Demo

#24

Post by tptacek » Sat, Jan 08, 2011, 5:06 PM UTC

zedshaw wrote: post #23

tptacek wrote: post #21

Earlier quoted context omitted.

No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read? You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser…

I know he talks about it, but he doesn't really. He starts talking about it, and then switches to a browser environment attack. The main crux of my disagreement with you is that you say: Doing javascript in the browser makes it more vulnerable to an exploit than just doing bcrypt+ssl passwords. However, if someone can exploit the browser (XSS, content modification, etc) then no login system is safe. In other words, y…

You think maybe he's making it up?

:)

Re: Autho.me API And Python Demo

#25

Post by tptacek » Sat, Jan 08, 2011, 6:55 PM UTC

zedshaw wrote: post #20

tptacek wrote: post #17

Earlier quoted context omitted.

"Turing completeness" does not mean "safe environment in which to run cryptography". There are in fact math problems in Javascript environments, but they are far from the worst problems you face there.

Again, you say javascript cryptography is flawed, and then say it's a browser environment problem. Let's break this down. If the flaw is in how javascript does math, then that's something Autho.me has to deal with and I'd like to know about it. If however, this is a flaw in browser environment, then all methods that use a browser are equally flawed. That includes OpenID, Oauth, SRP, and your own proposed solution of…

Look, I'm just not wading into this. You and I should, as much as possible, avoid arguing; because of our personality types, we're just going to end up at the nerd equivalent of pistols at dawn.

You're telling people to use SSL with this. That is good. With SSL in the mix, my only real issue with AUTHO.ME is that it's a lot of moving parts for (what I think is) minimal value. You think "not having to implement bcrypt or PBKDF2" is major value. Guess what: this point is not worth a huge argument. And it's absolutely not worth a line-by-line evaluation of your crypto code, so I'm just not going to do it.

If you're planning on a doing an indie two-factor auth project, that value may be less minimal. I have no coherent opinion that stuff. Good luck with it. If you do something crazy, I'll call you on it, which is I think what you want.

Ignore Kaminsky, by the way. I can't imagine how using RSA instead of SRP could possibly make this safer, but I can imagine lots of ways in which it could make you much less safe.