Allow user to set alternative hashing algorithm

[brettcannon]

Either bcrypt or scrypt. That way people worried about MD5 can stop worrying. Can also reverse string concatenation order to deal with lengthening attacks.

This is essentially Oplop v2. Would require a VERY visual shift in the UI so people know which algorithm they are using (different colours and icon?).

[brettcannon]

Other tweaks that could be made:

• Guarantee an uppercase and lowercase letter

Open questions are:

• Is it finally time to extend to 10 characters? Has the web finally gotten its password policies straightened out enough to make longer passwords commonly acceptable unlike back in 2006? Could also shift it so that any additions required to make the password pass requirement hurdles are additions instead of substitutions in the first 8 characters.
• Should a non-alphanumeric character be guaranteed in the output?

[brettcannon]

Another thing to consider is the addition of a salt. Maybe use HMAC or something to mix the salt with the nickname? That way the "salt" argument to (b|s)crypt is truly unique per user instead of potentially being consistent for people (e.g. everyone choosing amazon.com as a nickname but instead hmac(salt+'amazon.com')).

This could be an optional feature that gets saved into the setttings. Then again, if you are going to care enough to want to use scrypt over MD5, it probably should be required so that people don't forget to set it (i.e. if you think "salt" is something you put on your food, v2 is not for you).

[brettcannon]

First off, that website gives no details on how that number is calculated, so I consider it a dubious value.

Second, what exactly are you protecting against? The threat model only worries if an adversary figures out you are using Oplop, gets a hold of an account password, and knows the nickname used for that account password. Even step 1 is difficult unless you advertise the fact you use Oplop online. Otherwise if someone breaks into e.g. LinkedIn and manages to crack every password by figuring out the salt used and thus gets your account password for LinkedIn, who cares? Unless they piece together that your account password came from Oplop and they explicitly want to attack you are they going to bother with trying to get your master password (unless you have been reusing account passwords in which case I can't help you =).

As for scrypt over md5, it's is more difficult to reverse as scrypt is specifically designed to be a costly algorithm to use.

[brettcannon]

And both the use of md5 and the length choice are discussed in the FAQ.

[brettcannon]

Possible approach as outlined by a user: https://plus.google.com/u/0/110389149377588379226/posts/9JNJcm4PzUF

[elasticdog]

FYI, almost all of the suggestions here are exactly what has been done by Master Password: http://masterpasswordapp.com/algorithm.html

[steve9001]

@brettcannon Thanks for Oplop, it's been a useful tool.

I've been working on an update of the Oplop algorithm, tentatively calling it either Oplop v2 or Oplop 2019 (more on that below). The intent is to improve the generated passwords to be adequate for several years, the way Oplop v1 has been. Implementations can support both versions to facilitate user migration, and new users should start with the newest version.

I'd be interested in any comments on the plan, and if you'd rather it not be associated with Oplop then let me know.

Strengths of Oplop v1

• reasonably secure unique password for each account
• mentally scalable and sustainable for user
• no reliance on third party application or storage

Weaknesses of Oplop v1

• 8 character length is too short
• does not guarantee upper, lower, symbol
• method of guaranteeing digit is problematic
• use of MD5 is problematic

Proposed Oplop v2

• preserve the user experience of v1
• 12 character length
• guarantee upper, lower, digit and symbol for password policy
• replace md5 with a better key derivation function such as PBKDF2 or bcrypt

Proposal for future upgrades

As an alternative to being a one-time update of the algorithm, this could be the start of a sequence of updates.

For example, using a hash function such as bcrypt with tunable difficulty parameters will require fixing the values of those parameters so all implementations are using the same values. But the purpose of those parameters is to allow increasing difficulty over time in response to Moore's law or whatever. A future update of the Oplop algorithm could include adjustments to those parameters.

A standard upgrage workflow that does not excessively burden the user experience could be used repeatedly. So for example today's proposed update could be called Oplop 2019, and use bcrypt with certain parameter values.

The next update might be Oplop 2024 using different parameters or a different hashing algorithm, and maybe also producing longer passwords with more permitted characters in them. These decisions can be made in the future based on what makes sense at that time.

Keeping with the light weight mental overhead, users should be able to fairly easily recall e.g., that they have migrated everything from Oplop v1 to Oplop 2019, or that are in the process of migrating from Oplop 2019 to Oplop 2024. There might be no getting around the tedium of manually changing all of one's account passwords, but the workflow would be intuitive and able to be done gradually during the course of normal usage.

Choosing a new hashing function

PBKDF2, bcrypt, scrypt, and Argon2 all seem to be reasonable candidates from a security perspective. Possibly a more important consideration is the availability and quality of implementations across many programming languages, including the ease of using them in an Oplop implementation.
The older and more established hash functions such as PBKDF2 seem to score better in those respects.

Choosing random values

A simple pseudo-random number generator (PRNG) seeded with bytes from the digest is used to enforce the password policy constraints.
The implementation is demonstrated to have a uniform distribution adequate for our purposes.
https://gist.github.com/blixt/f17b47c62508be59987b

Proposed steps for Oplop 2019

• compute the digest from the nickname and master password
• start with the first 12 characters of the digest
• replace a random character with a random uppercase
• replace a different random character with a random lowercase
• replace a different random character with a random digit
• replace a different random character with a random symbol

Open questions

• which digest function to use and what parameter values (perhaps target ~1s time on "typical" device)
• choose set of allowed symbol characters

References

https://github.com/brettcannon/oplop
https://crypto.stackexchange.com/questions/3489/do-md5s-weaknesses-affect-oplop
http://www.cs.utexas.edu/~bwaters/publications/papers/www2005.pdf
https://gist.github.com/blixt/f17b47c62508be59987b

[brettcannon]

I would increase the length to 16 characters, otherwise sounds like a reasonable update!

One thing I would say is that there be no tunable arguments and it is very much a "version 1 vs version 2" choice. That makes it easy to just add a single enum-like value to one's list of labels so that you can track which version to use compared to having to track more details.

As for forking this, that's totally fine with a name change. I actually don't use the project anymore so no need to involve me (link back is nice to show where the idea originally came from and to communicate to folks it is a fork).

[brettcannon]

Since I am not developing this project anymore, I'm archiving the repository.