Master Password + Secret

[mrmachine]

If you have strong secret (say a randomly generated 50 character string), is it still necessary to have a strong master password? Or would a shorter password that is quicker to type (say 8 random characters) be sufficient?

I think it was mentioned that if an attacker has local access to the machine you have to assume the secret is compromised, but if they already have local access you might already have bigger problems?

Does having a long random secret with a short master password still provide great protection against remote brute force attacks if one of your sites is compromised and the attacker has your hashed password?

[chriszarate]

The biggest benefit of a secret is that, when SGP is first loaded, an identicon representing that secret is displayed to you. This allows you to confirm that you are accessing SGP from supergenpass.com, which is the only site that has access to your secret, stored in your browser's localstorage.

An attacker who obtains one of your hashed passwords would need to know that you use SGP in order to attempt any brute-forcing. If the attacker did happen to know that (or guess), a 50-character complex secret password, even combined with a weak master password, should be an effective deterrent for the foreseeable future.

But, in general, it's important to remember that SGP is a password generator, not a user security tool. It helps you avoid commonly exploited password patterns but should not give you confidence that your accounts are immune to attacks. If an attacker is targeting you personally or your computer specifically, there are likely softer targets that will yield to concerted effort.

[mrmachine]

Since SGP is deterministic, assuming the same secret and master password is always used, cracking tools could easily add an SGP rule to their tools and then all your passwords become at risk of any one of your sites is compromised. Are there any other options that could be stored per user like the secret that change the algorithm to make it more difficult for attackers to include a general SGP rule? For example, could I choose to hash at least 20 times instead of 10, or hyphenate every 4 characters (also making it easier to read out if I can't copy and paste), or always append a suffix to the generated password (eg you use 67% as an example to satisfy complexity rules)? Any of these options could also be stored along with the secret without breaking default compatibility, and the suffix would make it more difficult to generate additional passwords if one is brute forced?

[chriszarate]

My goal with SGP is to provide a reasonable amount of customization to benefit the broadest spectrum of users. Adding more options (in my opinion only) makes using SGP more complicated, confusing, and error-prone.

That's not to say that your concerns are _un_reasonable—just that SGP doesn't target that level of customization. SGP is open source for this very reason. I encourage you to fork SGP and implement the additional customizations you describe, and I'd be happy to take a look and offer any help that I can.

You should also take a look at the implementations wiki page before getting started to see if there's another project you could use as a starting point.

[mrmachine]

Would you consider merging such changes if they were to be implemented in a fork?

I can see that it might get confusing if you start packing in a tonne of options, but I think it would be really great to have just one option in SGP proper that would allow a user to alter the algorithm itself in some way and therefore make it far less likely for their master password to be brute forced by an attacker who has integrated the current/default algorithm into their toolset.

For example, the bash implementation is very simple, so I can't imagine it would be very difficult for an attacker to check 10 and 24 character passwords (probably the most popular SGP password lengths) made up of [A-Za-z0-9] with at least one lowercase, uppercase and numeral, against the SGP algorithm.

If an attacker was able to brute force a master password because one low security site got hacked and their hashed password list was leaked, that users passwords for all other sites would be compromised. Brute force attacks are only going to get easier as CPU power increases and mega GPU arrays can be rented from the cloud.

This could even kill two birds with one stone and make SGP more convenient to use, as well as more secure. Your FAQ mentions memorising and adding your own suffix to passwords in order to meet password complexity rules. Why not just automate this step to save the user having to manually copy and edit the generated password every time they log in, as well as decreasing the chance of their master password being brute forced?

Especially as SGP is featured on privacytools.io and a lot of people are starting to seek out password manager software, I think it's important that SGP itself doest everything it can to mitigate the risks of a deterministic algorithm. This could be a good point of difference compared to the other similar options that are available.

[chriszarate]

I'd definitely consider a merge if the added functionality was activated via feature flags and not by default. That way your proposed features could be available to those that self-host, but the hosted version at supergenpass.com would not change (or might change only in response to a custom query string variable).

An overriding concern for me stems from the fact that SGP is a browser tool without a centralized user data store. Configuration is kept in localstorage. Therefore SGP must be reconfigured from scratch whenever the user downloads a new browser, gets a new phone, opens up an incognito tab, uses a public/untrusted computer, etc.

Every added configuration option adds entropy that can help resist attacks, but also adds complexity and friction for the user, which can lead to frustration or lockout.

I care about privacy and security, and I especially admire and appreciate the efforts of those who think deeply about how to protect themselves online. However, I am someone who seeks to balance these efforts with a dose of practicality and ease of use. SGP probably isn't going to be (nor was it ever) a tool that stays one step ahead of hackers. But it does seek to provide, out-of-the-box, a reasonably good approach for those of us that might otherwise be tempted into insecure habits.

[dbakker]

If you want to make your master password harder to bruteforce the easiest solution is to simply make it larger.

If for example you make the iteration count configurable between 10 and 100 that would add 90 extra possibilities for password crackers to consider. Roughly the same as adding 1 or 2 characters to your password. So for example, I believe supergenpass('foo', iteration_count=85) would be about as strong as supergenpass('foo-85').

For example, the bash implementation is very simple, so I can't imagine it would be very difficult for an attacker to check 10 and 24 character passwords (probably the most popular SGP password lengths) made up of [A-Za-z0-9] with at least one lowercase, uppercase and numeral, against the SGP algorithm.

There are 62^24 different 24 character password (with random characters chosen from a-zA-Z0-9). Written out that are 10,408,797,222,153,426,578,715,765,348,940,396,820,955,136 different possible passwords. That's an insane amount of possible passwords to check.

To illustrate: Imagine our attacker has the resources to check 100 billion billion passwords per second. (Or 100 * 10^9 * 10^9 = 100000000000000000000.) It would take that hardware (62^24 / (100 * 10^9 * 10^9)) / 60 / 60 / 24 / 356 = 3,384,050,282,899,444 years to try all 24 characters.

If the attacker were in the possession of a quantum computer however, then the story would be different: a keys strength is reduced by about half its size (according to Wikipedias page about quantum computing). If you want to prepare for this, a 43 character password (256-bit) should give you absolute security.

Another thing to consider is that many 20-character master password + domain combinations will happen to generate the same 10-character output. So any attacker will need at least 2 generated passwords to even try deriving your master password.