Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
Brian Smith
The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript).
I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen.
We might also have the option of rewriting the J-PAKE implementation in C, include it in NSS, and making the J-PAKE functionality part of the public API of NSS. Another option would be to rewrite it in C, add it to NSS, but only enable it in a special (Firefox-specific) configuration of FreeBL. The default option seems to be to keep accessing these internal functions and data structures through JavaScript, and rely on NSS distributors to not change them. I am eager to hear others' suggestions.
Note that Sync's design is fundamentally incompatible with FIPS mode and consequently there's no need to consider FIPS mode concerns. We will just disable Sync (or require the user to disable it) in FIPS mode.
Cheers,
Brian
SHA1Context
SHA1_Hash
SHA1_HashBuf
SHA1_NewContext
SHA1_DestroyContext
SHA1_Begin
SHA1_Update
SHA1_End
mp_sign
mp_size
mp_err
mp_digit
mp_int
mp_init
mp_clear
mp_set
mp_sub_d
mp_sub
mp_cmp
mp_cmp_d
mp_mod
mp_addmod
mp_submod
mp_mulmod
mp_exptmod
mp_read_raw
mp_raw_size
mp_toraw
mp_read_radix
mp_radix_size
mp_toradix
Robert Relyea
> See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
>
> The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript).
>
> I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen.
>
> We might also have the option of rewriting the J-PAKE implementation in C, include it in NSS, and making the J-PAKE functionality part of the public API of NSS. Another option would be to rewrite it in C, add it to NSS, but only enable it in a special (Firefox-specific) configuration of FreeBL. The default option seems to be to keep accessing these internal functions and data structures through JavaScript, and rely on NSS distributors to not change them. I am eager to hear others' suggestions.
>
> Note that Sync's design is fundamentally incompatible with FIPS mode and consequently there's no need to consider FIPS mode concerns. We will just disable Sync (or require the user to disable it) in FIPS mode.
>
> Cheers,
> Brian
>
> SHA1Context
> SHA1_Hash
> SHA1_HashBuf
> SHA1_NewContext
> SHA1_DestroyContext
> SHA1_Begin
> SHA1_Update
> SHA1_End
>
#include "sechash.h"
HASHContext
HASH_HashBuf
HASH_Create
HASH_Destroy
HASH_Begin
HASH_Update
HASH_End
(It's not an accident that they are similarly named).
HASH_Create takes a HASH_HashType to say what time of hash you are
using. In addition there is a function that returnes the expected length
based on HASH_HashType, or the HASHContext.
There is also a function that maps oids to HASH_HashType. The latter two
would help you if you need hash agility (which you should probably think
about). If your protocal uses oids to specify your hash function, then
you won't even need to know what the real hash is under the covers.
> mp_sign
> mp_size
> mp_err
> mp_digit
> mp_int
> mp_init
> mp_clear
> mp_set
> mp_sub_d
> mp_sub
> mp_cmp
> mp_cmp_d
> mp_mod
> mp_addmod
> mp_submod
> mp_mulmod
> mp_exptmod
> mp_read_raw
> mp_raw_size
> mp_toraw
> mp_read_radix
> mp_radix_size
> mp_toradix
>
It depends on what J-PAKE is doing. My guess is it's doing a zero
knowledge proof algorithm (given the need for add and sub), which is
generally useful. I would be view a patch that puts the zero knowledge
proof into freebl with favor (and would clear out time to review such a
patch).
If we are just talking DH or RSA operations, there are public
equivalents to those as well.
bob
Nelson B Bolyard
> See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
>
> The following internal functions and data structures in FreeBL that
> would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes
> (a mechanism for calling native code through Javascript).
>
> I personally would like to find a way to avoid calling these internal
> functions from within Firefox--especially since there's no way to
> detect incompatibilities at compile-time and because the interface to
> these functions isn't frozen.
To what functions are you referring when you say "the interface to these
functions isn't frozen." ?? The functions you listed below (which I
haven't copied here)?
I'd say the interfaces to those functions (more precisely, their
signatures) are quite frozen. The mp_int bignum package API is so
frozen as to have become something of a standard of its own. There
are now at least 3 different implementations known to me that are all
API compatible, differing only in the content of the (opaque) mp_int
structure itself.
Speaking only for myself, I have no objection to offering the mp_int
bignum API as a "public" API out of freebl3. They're not presently
exported from the freebl shared lib at all, but IMO, they could be.
We merely wanted to minimize the exported API. But cryptography isn't
the only user of bignums, and IMO, it doesn't make sense to for Mozilla
to have yet another bignum library when NSS's is suitable for most purposes.
The hash functions you mentioned ARE already exported and there's even
a public API for them (albeit slightly different, as Bob has explained).
IMO, apart from the mundane technical issue of making hash and bignum
functions public, there are some bigger questions, such as:
- the wisdom of making Mozilla products even MORE dependent on shared
secrets and passwords than they already are, when, for at least a decade,
shared secrets in general and passwords in particular have been regarded
by security experts as more part of the problem than part of the solution.
- Letting mozilla products become a playground for home-baked crypto
protocols. That's a gate you'll find difficult to close once it is
allowed to be opened.
Marsh Ray
>
> IMO, apart from the mundane technical issue of making hash and bignum
> functions public, there are some bigger questions, such as:
>
> - the wisdom of making Mozilla products even MORE dependent on shared
> secrets and passwords than they already are, when, for at least a decade,
> shared secrets in general and passwords in particular have been regarded
> by security experts as more part of the problem than part of the solution.
Passwords suck, agreed.
But developers will code this stuff in Javascript anyway. By not
withholding those solid primitives which already exist someone has a
shot at making something that's not leaking through every imaginable
side-channel.
> - Letting mozilla products become a playground for home-baked crypto
> protocols. That's a gate you'll find difficult to close once it is
> allowed to be opened.
Since when have Mozilla products not been a playground?
Who put up a gate in the first place anyway?
Would you really have app developers go elsewhere for bignums?
Do you really think it would inhibit anyone from baking with crypto?
I want my playground and Easy Bake crypto oven. Or, more precisely, it
bugs me that an open project like Mozilla would restrict tools on the
"too dangerous for mere mortals" principle.
<cheap_shot>
So if Mozilla's got such high standards on authentication and such, they
can put up even one add-on that doesn't say "(Author not verified)" in
my browser:
https://addons.mozilla.org/en-US/firefox/addon/15003/
https://addons.mozilla.org/en-US/firefox/addon/11950/
</cheap_shot>
- Marsh
Brian Smith
> Brian Smith wrote:
> I personally would like to find a way to avoid calling these internal
> functions from within Firefox--especially since there's no way to
> detect incompatibilities at compile-time and because the interface to
> these functions isn't frozen.
> To what functions are you referring when you say "the interface to these
> functions isn't frozen." ?? The functions you listed below (which I
> haven't copied here)?
Yes.
> Speaking only for myself, I have no objection to offering the mp_int
> bignum API as a "public" API out of freebl3.
If people are open to having the J-PAKE building blocks in FreeBL, then we wouldn't need MPI to be part of the public API. The main concern with putting J-PAKE building blocks in NSS is getting that NSS release out for FF4.0.
> - the wisdom of making Mozilla products even MORE dependent on shared
> secrets and passwords than they already are, when, for at least a decade,
> shared secrets in general and passwords in particular have been regarded
> by security experts as more part of the problem than part of the solution.
>
> Letting mozilla products become a playground for home-baked crypto
> protocols. That's a gate you'll find difficult to close once it is
> allowed to be opened.
At the present time, the only thing you can do with the Sync account password is delete the data off the server and/or associate a different (strong) sync key with the account. Besides J-PAKE, it looks like Sync crypto will end up using quite simple/standard/boring algorithms & techniques. Once things are nailed down a little more, there will be a complete design document (and code, of course) for public review.
Cheers,
Brian
Wan-Teh Chang
>
> I'd say the interfaces to those functions (more precisely, their
> signatures) are quite frozen. The mp_int bignum package API is so
> frozen as to have become something of a standard of its own. There
> are now at least 3 different implementations known to me that are all
> API compatible, differing only in the content of the (opaque) mp_int
> structure itself.
>
> exported from the freebl shared lib at all, but IMO, they could be.
> We merely wanted to minimize the exported API.
We also need to undo some processor-version-specific type definitions.
An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit
is defined differently for different versions of the SPARC v9a processors:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefile&rev=1.115&mark=420-432#420
Wan-Teh
Nelson B Bolyard
I intended it to go to the list as well.
On 2010-10-21 16:50 PDT, Marsh Ray wrote:
> On 10/21/2010 05:53 PM, Nelson B Bolyard wrote:
>> - Letting mozilla products become a playground for home-baked crypto
>> protocols. That's a gate you'll find difficult to close once it is
>> allowed to be opened.
>
> Since when have Mozilla products not been a playground?
It IS a playground, in the sense that people can develop add-ons to do
whatever their hearts desire, and Mozilla actively encourages that.
I'm referring to the functionality in the base product, and particularly
to the security functionality in the base product. Users expect that
Mozilla product security, out of the box (so to speak), with no add-ons
present, is going to be very good.
And once added, features are seldom removed. Look at how long it is still
taking to get browsers to be secure with respect to renegotiation
out-of-the-box. It's because users have become dependent on that bad
old stuff and won't let go, even if it's bad for them.
> Who put up a gate in the first place anyway?
>
> Would you really have app developers go elsewhere for bignums?
I'm talking about putting JBAKE (or whatever it is) into the base product.
That's the motive behind this request. It's not for add-on developers.
It's because someone wants to put
> Do you really think it would inhibit anyone from baking with crypto?
I don't care about what people do with add-ons. They're not even at issue
here. I do care about what Mozilla offers to its users in the products
that bear its name, under the pretense of "security".
Security isn't about a pile of cool-sounding features. It's about
assurances. There are people within Mozilla who want to add to the
feature list, want to have more bragging rights, want to claim to be the
first with some new buzzword. That's utterly harmless when the new
buzzword is some new UI feature that changes pixels on a screen, but
in the security space, more care is needed to maintain the assurances.
> I want my playground and Easy Bake crypto oven. Or, more precisely, it
> bugs me that an open project like Mozilla would restrict tools on the
> "too dangerous for mere mortals" principle.
Marsh, Most users have no idea, draw no distinction, among the various
security protocols, mechanisms, schemes used within a product like their
browser. They have no idea where the responsibilities of a protocol end
and the responsibilities of the program's UI begin. When their security
is violated, they just lump it all together. That's why SSL/TLS keep
getting smeared for faults that are purely UI faults.
We read, monthly if not weekly, pronouncements in the press saying that
"SSL has failed" because users clicked past security warnings, or because
the browser was fooled by some clever web page content (e.g. JavaScript)
into displaying the wrong information to identify the source of that
content, or because badly-designed browser security UI, which is utterly
indistinguishable from web page content, is subverted to fool users into
taking actions that harm their own security, or simply because users
continue to fall for emails bearing dire warnings that appear to come from
their banks, that make them SO upset that they fail to notice the web page
into which they typed their bank password was NOT their bank's page.
None of these problems is in any way a fault of the SSL/TLS protocols, but
even readers of this group have tried to argue that they are.
So, when it comes to user security, Mozilla needs to take care about who
it lets into its bed. One foul piece of "security" in the base product
will besmirch ALL the product's security features.
> <cheap_shot>
> So if Mozilla's got such high standards on authentication and such, they
> can put up even one add-on that doesn't say "(Author not verified)" in
> my browser:
> https://addons.mozilla.org/en-US/firefox/addon/15003/
> https://addons.mozilla.org/en-US/firefox/addon/11950/
> </cheap_shot>
I don't think it's a cheap shot. I'm not wild about that, either.
I think it does show, however, a difference in degree of care between
things that are offered as "products of Mozilla" versus "addons by
whomever". That's appropriate, to some degree, in my opinion.
I'm just trying to ensure that the newest comer to Mozilla's security
development community is aware of some of these issues.
--
/Nelson Bolyard
Nelson B Bolyard
Hmm. The mp_int struct itself should be opaque in a public definition.
So there shuold be no need to change the machine-dependent definitions
of the contents of that struct (including the array to which it points).
But I know that mp_digit is also used for types in the function
signatures, and that IS an issue...
I think this says that the task is feasible but requires more time to
think about all its implications.
Brian Smith
> [...]
> I'm talking about putting JBAKE (or whatever it is) into the base product.
> [...]
Is there something specific about J-PAKE that you think is bad or worse than some alternative? Are you objecting to J-PAKE because you do not trust the proofs of security given by the authors? Is there anything you'd like to have clarified about how the Sync team is proposing to use J-PAKE and what steps we're planning to take to make the key exchange safe?
Thanks,
Brian
Nelson B Bolyard
>
> I believe mostly the problem is that the enthousiam level of Nelson for
> any password based solution is extremly low.
I think I should hire Jean-Marc to be my Public Relations consultant. :)
Now, let me tell you WHY my enthusiasm for any password based "solution"
is so low. It because none of them: J-PAKE, SPEKE, SRP, or for that
matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords.
PHISHING.
What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not?
The answer is: they don't require that you share your secret password
directly with the party who you would have authenticate you, with the
consequence that you do not make it TRIVIALLY easy for that party to
impersonate you, or sell your secret to someone else who them impersonates
you. That's it. That's all.
If you use JPAKE, SPEKE or SRP to authenticate to your bank, and you don't
use your bank password with any other service, then your bank
cannot impersonate you to ... your bank! WOW!
Do you fear your bank impersonating you to itself? You probably fear
others, with no relationship to the bank, impersonating you to it.
JPAKE, SPEKE and SRP don't address that any more than any other shared
password scheme (other than passwords sent in the clear). They offer no
more protection than CRAM-MD5, or even shared passwords sent directly over
SSL, to attacks that fool the user into entering his password in
the wrong place. It's still trivially easy to get that secret from a
large enough percentage of the users of those systems to declare them a
failure against phishing.
The ONLY solutions that actually solve phishing are the ones that the user
CANNOT be tricked into giving away. Those are the ones where nothing the
user knows in his head, or can induce his computer to send on his behalf
(using information in his head) can be replayed successfully.
That means there MUST exist some component to the solution, some secret,
unique to each user, carried (in some manner) by each user, that is NEVER
sent "over the wire" and cannot be derived from what is sent over the
wire, and that the user DOES NOT (likely CANNOT) CARRY in his head (or his
wallet) because it is just too big, or too nonsensically non-mnemonic, or
both. [This is nothing new. It's traditionally known as "Something you
KNOW and something you HAVE."] And (of course) there must be a
challenge-response element to the solution as well.
There's ONE test that should be applied to any proposed new authentication
scheme, and if it fails this test, it isn't worth the bloat is adds to
Mozilla code. That test is: If I learn the secret in
your head, can I then successfully impersonate you? Firefox already has
lots of schemes that fail that test. Why add more?
There are few schemes that pass this test. One of them is the public key
based client authentication used in SSL/TLS. Find another that's just as
good and it should be a winner.
--
/Nelson Bolyard
Brian Smith
> On 2010-10-25 10:49 PDT, Jean-Marc Desperrier wrote:
> > Brian Smith wrote:
> >> Is there something specific about J-PAKE that you think is bad or
> >> worse than some alternative? Are you objecting to J-PAKE because
> >> you do not trust the proofs of security given by the authors? Is
> >> there anything you'd like to have clarified about how the Sync
> >> team is proposing to use J-PAKE and what steps we're planning to
> >> take to make the key exchange safe?
> >
> > Hi, Brian.
> >
> > I believe mostly the problem is that the enthousiam level of Nelson
> > for any password based solution is extremly low.
> Now, let me tell you WHY my enthusiasm for any password based
> "solution" is so low. It because none of them: J-PAKE, SPEKE, SRP,
> or for that matter, good old CRAM-MD5 address the NUMBER ONE
> problem with passwords.
>
> PHISHING.
Sync would be using J-PAKE only to transport the Sync key from one
device to another. Nobody is proposing to establish any client-server
secure channel with it. Here is my understanding of how it would work:
0. I press the "Get my Sync Key from my computer" button.
1. My phone connects to the J-PAKE server to obtain a four-character
[A-Z0-9] channel ID.
2. The phone internally generates a ~40-bit key using
PK11_GenerateRandom, which translates into an eight character
code base-36 encoded [A-Z0-9].
3. I must read these 12 characters off of my phone and type it into
my computer.
4. If I enter the same code, the secure channel is established and the
sync key, username, etc. are transported to my computer.
5. The code is thrown away. In particular, after a failed attempt
(by the user or by an attacker), the process starts over at step
#1.
So, an attacker has a single 1-in-2^40 chance to guess the code,
assuming J-PAKE is correct and assuming the design is implemented
correctly.
> What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not?
> The answer is: they don't require that you share your secret password
> directly with the party who you would have authenticate you, with the
> consequence that you do not make it TRIVIALLY easy for that party to
> impersonate you, or sell your secret to someone else who them
> impersonates you. That's it. That's all.
That is a property of augmented password-based authentication scheme
and J-PAKE is a balanced password-based authentication scheme. J-PAKE
is interesting to Sync because it doesn't have that property and because
its authors claim it creates a secure channel even when we use a short
key for authentication, with perfect forward secrecy with respect to
that short key, and in such a way that an attacker can only make one
detectable attempt to guess it. Note that we are even considering the
Sync server itself to be a potential attacker; the Sync team is not
using J-PAKE for establishing any client-server secure channel. The
server acts purely as a proxy with respect to the J-PAKE key transport.
> The ONLY solutions that actually solve phishing are the ones that the
> user CANNOT be tricked into giving away. Those are the ones where nothing
> the user knows in his head, or can induce his computer to send on his
> behalf (using information in his head) can be replayed successfully.
> There's ONE test that should be applied to any proposed new
> authentication scheme, and if it fails this test, it isn't worth the
> bloat is adds to Mozilla code. That test is: If I learn the secret in
> your head, can I then successfully impersonate you? Firefox already
> has lots of schemes that fail that test. Why add more?
Unless I am misunderstanding you, the way J-PAKE would be used in Sync,
and in fact all Sync, is designed to accomplish exactly what you are
asking for. If there is something I am misunderstanding or overlooking
regarding your concerns, please reply and let me know. I want to make
everything Mozilla is doing with cryptography to be absolutely crystal
clear to everybody in the community. I am hoping that if I make things
clear to everybody, people will be more eager to contribute feedback
and/or code that improves things.
Thanks,
Brian
Nelson B Bolyard
> Nelson B Bolyard wrote:
>> matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords.
> >
>> PHISHING.
>
>
>> What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not?
>
That's resistance to something other than phishing. That's dealing with
an untrustworthy peer, with whom you WANT to trust, to the point that you
do give that party an authenticator of some sort. That's NOT the big problem.
> The server can not attack by brute-force the content of the exchange to
> deduce what you password is.
Right, so the attacker just asks you for it, very convincingly.
> Now, that's not it : What they truly bring is that if you are misled
> into making an handshake with a phishing site, you don't give to that
> site any information about what your password might be.
Sorry, untrue. The attacker puts up a password dialog. You type your
password into it. You give away your password. Maybe YOU (JMD) don't,
but then, you (JMD) aren't the typical phishing victim. You have a good
idea what to look out for. The phishing victim does not, and so enters
his password anywhere that asks, because he cannot (or will not) distinguish
between the places where he should and those where he shouldn't.
> If you are tricked into making the handshake with the wrong site,
> there's no bad consequence.
Right. That attack is not to get you to HANDSHAKE with the wrong site.
It's to get you to connect to the wrong site that ASKS YOU TO ENTER YOUR
PASSWORD.
> So the risk is to be tricked into entering your password inside a field
> that doesn't do a handshake, but instead just sends copy of it to the
> pirate.
Right.
> Therefore password exchange solution that relies on you entering the
> password inside a standard web page are still strongly vulnerable to the
> phishing problem, and there's no progress over older password schemes.
Right.
> But if the password is entered inside an element that is unambiguously
> the GUI of your browser, web site can not do a phishing attack against
> it any more, and the solution is actually quite good.
... ASSUMING that the user is bright enough to understand the difference
between chrome and non-chrome, and which one is trustworthy ... but years of
experience have shown us that most users are not. For years, and to this
very day, web sites put lock icons in the pages to try to convince
the users that the page is secure. My own bank does it! MOST users still
have no clue about trust of chrome vs trust of web page content. Not a clue.
I had a bank account "executive" sit in front of a browser once, and
"instruct" me in how to use the browser to do on-line banking. I sat
through his presentation (despite having been a user of online banking for
over a decade by then) to see how well HE understood it. He informed me
that he was specially trained by his bank to train customers in how to lower
their risk of being swindled. The FIRST THING he told me was to look for
the lock icon in the web page content to be sure I was looking at a "secure
page", before typing in my bank password. I asked him what was the
difference between that lock icon and the one down in the corner of the
window, against the background that matched the window border (he was using
MSIE). He had never noticed that lower icon before, and had no idea what it
meant. So much for his special training.
No, passwords simply have NO PLACE in protecting the average user from
phishing. And it doesn't matter whether the password is used to derive
a session encryption key, or just as an authentication token. The user
is just as vulnerable either way. A password user's best protection against
attack is simply appearing to be a low-value target. There are
so many of them waiting to be attacked that the trick is to appear to
be less worth attacking than one of the millions of others.
> Therefore the actual gap in security between the two is :
> - A : An attaquer that find a way to create a windows that tricks users
> to believe it's the genuine Firefox GUI for the password, without having
> to use chrome privilege.
No need to convince the user that it's "genuine Firefox GUI" because the
user has no idea what the significance of that is. Any ordinary web page
with a password field in the page content will suffice.
> - B : An attaquer that uses the usual weaknesses of passwords to get
> access without phishing the user. Those usual weaknesses being that
> passwords are frequently very weak, but the worst I believe is that
> users frequently reuse them. So the attacker could obtain the value of
> the password of the user at another site, and use it to guess accurately
> what he's using at the protected site.
Yup. That's another reason why you don't want the user to be able to use a
secret that he can carry in his head, because he will invariably choose a
dictionary word.
Here's a fun fact. DO you know any zealous Christians? If so, odds are
VERY HIGH that they use a password that is some combination of "love" and
"God" (e.g. LoveGod or GodisLove) for their passwords. I know this because
Christian people who I help frequently tell me this, and they think they've
all cleverly come up with something that no-one else will ever guess!
> Hardware protected private keys have a much more significant added value
> than software ones when compared to those schemes. Unfortunately they
> are still very little used. Except in China, surprisingly (Banks there
> have distributed millions of PKI hardware token to identify on their web
> sites)
Yeah, the Russian banks all do this, too. Why can't the bankers in the free
world have as much of a clue about network security as those in Eastern
Europe and Asia?
There seems to be a group of people who have accepted the notion that
passwords MUST be the solution. They spend a huge amount of time, coming up
with one new scheme after another that has some "provable" resistance to
some attack, but not against the easiest and most successful attack: ASK the
user for his password. They're living in denial. They just delay the day
when REAL solutions finally get deployed. If Mozilla wants to join that
pack, ... Sigh.
Marsh Ray
> On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote:
>> Nelson B Bolyard wrote:
>>> matter, good old CRAM-MD5 address the NUMBER ONE problem with
>>> passwords.
>>>
>>> PHISHING.
>>
>>
>>> does not?
>>
>
> That's resistance to something other than phishing. That's dealing
> with an untrustworthy peer, with whom you WANT to trust, to the
> point that you do give that party an authenticator of some sort.
If I understand it correctly, one thing it does do is convert an offline
password cracking attack into an active real-time MitM. The attacker is
required to use the session right then, he can not harvest the login
credentials for later use.
Now, the extent to which this represents a real improvement in the
effective security of the average user is a very open question. I think
that in practice, fewer attackers have demonstrated an online
attack capability (e.g. Zeus) than have using simple password
harvesting. But if somehow they ran out of usable password credentials
to steal, they'd probably become more sophisticated.
> That's NOT the big problem. [...] Right, so the attacker just asks
> you for it, very convincingly. The attacker puts up a password
> dialog. You type your password into it. You give away your
> password.
> ... ASSUMING that the user is bright enough to understand the
> difference between chrome and non-chrome, and which one is
> trustworthy ... but years of experience have shown us that most
> users are not.
It's impossible to discuss security unless we're able to expect some
minimal degree of competence on the part of the user. This applies to
telephone and mail scams just as much as data security.
Instead of the chrome/nonchrome lock icon distinction, we could equally
say that typical users are willing to download and install executables,
at which all bets are off. I've even heard of a (non-US) bank that
required users to do exactly that in order to access its site!
Whether or not Firefox can make an effective UI for this kind of
security is an altogether different question. My guess is that if
Mozilla doesn't do the best possible job of it with Firefox, extension
developers and/or Google Chrome will.
> For years, and to this very day, web sites put lock
> icons in the pages to try to convince the users that the page is
> secure.
They may be in part reacting to users' expectations of lock icons. Or
graphic designers simply like to decorate the page with little logos.
> My own bank does it! MOST users still have no clue about
> trust of chrome vs trust of web page content. Not a clue.
Just a personal anecdote, I find the color changes in the address bar to
be a good visual indicator. The red background really stands out when
you're used to seeing blue there.
> I had a bank account "executive" sit in front of a browser once, and
> "instruct" me in how to use the browser to do on-line banking. I
> sat through his presentation (despite having been a user of online
> banking for over a decade by then) to see how well HE understood it.
> He informed me that he was specially trained by his bank to train
> customers in how to lower their risk of being swindled. The FIRST
> THING he told me was to look for the lock icon in the web page
> content to be sure I was looking at a "secure page", before typing
> in my bank password. I asked him what was the difference between
> that lock icon and the one down in the corner of the window, against
> the background that matched the window border (he was using MSIE). He
> had never noticed that lower icon before, and had no idea what it
> meant. So much for his special training.
Classic!
> No, passwords simply have NO PLACE in protecting the average user
> from phishing. And it doesn't matter whether the password is used
> to derive a session encryption key, or just as an authentication
> token. The user is just as vulnerable either way.
Even myself, whom I consider pretty paranoid about these things,
occasionally enter the right password (for one system) into the wrong
password field.
> A password user's
> best protection against attack is simply appearing to be a low-value
> target. There are so many of them waiting to be attacked that the
> trick is to appear to be less worth attacking than one of the
> millions of others.
Which only works if you don't have enough to lose to make you worth of a
targeted attack.
>> Hardware protected private keys have a much more significant added
>> value than software ones when compared to those schemes.
>> Unfortunately they are still very little used. Except in China,
>> surprisingly (Banks there have distributed millions of PKI
>> hardware token to identify on their web sites)
>
> Yeah, the Russian banks all do this, too. Why can't the bankers in
> the free world have as much of a clue about network security as
> those in Eastern Europe and Asia?
Many of them do understand it. Hardware tokens have huge deployment
costs in quantity. My impression is that most customers are on the "free
checking" plan.
> There seems to be a group of people who have accepted the notion that
> passwords MUST be the solution.
I think the reality is starting to sink in. The financial industry in
particular bears huge costs for this type of thing.
> They spend a huge amount of time,
> coming up with one new scheme after another that has some "provable"
> resistance to some attack, but not against the easiest and most
> successful attack: ASK the user for his password. They're living in
> denial. They just delay the day when REAL solutions finally get
> deployed.
You got a better idea? You'll have my support.
I work on a product at my day job to try to provide deployable solutions
in this space. In my opinion, there will always be room for new ideas
and improvements in authentication, but the key is that it has to be
'deployable'. You'll never know what 'deployable' means until you talk
to the actual customers. Often cost per user is a big factor, but it
seems like just as often the issues are non-technical in nature.
> If Mozilla wants to join that pack, ... Sigh.
Ultimately it's up to those writing the web apps to decide how they will
be secured. Maybe we programmers could do a better job, but there are
certainly worse ways to go about adopting or rejecting technologies.
- Marsh
Nelson B Bolyard
> No, passwords simply have NO PLACE in protecting the average user from
> phishing. And it doesn't matter whether the password is used to derive
> a session encryption key, or just as an authentication token. The user
> is just as vulnerable either way.
Illustrative case history: http://imgur.com/cNorB
Konstantin Andreev
> On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote:
>> Hardware protected private keys have a much more significant added value than software ones when compared to those schemes. Unfortunately they are still very little used. Except in China, surprisingly (Banks there have distributed millions of PKI hardware token to identify on their web sites)
>
> Yeah, the Russian banks all do this, too.
Oh, nay. Very few of them use hardware tokens :( Typical solutions are:
- passwords-only
- passwords + scratch-cards
- user X.509 cert, signed by bank CA
Regards,
--
Konstantin Andreev.