For the longest time I was considering using a Javascript bookmarklet to generate the passwords for the different sites I visit to avoid the problem of "similar passwords everywhere", yet still be portable. However, after reading this paper it became clear to me that using this method would mean that a single malicious page could compromise my whole security. Now I'm pondering the following solution: a bookmarklet, which would only do one thing: open an URL in a new page with the original URL appended (for example http://example.com/password_man.html?url=slashdot.org ). The script located on the page from example.com would do the actual password generation. Does anybody see any security problem with this approach? While it is less convenient than the original one, as far as I can see, even a malicious page could only see the password it gets and would not have access to sensitive information like the master password. Am I correct in assuming this? More clarifications: The generating of the password will be done entirely client-side. The "password_man.html" mentioned in the example above will contain javascript code similar to the one already contained in bookmarklets and it will contain an entry field for your to specify the master password The interpretation of the "url" parameter will also be done client-side. I'm thinking of hosting this file as a particular revision on my google code account (ie. v1234 of password_man.html), which would provide assurances that I'm not changing the page underneath the users Also, HTTP/HTTPS is not an issue, since all the processing is done by the client browser, no data is sent back to the server. You might argue that a MITM attack could modify the page so that it sends back the generated password for example (or the master password for that matter) in the case that you are using a clear-text protocol (like HTTP), but if you already have a MITM situation there are other avenues of attack which are easier to do (for example: snooping the password from the request which is submitting it, or snooping the session id, etc) Update : after searching around and thinking about the problem, I concluded that there is no way this can be done securely within the same page. Even if the bookmarklet would only capture the domain and open up a new window (via window.open), a malicious site could always override window.open, such that it would open a copy of the page which would actually capture the master password (essentially perform a phising attack).

Reputation: 13118

What are the security considerations for a javascript password generator?

For the longest time I was considering using a Javascript bookmarklet to generate the passwords for the different sites I visit to avoid the problem of "similar passwords everywhere", yet still be portable. However, after reading this paper it became clear to me that using this method would mean that a single malicious page could compromise my whole security.

Now I'm pondering the following solution: a bookmarklet, which would only do one thing: open an URL in a new page with the original URL appended (for example http://example.com/password_man.html?url=slashdot.org). The script located on the page from example.com would do the actual password generation.

Does anybody see any security problem with this approach? While it is less convenient than the original one, as far as I can see, even a malicious page could only see the password it gets and would not have access to sensitive information like the master password. Am I correct in assuming this?

More clarifications:

The generating of the password will be done entirely client-side. The "password_man.html" mentioned in the example above will contain javascript code similar to the one already contained in bookmarklets and it will contain an entry field for your to specify the master password
The interpretation of the "url" parameter will also be done client-side. I'm thinking of hosting this file as a particular revision on my google code account (ie. v1234 of password_man.html), which would provide assurances that I'm not changing the page underneath the users
Also, HTTP/HTTPS is not an issue, since all the processing is done by the client browser, no data is sent back to the server. You might argue that a MITM attack could modify the page so that it sends back the generated password for example (or the master password for that matter) in the case that you are using a clear-text protocol (like HTTP), but if you already have a MITM situation there are other avenues of attack which are easier to do (for example: snooping the password from the request which is submitting it, or snooping the session id, etc)

Update: after searching around and thinking about the problem, I concluded that there is no way this can be done securely within the same page. Even if the bookmarklet would only capture the domain and open up a new window (via window.open), a malicious site could always override window.open, such that it would open a copy of the page which would actually capture the master password (essentially perform a phising attack).

Upvotes: 4

Answers (4)

Mike Samuel

Reputation: 120516

Javascripts PRNGs are usually not cryptographically strong: https://bugzilla.mozilla.org/attachment.cgi?id=349768 ; so if you use to generate passwords, other sites might be able to guess the generated password or even influence the password chosen.

Upvotes: 0

Pēteris Caune

Reputation: 45112

supergenpass sounds very similar to what you're proposing to make.

If requirement for being implemented as bookmarklet is portability, there are existing multi-platform password managers. For example, I'm using Lastpass, it supports all major browsers, also works in Opera Mini, also comes in bookmarklet form.

Upvotes: 2

Devon_C_Miller

Reputation: 16528

If you don't mind a Firefox-centric solution take a look at Password Hasher. There is "portable page" option that allows you to generate a page that can be used with other browsers, but I have only tried it with Chrome

The source for it is available here if you want to adapt it for another browser.

Upvotes: 0

James Black

Reputation: 41858

You may want to pass in a passphrase also, along with the url, that way there is two things that must be known in order to regenerate the password.

If you pass in just the url and it always goes to the same password then only one person can use this application.

The odds that two people will use the same passphrase is unlikely, and you can use the same passphrase for every site.

If you use an https connection then it would be more secure from snooping.

I believe you have some usability issues with your approach, and if you use http connection then you will also be vulnerable to snooping. The fact that someone can get the password by knowing the url means that this is more vulnerable than using the same password on each site, IMO.

Update: Due to the clarification my answer changes.

Basically, in javascript you can have private members, so that other code can't see the values, unless something like firebug is used, but then the user is the one looking.

This link will help explain this more: http://www.crockford.com/javascript/private.html

If you put the master passphrase and all related information into here, and do the password generation then no other javascript code can get that information, as you will create setters with no getters.

This should enable you to have a secure password generation page.

Upvotes: 0

What are the security considerations for a javascript password generator?

Answers (4)

Related Questions