The actual announcement from Mozilla: https://blog.mozilla.org/futurereleases/2014/02/01/test-the-...
Mozilla adopts plain-vanilla password sign-in for Firefox sync
11–20 of 44 posts
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#12Will Mozilla be removing the secure sync option or having this one in parallel? I don't use it myself, but it's definitely worrying to see a secure option being potentially removed in favour of plaintext storage on servers outside the user's control.
I don't think it's stored in plain text, the post was about standard login/password signing in instead of too-complex current mechanism.
Historically, all data was encrypted locally before being sent to the other device. Now, by default, some data will be local-only encrypted, and some won't (the motivation being recovery services). There are plans though to have an option to locally encrypt all data.
https://wiki.mozilla.org/Identity/AttachedServices/Architect...
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#13Earlier quoted context omitted.
I don't think it's stored in plain text, the post was about standard login/password signing in instead of too-complex current mechanism.
If it's a username/password pair, either the data has to be stored in plaintext, or with a key escrowed using the user password, which are not as secure as a private key only known to the user.
No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server.
When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with public key, send all to the server).
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#14Not Mozilla Persona? Why wouldn't it be suitable for this purpose?
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#15Earlier quoted context omitted.
I don't think it's stored in plain text, the post was about standard login/password signing in instead of too-complex current mechanism.
If it's a username/password pair, either the data has to be stored in plaintext, or with a key escrowed using the user password, which are not as secure as a private key only known to the user.
Not true, there are plenty of key-derivation schemes. Basic idea for how one may work (not necessarily the one they will use, I'm still reading the wiki pages): data is encrypted locally with a hash of the user's passphrase, then that hash is hashed again and sent to the server as a login credential. The server never sees the original passphrase, nor the encryption key, nor the contents of the material uploaded.
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#16Earlier quoted context omitted.
If it's a username/password pair, either the data has to be stored in plaintext, or with a key escrowed using the user password, which are not as secure as a private key only known to the user.
No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server. When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with pub…
Considering the average user's password choice tendencies, that's still weaker than a key from a proper source of entropy, then password reuse on top of that.
That plus IIRC, RSA isn't deterministic even with the same seed. Not sure about generators for elliptic curve though.
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#17Aah good riddance to the older approach. Its a major fail from UX perspective. The long sync key was ridiculous to type.
Maybe a QR code option would have helped at least for the mobile devices use case?
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#18Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#19Earlier quoted context omitted.
No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server. When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with pub…
Considering the average user's password choice tendencies, that's still weaker than a key from a proper source of entropy, then password reuse on top of that. That plus IIRC, RSA isn't deterministic even with the same seed. Not sure about generators for elliptic curve though.
I think it is, at least that's what Cryptico[1] does, if I understand it correctly.
Re: Mozilla adopts plain-vanilla password sign-in for Firefox sync
#20Earlier quoted context omitted.
No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server. When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with pub…
Considering the average user's password choice tendencies, that's still weaker than a key from a proper source of entropy, then password reuse on top of that. That plus IIRC, RSA isn't deterministic even with the same seed. Not sure about generators for elliptic curve though.
They're using key-stretching to mitigate the use of bad passphrases, though reuse will still be an issue.
https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...
And RSA is deterministic.