On 5/3/14 7:32 AM, Alexander wrote: > I was looking for an ability to use third party (PAM) authenticator > for my own auth server. But it seems really hard to integrate it into > current design of auth server (I would say "impossible without > hacks"). This is because auth server uses digest routes/account.js > works with password hashsums, not with real passwords.
That's right: to protect the privacy of your Sync data, we can't let the auth server know what your raw password is. As a hack, you could tell PAM that your "password" was really the 256-bit hashed output named "authPW"[1], which is a PBKDF derivative of the real password and the account's email address. Then one option would be that your auth server doesn't manage keys at all (i.e. it supports sign-in-with-FxA, but not Sync or other future services that need keys). Or, it could store any random value for kA and wrap(kB), and return them from the "GET /account/keys" API (i.e. supporting Sync but not protecting the keys as well as the real fxa-auth-server). To get the same level of protection against offline attacks as fxa-auth-server, you'd need to use its wrap(wrap(kB)) mechanism, and you'd also need to make sure that whatever hashes PAM stores are stretched at least as much, otherwise the PAM hashed authPW would be the easiest thing to brute-force. > Are there plans to support 3rd party authenticators? Or may be I am > missing something. No specific plans, but I'd love to see them get written :). The need to manage kA/kB secrets kinda throws a monkeywrench into the process: most PAM-like auth mechanisms don't provide for that. One of the alternate designs we looked at was to use a regular auth mechanism for the FxA login side, and a second password for the Sync secrets, but we rejected it because it'd require all users to manage two passwords. We also rejected, for obvious reasons, a plan to use a regular auth thing for signin (so just one password) but not encrypt the Sync data. If you ever hear one of the mozilla Identity folks talking about the "clown-shoes" problem, they're referring to this frustrating set of design constraints :). cheers, -Brian [1]: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol#creating-the-account _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
