> Maybe that's an acceptable compromise for your users, but I want to be > absolutely clear about the trade-offs involved.
As I said we don't know the user password, but I understand what you mean about the sync's crypto model. For the project I'm working on, we will use Sync for his Web Browser Sync abilities, not for the crypto. ATM if the password is secure until it's arrived at the login server, it's good as MITM attack won't work (and it's the most important for now). >https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol I'll look at this for the Sync 1.5 part of the project. > First, you can't verify this hashed password against an exiting AD user > database, which are typically designed for verifying cleartext passwords. > You would either need to modify your Active Directory to use an fxa-style > password verifier, or store the fxa-style password verifier as a separate > record in the user db. This could be a problem to implement a unique password between AD and FXA :/ I'll look into it. Robin Aleman Apprentice engineer - Software integration Customer Integration & Support EQUANT France - Sophia Antipolis +00 33 4 92 96 64 48 [email protected] -----Original Message----- From: Ryan Kelly [mailto:[email protected]] Sent: Friday, July 04, 2014 01:38 To: [email protected]; ALEMAN Robin SCE/ID ITS Subject: Re: Sync-reg / FXA : Active Directory authentication On 4/07/2014 3:18 AM, Richard Newman wrote: >> The goal would be to at least allow users to have one password for Sync & >> AD. > > If your directory service knows the user password, or even a weak hash of it, > then by definition that's a non-goal, because it would defeat Sync's ability > to do end-to-end encryption. By way of a little more detail here, the authentication dance between Firefox and fxa-auth-server is pretty complex and is documented at: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol Firefox does not send the cleartext password for authentication. It computes a hash of the password and sends that to the server instead. This poses two problems for integration with other auth stacks like Active Directory. First, you can't verify this hashed password against an exiting AD user database, which are typically designed for verifying cleartext passwords. You would either need to modify your Active Directory to use an fxa-style password verifier, or store the fxa-style password verifier as a separate record in the user db. Second, as Richard points out above, you will substantially weaken the security properties of sync. If some other part of the system sends the auth password to the server in plaintext, then you lose almost all benefits of sync's crypto model. Maybe that's an acceptable compromise for your users, but I want to be absolutely clear about the trade-offs involved. Cheers, Ryan _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
