Autho.me API And Python Demo • Hacker News Board

Re: Autho.me API And Python Demo

#11

Post by sdghjrjyt » Sat, Jan 08, 2011, 2:38 AM UTC

     Happy New Year◎,◎appy shopping

●---------------------------------------● ●------ http://goo.gl/l5v0b ------●

●------ http://goo.gl/l5v0b ------●

●------ http://goo.gl/l5v0b ------● ●---------------------------------------● Happy New Year◎,◎appy shopping

Re: Autho.me API And Python Demo

#12

Post by zedshaw » Sat, Jan 08, 2011, 2:40 AM UTC

delano wrote: post #6

tptacek wrote: post #5

Earlier quoted context omitted.

The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.

That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.

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.

Re: Autho.me API And Python Demo

#13

Post by srean » Sat, Jan 08, 2011, 2:48 AM UTC

zedshaw wrote: post #10

srean wrote: post #9

It appears that Zed Shaw does not like openId. I agree with him that it is certainly no panacea, but the risks can be minimized to a large extent if used properly. I use openId to login to HN. So when I submit my Google openID, in principle, HN can redirect me to a fake Google site where I may unknowingly type in my password. The big loophole is that I have no control over which site I am redirected to by HN. However…

I don't have any problem with OpenID itself, and in fact I worked on the PIP project at Verisign briefly. That statement is more about the difference in design, that OpenID has been marketed as some kind of protection against evil sites. It's an evil site, no amount of OpenID is going to protect you. I also disagree with the idea that OpenID protects against phishing, since well, if one site can be phished then an Op…

Ok that clears the air :)

I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be mitigated if I login to my OpenId provider first.

I think your concern is that my OpenId provider itself might be a phishing trap. Yes, if I fall for that, then all bets are off. But ideally I should be typing its url on my browser or going from a bookmark.

Re: Autho.me API And Python Demo

#14

Post by zedshaw » Sat, Jan 08, 2011, 2:55 AM UTC

srean wrote: post #13

zedshaw wrote: post #10

Earlier quoted context omitted.

I don't have any problem with OpenID itself, and in fact I worked on the PIP project at Verisign briefly. That statement is more about the difference in design, that OpenID has been marketed as some kind of protection against evil sites. It's an evil site, no amount of OpenID is going to protect you. I also disagree with the idea that OpenID protects against phishing, since well, if one site can be phished then an Op…

Ok that clears the air :) I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be miti…

You're also forgetting that the OpenID provider could be storing passwords and things wrong too, or that they've been hacked and someone's collecting them in-transit. Really, any attack against a non-OpenID site is available to an OpenID site, but with the added problem that nobody has to know.

For example, if google had a security breach (ehem China?) and passwords got snarfed for a period of time, how would you or a customer site know?

In addition to those attacks, there's economic attacks available from the provider. One day Google can just decide they don't like you and poof there go your users. For a customer this is a pretty big problem that they all must worry about.

And, all of those attacks are pretty much available to any login system.

Re: Autho.me API And Python Demo

#15

Post by srean » Sat, Jan 08, 2011, 3:04 AM UTC

zedshaw wrote: post #14

srean wrote: post #13

Earlier quoted context omitted.

Ok that clears the air :) I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be miti…

You're also forgetting that the OpenID provider could be storing passwords and things wrong too, or that they've been hacked and someone's collecting them in-transit. Really, any attack against a non-OpenID site is available to an OpenID site, but with the added problem that nobody has to know. For example, if google had a security breach (ehem China?) and passwords got snarfed for a period of time, how would you or…

Yeah that's what I meant by "phishing trap". In retrospect not a good choice of words, "compromised" would have been better. I am letting it remain as it is because you commented on it.

I think a better way to express my opinion about OpenId is this: say I trust that the probability a particular site will not be compromised is (1 - \epsilon). Then OpenId lets me maintain and transfer that value of trust over authentication transaction with other sites. As the saying goes, it is as strong as the weakest link.

There are protocols by which one can boost the level of trust beyond that (1 - \epsilon) but I have not come across a easy to use deployment of one such.

Re: Autho.me API And Python Demo

#16

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

zedshaw wrote: post #7

tptacek wrote: post #3

Here's what you're thinking when you see this: "Oh, neat, this is Zed Shaw telling me he's made something that will get me secure login that doesn't send passwords to my service using crypto that he feeds users through Javascript! I can't wait until it's ready to use!" Here's what Zed Shaw says this is for: application developers who are so uncertain as to whether they can hash passwords properly that they'd rather o…

Actually, no that's not the point of autho.me. I know you keep thinking it's about me making a secure authentication that competes with bcrypt+ssl. It's actually for the purposes I laid out in the blog post: 1. An easy to setup secure auth system that's at least as secure as the others available. Not more secure, but just as secure. For example, your attack of protecting against content modification applies to all lo…

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 in Javascript. You also keep calling it "Tom Wu's SJCL". You're saying that because "Tom Wu" is the name on SRP. Tom Wu didn't write SJCL. The SJCL authors, for what it's worth, claim "the best security which is practically available in Javascript", follow by a parenthesis, followed by the word "Unfortunately", followed by more words you should read.

The two factor stuff, by the way? News to me as of this post. Twilio and 2-factor auth is a good idea (note though that I'm biased, as my friend Dug is doing something very similar --- http://www.duosecurity.com).

Re: Autho.me API And Python Demo

#17

Post by tptacek » Sat, Jan 08, 2011, 3:11 AM UTC

zedshaw wrote: post #8

tptacek wrote: post #5

Earlier quoted context omitted.

The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.

Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL. Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant b…

"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.

Re: Autho.me API And Python Demo

#18

Post by tptacek » Sat, Jan 08, 2011, 3:12 AM UTC

zedshaw wrote: post #12

delano wrote: post #6

Earlier quoted context omitted.

That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.

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?

Re: Autho.me API And Python Demo

#19

Post by zedshaw » Sat, Jan 08, 2011, 3:54 AM UTC

tptacek wrote: post #16

zedshaw wrote: post #7

Earlier quoted context omitted.

Actually, no that's not the point of autho.me. I know you keep thinking it's about me making a secure authentication that competes with bcrypt+ssl. It's actually for the purposes I laid out in the blog post: 1. An easy to setup secure auth system that's at least as secure as the others available. Not more secure, but just as secure. For example, your attack of protecting against content modification applies to all lo…

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 content, which is pointless because all browser based security, even your own proposed bcrypt, is vulnerable to all of his attacks.

Also, my invocation of SJCL is not straw man, it's the actual library I'm using, so if you're going to do an exploit that takes advantage of a flaw in javascript math, then that's what you'd use. It's a concrete thing to focus on as an attack vector. That's sort of the inverse of "straw man".

Finally, if you are saying that this is the first time you're hearing about the Twilio 2-factor auth then you didn't even read the blog post.

Re: Autho.me API And Python Demo

#20

Post by zedshaw » Sat, Jan 08, 2011, 3:58 AM UTC

tptacek wrote: post #17

zedshaw wrote: post #8

Earlier quoted context omitted.

Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL. Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant b…

"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 bcrypt. That's because, once I can exploit the browser environment, then I have access to anything the user submits.

That's the crux of my question: If you say there's an exploit against cryptography because of javascript math then demonstrate it. If you have exploits against the browser environment, then I can't fix those and they apply to your proposed solutions.

Let's take an example: An attacker can inject XSS code onto the login page and get the SRP password. Well, an attacker that can XSS the login page and get the password from your SSL/bcrypt solution. They've got access to the whole page.

So, if you find demos of failed math in javascript I'd like to see those.