If an SGP request is hijacked by a malicious site, there is no way to validate the Salt before the master password is entered. If an identicon was provided based on the saved salt, and that identicon was shown on initial load, that should provide at least some protection from a SGP forgery. I've implemented just such a thing on my fork.

Clicking bookmarklet does nothing on https://www.etrade.com. Works on https://us.etrade.com/e/t/user/login

I have tried a few times, but it appears the use of "@" in the Domain/URL field is no longer being accepted. I had some cached versions in browsers that were still accepting, but clearing out cache on the working browsers results in that no longer working as well. I was using "user@url" for a password policy to generate passwords for certain users. Did something change that stripped that out? Do I need to download a previous version and run my own moving forward to allow that? Thanks for listening!

@chriszarate, would you be positively feel about making the supergenpass library stand-alone?

Currently you have the bookmarklet, app, and the library mashed together in one repository. I, as the maintainer of a Chrome extension, can not just update my dependency and get the newest algorithms and cookies.
Even if I include the full current project, there is still a lot of files in js directory with a lot of global names.
I want to simply dependencies: ["supergenpass"] in my package.json! :)

I suggest to split the actual password generating library into a separate repo, and make your bookmarklet repo use that library. Such programmatic access would allow your supergenpass consumers, such as my extension to be easier up-to-date with changes, as well as it would facilitate creation of new tools based on the library.

I am not simply requesting you to do it, I am ready to put my work where my words are.
I would extract the supergenpass lib from the current repo, make it modular, and transfer it to your ownership to be named chriszarate/supergenpass-lib or whatever,
and modify the extension repo to use that one.
In return, I need your consent and a pause in developing the current version in this repo to avoid complicated merges.

When changing passwords on most sites, they usually take input this way:

old password:
new password:
new password again:

Which confuses SGP, which would always fill in all three. Couldn't we easily detect the field name of "old password" and avoid it? Or in more rare situations like this:

password:
new password:
new password:

Just ignore "password" fields if the field name "new password" is present etc.

Previously, there existed a page where users could create a custom bookmarklet that hardcoded various options. I will restore this page to the new site for older versions of SGP.

There will no longer be an ability to create custom versions of the current version of SGP. The reasons for this are:

1. Options like password length, salt, and subdomain removal are stored by the mobile version in localstorage. The bookmarklet simply loads the mobile version in a floating iframe, so these options are effectively "hardcoded" into the bookmarklet.
2. Support for IE<10 is dropped. IE<10 limited the length of bookmarks, which meant the code was loaded from my server. This presents a security risk.
3. The option for hardcoding the master password is just too big a security risk. The option for hardcoding a hash for verifying your master password has been replaced (and improved) by the use of identicons. Recognize the identicon? You've typed your master password correctly.

Hi

