[RESEARCH] PBKDF2?

[sergeevabc]

Dear Eric, could you be so kind and clarify how exactly PBKDF2 is used here? So far it seems unclear as hash-algorithms dropdown has no mention of it. Neither bits nor iterations are specified as well.

[heavensrevenge]

Sure, it isn't an algorithm we (PasswordMaker in all it's flavours in general) use to actually "create" passwords so It's not an option to actually choose from when it comes to user-facing options in order to keep 100% compatibility with all other PasswordMaker implementations that exist. I've added the use of PBKDF2 in two places which are in the extensions "General Options" page of extension configuration.

1. Keep Master Password Hash https://github.com/passwordmaker/chrome-passwordmaker/blob/master/javascript/popup.js#L80 which is a feature where you only need to type your paster password once and we compare internally for you if you've typed your 1 master password correctly to what you entered.
2. Sync Profiles Between Computers https://github.com/passwordmaker/chrome-passwordmaker/blob/master/javascript/settings.js#L221 Which means I don't even let your data reach Google's servers unencrypted by me so I derive the PBKDF2 based key and that data to sync is AES encrypted with a 256-bit key(that PBKDF2 value) which is only then synced to Google's sync servers so your settings follow you only if you explicitly say you want that to happen :+1:

In all cases at the current time (October 1, 2014) I use a default of 1000 iterations and a 256-bit salt size which you or anyone can see https://github.com/passwordmaker/chrome-passwordmaker/blob/master/javascript/settings.js#L246-L251 but I coded in a way to easily change the # of iterations to any value I want for future-proofing in a practical manner.

[heavensrevenge]

Let me know if you have any other questions @sergeevabc or if you need any clarification :)

[sergeevabc]

Eric, thank you for details.

You see, I came upon PasswordMakerPro after trying its light version called PasswordGenerator based on the same principles. Indeed, the latter produce same hashes with MD5/SHA1/SHA256, however interface of both popup and options page is slick, non that bloated. So why would I need a replacement?

Answer: to get PBKDF2 with at least 5000 iterations to slow things down a bit as current hash algorithms alone are vulnerable to rainbowtables, hashmaps, etc. Ideally, PBKDF2-HMAC-SHA256 (or even Bcrypt/Scrypt + SHA3) would suit security-concerned needs for years ahead. Alas, you say PBKDF2 is used just for internal routines like hashing master password (not using) and sync (not using either because of “less Google” policy).

In the end, question is about PasswordMakerPro’s future, when will it support stronger schemes?

P.S. Feel free to check Cryptopass, Hash0 and CtrlQpasswords to touch the future. :)

[mmlb]

@heavensrevenge if you think about implementing PBKDF2, I'd like to see scrypt also.

[heavensrevenge]

Well @sergeevabc you don't need a replacement unless that simple tool isn't powerful enough and you don't need you passwords anywhere else on any other device, in the end it up to which one you like better and which one works for how you do things. (btw if I do something badly def mention it so I can fix & improve it)

I did consider adding other functions and will sometime when the "time is right". In a way, it's still too soon since SHA-3 isn't officially finalized even thought the hash function was picked and won. I really do like keccak and I love BLAKE2s, but I'd have to worry about compatibility with all the other versions of Passwordmaker whenever I add them and it takes years to guarantee apparent or claimed security of a hash function.

Remember, how we construct a resulting password = hashAlgorithm, masterkey, url + username + modifier, whereToUseL33t, l33tLevel, selectedCharset, so this is way beyond a simple hash your password + domain way of most other password generators so I doubt any rainbow table could be constructed with that large of dataset for many years to come since rainbow tables are truly massive.

@mmlb I'm already using pbkdf2 internally and I have an scrypt implementation but haven't needed to include it. I could add it whenever it seems useful vs just adding it for the sake of trying to brag about features without the true benefit that feature gives. Remember we/I don't store the password at all, so theres nothing for a cracker to crack or exploit other than the options on how your password is created (profile details).

Using a key derivation function for password generation is very burdensome unless your willing to save your initialization vector and state to generate your correct password everywhere you go so cryptographic or at least unique hash functions suit this a tad better vs using PBKDF2 or scrypt for actual password generation. They are def better for long term offline storage of a password attackers can pound on for years though since it's their purpose.

[sergeevabc]

Eric, I'm trying to keep it as simple as possible, relatively fast, yet reliable.

