[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WEB SECURITY] Re: Using JavaScript to generate "secure" passwords.
- From: "Brian Eaton" <eaton.lists@xxxxxxxxx>
- Subject: [WEB SECURITY] Re: Using JavaScript to generate "secure" passwords.
- Date: Wed, 30 Jan 2008 11:21:44 -0800
The code is fairly conservative in the entropy estimate:
++bits; // treat each sample as having one bit of entropy
You put an upper bound on the entropy gathered per mouse movement as
25 possibilities or a little under 5 bits. That upper bound is high,
because mouse movements aren't random, but there may well be at least
1 bit of entropy in each sample.
Not that I would mind seeing some additional entropy mixed in. Least
significant bits of the current time, some randomness provided by the
server, etc... would be good. Also keep in mind that this is for
generating a password, not an encryption key.
Cheers,
Brian
On Jan 30, 2008 11:03 AM, Hoffman, Billy <billy.hoffman@xxxxxx> wrote:
> From Brian:
> > This seems like a reasonable goal to me as well, check out
> > http://tim.dierks.org/2007/03/secure-in-browser-javascript-password.html
> > for another approach.
>
> !!! ... this kind of scares me. JavaScript cannot generate cryptographically secure random numbers.
>
> To sidestep this, Tim is gathering mouse movements, concating them together, converting it to big endian ints, SHA-1ing that, and then using that to select from a word list. Since the security of the system depends on how much entropy is in the original seed, let's see how that is created.
>
> function addSeed(x, y) {
> with (addSeed) {
> if (bits == 0 ||
> Math.abs(x - addSeed.lastX) > 2 ||
> Math.abs(y - addSeed.lastY) > 2) {
> ++bits;
> seed = seed + x + y;
> lastX = x;
> lastY = y;
>
> //snip
> }
> }
> }
>
> This tells us a few things: The seed will always be numeric. That drastically reduces possible character set) (and thus entropy) of what you are SHA-1ing.
>
> Furthermore, not only is this seed numeric, it has internal dependencies and predictable structure! Here is what the seed string looks like (dashes inserted for clarity)
>
> x1y1-x2y2-x3y3-x4-y4- ... -xiyi
>
> It's just a series of of X,Y coordinates. More importantly, those coordinates are related to one another. The value of x2 of depends on the value of x1 as the value of y2 depends on the value of y1. Specifically:
>
> x1 != x2
> x2 > x1 +2 or x2 < x-2
> x1 -Z < x2 < x1 + Z
>
> Z is some number that essentially bounds where the next point can be. For example, if a user has the mouse at (5,5) there is only so far they can move their mouse in the period of time between when the computer checks the position of the mouse. In other words, a user will not be a (5,5) and then move their cursor to (100,100) before the mousemove event fires.
>
> Lets say a user can only move the mouse 15 pixels in any direction between when the computer samples the mouse position (Z=15). If a user is currently at (100,100) (x1=100, y1=100) the value of x2 is bound by these constraints: 85 <= x2 <= 115 and x2 != {98, 99, 100, 101, 102}. (y2 is also bound by the same constraints) Based on the value of x1, there are only 25 possible values for x2. The same applies to y2. And this effect snowballs. x3 can take on only 25 possible values given the value of x2. It's a recurrence problem.
>
> The are more weaknesses. Given the average size of people's computer screens, you can make good estimates about the size of any of the coordinates. In other words, how many text characters does it take to represent the number of X. if 0 <=x <=9 it takes 1 character. If 10 <= x <= 99 it takes two. Consider the X coordinate if a user has a browsing window of 1024x768. There is a .97% chance X is composed of a single character. There is a 9.7% chance it is composed of 2 characters. There is a 87.8% chance it is composed of 3 characters. There is a 2.3% change it is composed of 4 characters. This helps delimit where one sample starts and the next begins. Using Conditional probability we get a good idea about what the length of the seed string was as well. Finally you also can make some assumptions about the initial values of x1 and y1. (Mouse is more likely to be in the center of the screen than along edges)
>
> What should you take away from all from this? GATHERING ENTROPY IS HARD! Only the most extreme least significant bits of operations like latancy between disk reads, network traffic, cache hits, etc, are used. You have access to none of this in JavaScript. JavaScript does provide a large number of significant digitswith its Date object. Checking time between user events and only using the least significant bits might be an acceptable approach, but I imagine you would need to gather a lot of data to do it.
>
> In short, Don't expect to be able to have any degree of cryptographically secure randomness in pure JavaScript. (You might be able to communication with an Java Applet which does have access to a cryptographically secure random number generator. Hmmmm....)
>
> Billy Hoffman
> --
> Manager, HP Security Labs
> HP Software
> Direct: 770-343-7069
> http://www.hp.com
>
>
>
----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Brought to you by http://www.webappsec.org
Search this site
|