I have been using SPG for a long time, always with a length greater then 10 (because a 10 chars password can be cracked by brute force with today's computers). But now that functionality is gone both from the mobile website and the bookmarklet! How could you do that!!!

Thanks.

Len is both the id of a form element, which elevates it to the global namespace, and a global variable intended to store the saved length.

This causes problems in the gp2_validate_length function

Basically you just need to give the input a different id (LenField) or something, and then change the places where it refers to the field to point to the new id.

You can demonstrate a nasty side-effect of this bug by entering a space into the length field and clicking generate. It'll enter an endless loop, and you'll have to wait for the browser to time-out.

Here's my fix:

        window.gp2_validate_length = function ( n ) {
            var default_length = parseInt( $('#Len').val(), 10 ) || 10; 
            try { LenMax } catch(e) { LenMax = ( b64_hash( 'test' ) ).length; }
            return ( parseInt( n, 10 ) ) ? Math.max( 4, Math.min( parseInt( n, 10 ), LenMax ) ) : default_length;
        };  

Well, don’t make me download any resources. Make the bookmarklet entirely self-contained.

Some forms will only let you submit after their validation functions have run, and they don't run unless they hear a keydown/keypress/change event. Since SGP populates passwords without firing those events, it should fire them manually.

Hi. In the old version there was a button to show me what I had actually typed. I found this really useful. It's a pain not knowing whether a password is wrong because I have mistyped it, or because I am trying to use the wrong password.

The <iframe> approach is certainly an improvement on the previous major version - thanks to @chriszarate for all the updates!

On the long and highly ranked discussion thread at http://akibjorklund.com/2009/supergenpass-is-not-that-secure , Steve Lewis writes (in 2010):

If SGP was changed to open a HTML file in an Iframe saved on the computer containing the application, that portion of the DOM might be isolated from the suspect page. The bookmarklet could possibly pass the domain as a parameter to the HTML file. Would this work as sort of a “secure” version of SGP?

and Tim Anderson replies

In order to open the page in an iframe, some DOM manipulation procedures need to be called. These procedures can be overwritten to steal your password by changing the ‘local’ page to one on a remote server. Even if it did work, the portion of the iframe isolated from the evil stuff on the page would be isolated from SGP.

Is this still the case? It would seem to be. Is there are a way of working around or preventing this? I'm thinking about it.

Sometimes the login is ajax based, on that case the SGP is not closed and stays visible.

I just spent a few minutes trying to figure out why I was getting different results between my phone and my desktop, until I realized that I had an extension auto-filling the "Secret Password" field on the desktop.

(Ironically, it was the SuperGenPass Chrome Session extension, but it could have been anything).

Looking over the issues list, I see somebody was already bitten by this in #44, and I suspect that #35 was also about this problem.

I suggest you either always show the secret password field so that people would be able to see if it was auto-filled, or better yet, generate the field dynamically when hitting the "Options" button, so that there's no chance for it to be auto-filled.

As it says - I am now locked out of quite a number of sites including Ebay and Paypal.

In GenPass I can choose the number of characters (10) but it generates the wrong password. When I try the Mobile version, clicking the gear wheel gives some options but what are they - MD5, SHA,TLD???

What is the secret password?

Why, when I choose 10 characters, does it generate a pw with16????

I'm using Firefox 29.0.1

Spare a thought for those of us who are not geeks.

:(

In an attempt to better understand how SGP works, I'm trying to manually generate the same passwords as it with a small script. Can you add some documentation about what transformations SGP is applying to derive a password? (Possibly related to #24)

www.fuelrewards.com is an example of a site that has css for iframes. In order to fix it for this site, set position: static in sgp.js for the iframe style

As the author of a GPLv3 native Android version of SuperGenPass, I'd love it if you could link to my project from the main site for users who aren't keen on using the bookmarklets. Is there a chance you could link to my and other perhaps even some other implementations of the algorithm? By banding together, we can become stronger and keep SuperGenPass more cohesive.

Hi

On chrome 35 on OS X, the latest version of the bookmarklet, on the Facebook page will load https://chriszarate.github.io/supergenpass/mobile/ instead of opening the little floating panel

For some reason I can't choose a password length of 23 when I have MD5 selected as the hash function, it worked fine in the older version. All my passwords use that length so until you implement it I'm stuck using my old bookmarklets, or I'll have to change every password everywhere by juggling the old and new systems.

Hi,

How do I alter bookmarklet so that by default it uses SHA and different password length?

Before SuperGenPass was hosted on Github, the latest version that had was 2.0.1. However the 5 Releases that are currently available for download all have version 0.., so I'm confused about the numbering scheme.

What's the relationship between the version before Github and after?

What is the purpose and usefulness of "salt"?

It's not like a regular salt, generated automatically and stored internally.
I suppose the user that wants to use it, has to add a random salt for every different website himself and keep track of them?

What is the advantage over just using different master passwords?

I am using SGP Beta on Safari and Chrome under OS X 10.8.5. Recently I have noticed SGP misbehaving within Safari and I think the problems began around the time I upgraded Safari from 6.0 to 6.1. SGP continues to function without issue in Chrome.

The problems that I am seeing include the number of generated characters not sticking - it continues to revert to 10 characters despite my setting it at 12 and despite my going to https://supergenpass.s3.amazonaws.com/index.html and running SGP. This behavior seems to be intermittent -- occasionally it goes to 12 characters but usually it wants to use 10.

Also, the SGP window is being auto-populated with my stored password (I think) and username instead of the domain of the current page. See attached photo.

I'd be happy to troubleshoot some more or provide any additional information if that would prove useful.

Michael

Would be nice, if you can raise LenField for mobile version up to 30? Thanks :)

Are there other actions that should have a keyboard shortcut? Should they use metakeys or only be triggered when no input field has focus?

I have the old mobile site http://supergenpass.com/mobile/ book marked everywhere, and it no longer works, any chance to get it back ?

The new bookmark shows the generated password when using the bookmarlet. The old version of the bookmarklet didn't do this unless the user clicked 'show password'. This behavior makes SGP significantly less secure when using computers in a public place (school, libraries, when the kids are watching etc.)

Please change the password so it is obscured by default.

...what's the recommended workflow when forced to change my password, when I was already using SGP, and a site asks me to generate a new one. I don't want to end up having to remember a different master password for each site as this would invalidate the advantage of SGP.

Thanks
Nigel Thorne
(ps.. I love SGP)

Add logic to conditionally load script over https when the login page is https. This prevents a security dialog in some browsers ("This page contains both secure and non-secure items").

This issue will not be implemented until the resources are migrated to Amazon CloudFront.

The mobile (online) version of SGP no longer generates the same password. Something broke.

If I have changed the number of characters for a given domain from 10 to something else and executed SGP during a Safari session, that number of characters is "remembered" for that domain until Safari is closed. But once I restart Safari or navigate to a new domain within a Safari session, the SGP reverts to 10 characters.

Within Chrome for OS X, SGP behaves better: once I set the number of characters, that value is populated by default on any new domains and even once Chrome is shut down and restarted.

Is there any way to make Safari behave like Chrome with respect to SGP? If not, is there a way for me to make the "global" default number of characters something other than 10?

Finally, is there anyway to access SGP's extra settings via the keyboard? In other words, a keyboard shortcut equivalent to clicking the "gear" icon?

Thanks in advance,

Michael

OS X 10.8.5
Safari 6.1.3
Chrome 34.0.1847.131

Some of us still use the old genpass bookmarklet in some places, however it looks as though the bookmarklet has a reference to a page which no longer exists - http://supergenpass.com/genpass/mobile.html - and I guess this is the reason I can't get the bookmarklet working?

I've forked SuperGenPass to include support for bcrypt and symbols using base85 rather than base64. For me this addresses the two biggest weaknesses of SGP:

1. SGP generated password is unnecessarily weak, and can be more easily compromised when password database is compromised (see In, Linked). This can be resolved by manually padding the SGP password but, I'd prefer if the tool did the work.

2. Master password retrieval is potentially too easy because of the inherent weakness of using a "fast" hashing algorithm if the domain/SGP password has already been compromised (see 1). By using bcrypt to arrive at the SGP password, it becomes infeasible to brute-force even a relatively weak master password.

See: cmcnulty/SuperGenPass@5875e2d

Ever since my bank re-designed their website Supergenpass doesn't auto-populate the fields. I assume this is because the login is inside of an i-frame?

https://www.unitusccu.com/

There may be nothing you can do about it, but I thought I'd ask.

This is really only for my benefit, but it would be nice if in sgp.js where you bind the message event, if in addition to testing for Doman equals origin, if it also tested for e.originalEvent.data !== "". This enables asynchronous password generation techniques to not have the target password turn green until an actual password is sent.

Chris,

I've been using SGP for years and so does a few other ppl I recommended it to. Perhaps you could add a donate button to get some kickback support.

When I launch SGP from the bookmarklet in Safari 6.0.2, the number of character defaults to 10. I change that to my desired default and generate a password. Unlike prior versions of SGP, the next time I launch the bookmarklet, it goes back to a starting point of 10 characters. Is this the intended behavior of am I doing something wrong?

In order to support alternate password generation libraries, it would be nice if the SGP (and the API of supergenpass-lib) provided a mechanism for both asynchronous password generation. This would take the form of two callbacks passed into the options array of the password generator function, a progress callback and a completed callback. I already have the code in my fork, I'll split it off into a pull request whenever I get a chance, if I get an indication that such a pull would be considered.

https://github.com/chriszarate/supergenpass/wiki/FAQ is useful!

Styles are read-only in IE8, so the following code from sgp.js causes an error and doesn't load the styles:

jQuery("<style/>",{type:'text/css'}).html(Styles).appendTo(jQuery('head',$Target));

However, you can simply do this to work around the issue for IE8:

jQuery("<style type='text/css'>" + Styles + "</style>").appendTo(jQuery('head',$Target));

Using the version at https://chriszarate.github.io/supergenpass/mobile/, I get different results when I choose different lengths of passwords.
For these examples, I will use a password of "password" and a domain of "dc1" (because I was making passwords for intranet servers). I used SHA as the hash.

Length of 4: mE05
Length of 6: mE05Ec (expected)
Length of 7: nAFtfS5 (woah, why?)
Length of 20: nAFtfS58gYOAQ7a7fiWW (expected)

Why are there variations based on the length? I don't think the original SGP worked that way.

The weird hybrid text box that contains the password in the mobile version is not selectable for copy/paste on Android. I see the logic of the hybrid text box on the desktop version, but the mobile version should show the password in a normal text box, with no obfuscation, as the default. Otherwise it's very complicated to copy/paste and defeats the purpose of having a mobile version at all.

The old bookmarklet had a checkbox to "Disable subdomain removal". I used it extensively. Any reason why you considered whatever it used to be good for does not apply any more? Please bring it back.

If you're on a page the has input elements, and the focus is in one of those elements and you start SGP, the bookmarklet does NOT get the focus. Try this page:

https://www.perturb.org/homepage/

When you first load that page the focus is in the Google box. Starting SGP does not put the focus in the password field. If you click in the blue background so nothing has the focus and launch (or even re-launch) SGP the password field gets the focus.

I've only tested this in Firefox 28. Don't know if it affects other browsers

Personally, offline support is much more important to me than the added security of using an iframe, since:

• the code is not loaded over SSL, so you get the added potential of MITM
• the code is still vulnerable to malicious host pages (modifying the

so I don't really see the point, and would love to have a version that works offline like v2 (but with bugs fixed, notably google login). Is this on the roadmap?

Hi Chris,

I am longtime user of SuperGenPass. It is quite a useful tool -- thank you for providing it. The latest version of the beta (SGP3) has become broken for me recently. It seems to have started around the same time that the styling of the iframe changed to show drop shadows around the user input fields. When I launch the bookmarklet, extraneous text is immediately filled in the password field on the login page of whatever website I'm on. Then, when I generate the SGP password, an excess number of characters are inserted in the password field.

This problem is occurring in Safari 6.0.2 on OS X 10.8.2. It does not occur using Firefox 16.0.2 on OS X 10.8.2.

Using the Web Inspector Develop Tool of Safari I was able to convert the "privacy dots" showing in the password field to text. The text initially being inserted into the password field each time is: {"height":"168"}. Then, once the password is generated, the password field is populated with {"result":"SGPPassword"}, where SGPPassword is the expected randomized SGP password characters.

While exploring this problem I noticed another issue that seemed quite strange to me. Perhaps this is not a bug, but should the first characters match no matter the length of the desired output password? Consider:

master password: macbook
domain: apple.com
SGP password, length: j9NZ1Eao, 8
SGP password, length: j9NZ1Eao0, 9
SGP password, length: j9NZ1Eao0Z, 10
SGP password, length: ztNTNLhqKF9, 11
SGP password, length: ztNTNLhqKF9n, 12

I can provide more info and screen shots if that would be helpful.

Best regards,

Michael

It looks like the gp2_validate_length calculates the LenMax based off of b64_hash('test'), but what I've noticed is that all cases of b64_hash will return a string with the trailing characters 'AA'. You can easily see this by simply running the supergenpass and setting the password length to 24 and generate passwords for any number of strings. In fact, you'll notice that even the 21st character does not have a lot of entropy, either returning as 'Q', 'w', or 'A' most (all?) of the time.

This would indicate that the true LenMax is actually 21?

not sure what happened, i relied on this quite a bit, but the recent updates in the last 24hrs are not spitting out what i recognize as my normal passwords. i used the old supergenpass mobile version with just master, url, and character limit. am i missing something with the new setup, or am i going to have to reset all my passwords now?