That's why PasswordGenerator was initially chosen over PasswordMakerPro. There is no l33t, preffixes, suffixies, modifiers, etc. Just domain, masterkey, length, allchars, SHA256, and the result. That approach seemed secure enough till very recently, now it's not, by intuition.

That's why this thread about update possibilities happens. It's not a feature request to “extend with all modern and half-done algos”, but to promote a new recommended option, let's say for the next 5 years. Could it be PBKDF2-HMAC-SHA256 (using SJCL implementation) with X iterations?

[tasermonkey]

If its implemented for the chrome extension I think it should be easy enough for the android version: http://stackoverflow.com/questions/11628256/pbkdf2-with-sha256-on-android

[heavensrevenge]

Uhm well @tasermonkey atm I'm against adding PBKDF2 as an algorithm to choose for users from since it doesn't really buy us any security than we already have other than something to add to make uninformed users feel more at ease. It's only ever really useful when a stored value needs to be compared like password storage, it isn't really useful for password generation since its absolute overkill while adding complexity vs just adding another cryptographically secure hash function.

Either we would need to store a salt for every user/domain making every installation be dependant on unique state(data) used other than profile options or construct a 100% deterministic(nonrandom seed) to use in the PBKDF2 process which makes it pointless to use other than to ease people because then it would be just as easy to crack because all parameters would be known to the attacker if its done this way.

So adding any type of key derivation (pbkdf2 or scrypt) whose actual security is designed and reliant on a random/unique salt adds state that users need to config, can lose and not backup or ever remember again, it just seems like a bad fit and I'd much rather wait for SHA-3 to be finalized since it would actually be a good addition in the future.

Anyone who have also implemented pbkdf2/scrypt have any counterpoints that somehow show pbkdf2 increases security in a practical way in the case of password generation vs just adding it for the sake of sounding good to add?

[sergeevabc]

For example, there is a must try Mypass extension based on OneShallPass guidelines with a lot of how & why questions answered, including PBKDF2-HMAC-SHA choice and salt issues covered. Also there are numerous in-depth security articles like “Storing passwords securely” where the difference between “fast algos” for integrity checking.and “slow algos” for modern password hashing is explained. Communities such as Lastpass, 1Password and Stackexchange already caught that drift and deprecated other approaches exactly as IE6/7 support was widely abandoned once. Let’s move on, shall we?

P.S. Enterprise compression software WinRAR already uses BLAKE2. Future is knocking, common.

[heavensrevenge]

@sergeevabc One extension you may like is from a guy named @jither who's contributed to PasswordMaker Pro which is called "KeyPunk" https://github.com/Jither/KeyPunk It has PBKDF2 & SHA-3 and you can change the iteration count to whatever you like although its CSS seems to make it too small at 1st but if you know how to change CSS for the extension pop up size to be usable (or open the KeyPunk/src/index.html directly) it may be what would make you happy if you'd like to check it out and help him fix it up a little :)

[heavensrevenge]

So @sergeevabc have you tried out KeyPunk at all?

[sergeevabc]

@heavensrevenge Thank you for the input, hope long reply would excuse my delay and give you a pleasure reading.

Keypunk seems to be an ambitious effort, however abandoned half way months ago, alas. Actually I believe it is overbloated since day one in terms of

• UI (e.g. masterkey verification could be done without two masked fields comparison, password's length is a second thing after resource's name to change quickly, yet it's hidden under hood of profiles, let alone rewire thing and confusing password related both to masterkey and derivedkey),
• options that reduce output's strength (e.g. HMAC must used mandatory with no checkbox to turn it off, let alone hex salt (omg!) you'd better backup and ability to copy the result using Flash),
• dependencies (e.g. using CryptoJS instead of SJCL, AsmCrypto, etc).

In the end, Keypunk is about flavoring PasswordMaker with bleeding-edge hash functions and key stretching with outdated iterations number by default (65535), not about.rethinking how to implement the most secure yet friendly solution to date.

Being so pessimistic above and in the past, I'm excited to tell there are

