Hacker News Reader

Comment by callahad | Hacker News Reader

Hi, I hack on Persona at Mozilla. Persona is not a panacea, but this post is disingenuous.

Benjamin is concerned about user impersonation by identity (email) providers.

1. The identical risk of silent impersonation is present with any OpenID or OAuth-based system.

2. With password-based systems, a malicious provider could also intercept reset emails, creating similar risk. Benjamin notes that "a user will be aware of the attack then next time they try to login," but that's a poor mitigation, since the attacker has already gained access. Benjamin agrees: "On bugzilla.mozilla.org, we disabled password reset emails for users with access to security bugs."

If you're operating under the same constraints as Benjamin, then I agree: Persona alone is not sufficient. Nor is any other normal authentication system.

View on HN

Since each IdP has a private key, couldn't they request "pinning" it? So, for example, I can ask my IdP to say "I will be the IdP for this user for at least a year, if you get a different signature within this year, it's an impostor".

Each client would have to cache the ID specifically for every user, but that doesn't seem too bad for the extra security it gives. Alternately, the user themselves could send the IdP ID to the authenticating site and the site can check that they match, thus detecting any foul play.

Please correct me if I'm talking out of my ass, it's been a while since I implemented an IdP.

Smedberg is talking about a situation in which the IdP itself isn't to be trusted: it impersonates the user to the RP.

I was talking about the ".well-known/browserid file being changed to something else" attack, #2.

Ah, sorry for the confusion then. I have to say, an attacker who can change random files on the server can do all sorts of naughty things. Serve evil javascript libs? Change server configuration? Insert her own TLS cert? Check, check, check. Why would .well-known stuff be any different?

For those who do have problem with this, I guess I see why they want DNS SRV, but I can also see why the "plain DNS" complaints sidetracked this functionality.

Well, it's not necessarily that. For example, my website serves an authority delegation file (https://stavros.io/.well-known/browserid) which I really don't want an attacker to mess with. Serving JS libs/changing the config/etc wouldn't get them anywhere, unless they could change that single file.

Since there are some ways to protect from that (I think the two I proposed above are reasonable), Mozilla probably should think about implementing it.

> 2. With password-based systems, a malicious provider could also intercept reset emails,

He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.

> webmail login form => the password is typically sent in plain text to the server [regardless of transport security

I don't understand what you mean. If the form submit is over https, isn't the password neccesarily (not just typically, but always) _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?

I think the point is that if your email provider is hacked or malicious, your email password is hacked, but that's really only a problem if you use the same password on multiple sites. Don't do that.

If your email is hacked/malicious, and that's where your password reset requests from twitter, facebook, HN etc. are sent, it doesn't matter whether you reuse passwords or not; the attacker has the power to change them.

> isn't the password neccesarily [...] _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?

https is transport security. The data goes over the 'net in encrypted form, but the endpoint will get it in plain text (same as the contents of the html page with the form, which your browser sees as plain text, even though you access it over https). Therefore, an attacker who operates the server (or has compromised it), can just grab the plaintext passwords as you log in over https.

Reply on news.ycombinator.com