• Bcrypt SecurePasswords (with video intro by author, stores masterkey in localStorage by default)
• Bcrypt BPasswd2 (with dubious mapping and author is too lazy to toggle div without jQuery)
• Scrypt MasterPasswordApp (the algorithm does it pretty close to how I imagined, however being cross-platform, app is not browser-ready yet, so I'm looking for a way to implement it).

By this time you could obviously call me a pain in the neck, so let me reveal the ultimate goal:

• remember a few strong masterkeys to access the most sensitive data
• create unmemorable passwords from masterkey for the rest of resources via deterministic generator
• save those passwords into Keepass and use its keylogger-resistant autofill where possible
• upload deterministic generator* to multiple CDN-powered places like JSbin and Kodtest to run it from anywhere as a backup solution to Keepass when keyfile is wiped to prevent disclosure and to deny naturally under questioning about specific resource**, device is stolen, broken or discharged, in untrusted environment like third-party machine of e-cafes and passenger terminals…
• split masterkey*\ via Shamir's scheme among trusted people on a case of amnesia and death

_that's why deterministic generator must be available as a single file with required js inside *_think of plausible deniability and Rubber-hose cryptanalysis as well ***optionally

Sounds too paranoid? Sufficient enough.

[Jither]

I'd never recommend KeyPunk to anyone - and not sure why anyone else would. That's made quite clear in the very first line of its README... It was developed for the use of a single person (me), in a matter of two days (excluding a few fixes). And it wasn't put on github for consumption, it was put there because someone wanted to see it.

But just to be clear: Every single thing you call "overbloated" is addressed in that readme too - or is just plain misinterpretation on your side. For example, no, it doesn't require the two masked fields, and the rewire thing is there for a very specific (and often used - by me, and several others) purpose.

Also, there are no options there that "reduce output's strength"; HMAC isn't mandatory; there's a checkbox to turn it off, and it's off by default; the hex salt is clearly noted as a WIP feature; ability to copy the result based on flash? Check what github and every single other "copy to clipboard" feature in existance does...

SJCL doesn't support the hashing algorithms needed, AsmCrypto was - and is - even less proven (and even more bug-ridden) than CryptoJS. "Outdated iterations number" is clearly explained, again, in the README. Although it's only explained for people actually interested in knowing why - since, again, it's not meant for "grab and use" by anyone except me.

etc. etc. etc.

And no, in the end KeyPunk was about letting me use PasswordMaker in the way I wanted to, rather than wait for someone to pick it up and improve it. Nothing ambitious about it. But someone eventually did pick up and improve PasswordMaker.

As for Bcrypt and Scrypt - in terms of password generation, they're even more useless than PKBDF2 in terms of security vs. performance in a javascript environment. Most of these added features (including SHA3, key derivation etc.) are also largely overkill - applying security considerations for storage of multiple passwords on a server to the case of generating single passwords of which two - not to mention 200 - will rarely - if ever - be seen in the wild in the same place. It's more buzzword-chasing than actual security considerations.

[heavensrevenge]

Sorry @Jither I quite liked some aspects of it but then again I have an eye that can see the beauty which @sergeevabc wasn't able to since I did go through your code.

The primary reason why I did recommend it was this: you allow both the salt and # of iterations to be manually be set by the user, in no other extension have I ever seen allows the changing of the iteration count of PBKDF2 so apparently @sergeevabc didn't see that he could increase the iteration count to 1-2 million if he wanted to lol.

He seems to just be very excessive towards tons of password generation products without truly understanding how cryptography works and just considers the extreme of things or doesn't see that what actually proves security is time, no "new" thing can EVER be considered secure, only after continued scrutiny will something be considered secure only because it hasn't been broken.

I'm glad you're able to chime in on the usage of key derivation functions such as PBKDF2, scrypt, and bcrypt; all of which are just insane in terms of password generation as I tried to mention it but many people don't seem to not understand and are looking at password generation from the point of a system/database admin which they actually are required because of their need to store the results and they directly hash a password of a limited length vs how we construct and what we feed into the hash which isn't a password directly which makes finding a hash we generate a whole different ball game from password "storage" in a server database. He(and many) doesn't realize that even a single cracking of a password that uses SHA256, a "cryptographic hash algorithm" for example would take hundreds of billions of years to iterate a 256-bit key-space even today with billions of NSA government powers, much more than a year or 2 it would take to simply change a password lol.

@sergeevabc I imagine you'll need to code your own password generation solution if you have the ability in order to get all of those extremely strong(always loved Shamir's secret) yet completely unnecessary features. But as thing's come up I will add to PasswordMaker Pro so long as the feature is actually useful and actually increases/compliments security :)

[sergeevabc]

Thanks for your input. So long.

[heavensrevenge]

I hope you can find a solution that makes you happy @sergeevabc , but chances are you'll probably have to code such a thing yourself. The PasswordMaker concept has been around for ~10 years way before I ever coded on it or even heard of it, and it exists on all platforms vs just a browser extension. So if you ever want to come back you bet we'll still be around :)