Words (Diceware) with options to satisfy password criteria
I love the new(ish) diceware passwords feature. I ignored it for a while until I finally encountered my first few passwords I had to enter on other people's devices. I looked like such a tool shifting my eyes between my iphone and the computer for 2 minutes...
I use Words passwords now if I suspect a possibility of needing to enter the password manually, but many websites have unfortunate requirements (e.g. ≥ 1 upper/lower/digit/symbol). Symbol can be solved with the user's choice of separators, so problem already solved. Upper/lower could be added as an option and simply shift the generated Words password to title case, thus preserving its memorability. For digits, I guess throw a number at the beginning of each word, or just at the beginning or end of the password, or maybe options to cover a few different possibilities.
My goal here is not to increase password entropy, but to satisfy criteria without having to modify the password myself. You see, I'm very lazy...
To be precise, I'm too lazy to hop over to xkpasswd.net so I want you guys to implement the same thing he did but with fewer options.
1Password Version: 1Password Version 6.2.1 (621001) Mac App Store
Extension Version: Not Provided
OS Version: OS X 10.11.4
Sync Type: Not Provided
Comments
-
Hi @twilsonco ,
I had the exact same problem when I had to change a password recently. We are planning future enhancements to the password generator. And we'll be keeping this use case in mind. I don't have a timeline on when we'll be able to offer this, but we will consider your feedback when we do make those enhancements.
Cheers,
Kevin0 -
I think that this would be a great addition. More and more I am hitting websites that insist on an uppercase letter and a numeral, which obviously requires me modifying my passwords of only lowercase words.
0 -
Thanks for the feedback! I've passed your feedback along, but as ag_kevin said, we don't have a timeline for when any changes might be made.
ref: OPM-1378
0 -
@SpikeGuy: However, I should point out that Diceware/Wordlist passwords will always be weaker than a character-based password of the same length. So really it's best to use a character-based password unless you have an express need to memorize and/or type the password for a specific site. Cheers! :)
0 -
@brenty i'm unconvinced that a Wordlist password is weaker than a completely random password under normal circumstances. Certainly, if you know that One is using a Wordlist password it becomes less secure, but there's no such guarantee for any given password. Furthermore, an algorithm meant to guess at Wordlist passwords still needs to consider upper and lower case, as well as a range of potential delimiting characters, which could be changing randomly between each word. If you utilized the full capabilities of the xkcd password generator then it seems to me that the password should be, under practical conditions, every bit as secure as a completely random password, even if technically the entropy of the word list password is less.
Since you guys are the default password experts, I assume you have relevant literature at hand explaining precisely why a word list password would be less secure in general. If so, could you point me in the right direction?
0 -
@twilsonco: I think it's pretty much by definition that a wordlist-based password has lower entropy than a password of the same length based on fully randomized characters. The latter has the highest possible entropy. So any system that limits the possible passwords of that same length, will naturally have lower entropy.
Then you might ask if that lower entropy matters in practice. As long as the entropy of the wordlist password is high enough, then it probably doesn't matter. But it's still true that it's a weaker password.
Also, you should never count on what a potential hacker might or might not know about your password. That's called security through obscurity and is discouraged. In this specific case, you can also look at it this way: A hacker is never even going to try to break a fully randomized character-based password of substantial length. But he may indeed try a wordlist attack on it. But again, provided the password is long enough, he is unlikely to succeed.
0 -
@pervel I agree the entropy of a random password will always be higher, unless your culture speaks a language composed of words that take the form of encrypted blocks of ascii characters!
Given a reasonable length cap—say, 32 characters, and utilizing a mix of upper/lower case words and with randomized numerical/special characters as delimiters, wouldn't such a password be sufficient for use under most conditions?
Also, any update as to the OP request?
0 -
@pervel I agree the entropy of a random password will always be higher, unless your culture speaks a language composed of words that take the form of encrypted blocks of ascii characters!
@twilsonco: This! So awesome. :lol:
I apologize for not going into more detail. Sometimes it isn't needed/wanted, so I try to strike a balance and not bore too many people. And I have to be honest, I was very confused at first because I'd just replied in a similar discussion the other day and thought this was a followup to that...but this is an older one I'd forgotten about. ;)
Given a reasonable length cap—say, 32 characters, and utilizing a mix of upper/lower case words and with randomized numerical/special characters as delimiters, wouldn't such a password be sufficient for use under most conditions?
Yes. Because what we're really after is making the password infeasible to guess, word-based passwords are going to be more than sufficient in most cases. Typically 4 words is deemed more than strong enough. But that's today. It could change. And since changing passwords is a chore, I use character-based wherever I can because that's the best "bang for the buck", and if I can use 5 or more in word-based scenario, I'll do that. It's all about maximizing password strength to minimize risk, not just now but in the future as well.
Also, any update as to the OP request?
Nothing to announce at the moment, but we are working toward a revamp of the password generator in the future, so it's good to have feedback like this.
Getting back to comparative entropy, I know it's tricky and I've muddied the waters previously by referring to characters, but since word-based passwords are constructed with a certain number of characters in mind the indeterminate length is simultaneously a blessing (with regard to attacks) and a curse (when it comes to satisfying password requirements).
The word list, at present, has over 18k items, giving you roughly 14 bits per word. So a four word pass phrase is 56 bits. Not bad! But when we compare it to a character-based password, we can get more entropy with a much shorter length:
31 symbols
!"#$%&'()*+,-./\:;?@[]^_`{|}~><
10 digits
26 capital letters
26 lowercase letters
= 93 characters totallog2(93) = 6.5391588111 <- bits of entropy per character
6.5391588111(9) <- length of password
= 58.85242929 <- bits of entropy totalThat's right, a nine character password edges out four words. But, to be fair, this is using a lot of characters which may or may not be allowed in any given password. So to level the playing field a bit, let's use only lowercase letters to compare both word- and character-based:
log2(26) = 4.7004397181 <- bits of entropy per character
4.7004397181(12) <- length of password
= 56.40527664 <- bits of entropy totalSo in the extreme case where we're constrained to only lowercase letters, 12 characters versus 4 words is a close comparison.
You're right that mixing things up can help with word-based passwords, but I do think that works against their strength, which is that they're easy to memorize and type. Delimiters can help both with entropy and ease-of-use, but I think in cases where we're concerned about maximizing password strength (rather than usability), character-based really needs to be the go-to, as it offers a tremendous benefit in that regard. Cheers! :)
0 -
@brenty Thanks for the great explanation!
I think the comparison of word-based to all lower case characters is supportive of my original request, since the 1Password word-based recipe limits you to lower case :p .
Clarification
Could you comment on the method(s) of attack that should be considered? I'm very ignorant to the subject, but I figure that by using varying special characters and numbers as delimiters and alternating between upper and lower case words, the attacker needs to include the full 93 characters in order for a brute force attack to work. If they're brute-forcing assuming random password then you get the same entropy-per-character as you listed above for a fully random password. If they're using a word-based attack that includes the variations I propose, then wouldn't the entropy calculation now involve the 18k words, another 18k WORDS, as well as the 10 digits and 31 symbols? I don't know how the entropy calculation would be performed, since the word would be entirely UPPER or lower, and you only get one delimiter per word (though that could easily be increased).
So in the extreme case where we're constrained to only lowercase letters, 12 characters versus 4 words is a close comparison.
With that in mind, wouldn't the entropy of this modified word-based password potentially be equivalent to a random password? Clearly random is more entropy, so let's be more specific: If an all lower case random 12-character password is on par with a 4-word word-based password, would a 12-character (from a 93 character set) be comparable to a 4-word modified word-based password? If not, could you do a similar
number of random characters vs number of wordscalculation for a random 93-character set password vs my modified word-based password?I guess I'm still typing...
I agree that the extreme case I proposed with random delimiters and use of upper/lower case characters works against one of the main strengths of word-based, memorability.
In my own use, however, I've found that because I have my phone on me anyways, typability (which should be a real word) is the more important of the word-based password's strengths. This is the case where you're on a friend's computer or otherwise unable to initiate a copy-paste. With the password in front of me on my phone, changing delimiters and words changing from UPPER to lower just barely slows me down (It's easy to hit caps-lock every other word or type with shift pressed, and there are so few delimiters even in a large word-based password that they add negligible time), especially compared to the snail's pace of entering in a random password manually.
Personally, since I use a password manager anyways (1Password, if anyone wants to know which password manager I'd recommend!), I always max out the password length whether I use a random or word-based password. The main reason I've switched primarily to word-based passwords is due to the seldom-but-horifying instances where I've had to type in a 64 character random password, meticulously checking each character as I type, lest I need enter it again, where an equivalent length word-based password would've taken a small fraction of the time and effort.
0 -
@brenty Thanks for the great explanation!
@twilsonco: You're totally welcome! Thanks to you for starting — and following up on — this interesting discussion! :chuffed:
I think the comparison of word-based to all lower case characters is supportive of my original request, since the 1Password word-based recipe limits you to lower case :p .
Haha agreed. Though I do think that in most cases we don't have to limit character-based passwords in this fashion, that's part of why I included it — and regardless, I think it helps illustrate things better than if I just dumped the bits of entropy for "words" and "characters" on you. ;)
I apologize in advance that I'm about to gloss over the rest of your excellent points and pick on you a bit here, but hopefully it helps put things in perspective. First, you're not wrong about pretty much everything you covered in practice for your particular case, but since we're making recommendations and designing an app that each need to be useful to as many folks as possible we have to throw away some good, common sense objections and focus on a theoretical attacker who is skilled and knows their stuff. An idiot or a robot would probably do exactly the sorts of things you used as examples, and that would greatly reduce the likelihood of success. But when we talk about and build this stuff, while there will doubtless be idiots and robots (and idiot robots) out there attacking peoples data, they aren't what we need to worry about. For the folks who face attacks from competent adversaries we need to set the bar accordingly, as we cannot know in advance which one any given user may face: the lady, the tiger, or the idiot robot.
I'm going to do something now that may seem, on its face, rather silly after just saying that we shouldn't focus on your particular case when designing 1Password and giving security advice; yet at the same time I can use you as a "real world" example of the threats we all face when using 1Password. I'll preface this by saying that I mean no offense, and I'm also willing to bet that you haven't given away your strategy on a public forum. Best not to confirm or deny, I just want to throw that out there so you know where I'm coming from: you clearly care and take your security seriously. So please don't take the rest of this as me saying — or believing — that you don't.
That said, I think we should assume that someone serious about getting at your data is targeting you specifically. There could be any number of reasons why, but the best reason is that targeting just anybody leaves the attacker at a huge disadvantage, when there is so much information that can be used to great advantage to attack an individual in a targeted fashion. Put a different way, I'm much more likely to successfully break into your house if I target you in particular and take the time to learn about you and use that to my advantage, as opposed to going door to door hoping someone left their door unlocked and has something I care about which is easy to abscond with.
And if we assume that you are being targeted for attack specifically, there's a reasonable case to be made that the attacker will know that you're using 1Password. So learning about not only 1Password but your habits/preferences will give the attacker a leg up. And coming across this thread where you discuss the relative pros and cons of different password strategies could be a goldmine. And from there it's a short trip to try to gather even more information from you by any means possible. Someone motivated to target you could certainly do worse than taking the burglar route, but instead of figuring out a way to get in and out with your computer, give themselves access to it remotely so they don't have to leave a(n obvious) trace — and can take their time getting what they need.
Now, that's pretty paranoiac, and you'd probably be just fine adding delimiters to word-based passwords, but ultimately the attacker we need to worry about isn't the sort who will be fooled/deterred/thwarted by these measures, but rather the one who's willing to do their homework while you don't suspect a thing. Suffice to say that I wouldn't be willing to bet my security on an attacker not knowing how I generated a password. Even if in most cases that's going to be true, if and when it isn't, I'll be in trouble. So I feel pretty strongly that using 64 characters composed of letters, numbers, and symbols chosen at random is the best option and my standard, and then I can "lower the bar" on a case-by-case basis for sites which disallow passwords of that length and/or composition.
I'm sorry that this probably seems like a bit of a cop-out and dodging your question(s), but going overboard means that we're in the best position possible in both best- and worst-case scenarios. Food for thought. :sunglasses:
0 -
going overboard means that we're in the best position
I agree, but then why offer a word-based password generator in the first place?
Making it convenient for users to choose word-based over random, combined with the increased ease of use of word-based passwords, aren't you inadvertently putting users at risk, especially without any sort of caution to the user to elects to generate a word-based password?
To continue the thought exercise of the attacker that does her homework and knows I both use one password and on occasion use word-based passwords: With only the very small number of degrees of freedom in the correct recipe (# words and a choise of 6 delimiters), it wouldn't be hard to write an effective cracker aimed specifically at 1Password users.
So I see your point and even agree with it. In my case I'm always trying to push 1Password on friends and family, so a would-be attacker that actually knows me has probably heard me rant and rave about 1Password and the use of word-based passwords enough to assume I use it. But your points seem to imply that 1Password users would be much better off without the word-based generator in the first place.
The following applies to both the random and word-based generators
If there could be an advanced mode that would allow users to customize the recipe further, a 1Password specific cracker would be unfeasible. This mode would allow the user to specify, for random passwords, which characters/digits/symbols are to be included/excluded (either by providing a character string, or maybe with a series of checkboxes if only symbol exclusion need be specified).
For word-based passwords, the advanced mode would at most mimic the options at https://xkpasswd.net/, and at least allow for changing delimiters, word case, and front/back padding.The App would suggest that users stick to random passwords as much as possible, but also provide a secure and hard to target word-based generator in advanced mode so that, if a user really wants a word-based password, they're getting a more secure one from the great minds at Agile Bits! The last thing you want is for users to go elsewhere for potentially unsafe password generation, such as actually using the web-based generator I linked. Likewise, it's undesirable for users to stick to the current word-based generator thinking it's more secure than it is.
0 -
To continue the thought exercise of the attacker that does her homework and knows I both use one password and on occasion use word-based passwords: With only the very small number of degrees of freedom in the correct recipe (# words and a choise of 6 delimiters), it wouldn't be hard to write an effective cracker aimed specifically at 1Password users.
Any evaluation of security assumes that the attacker has done his homework and knows how you designed your system. So when @brenty above calculated that a 4 word password is about as secure as a 12 char fully randomised password, he made that assumption as well. So even a 4 word password is very, very strong indeed and not something that an attacker can brute force effectively. And then just think how strong a 5 or 6 word password is.
0 -
I agree, but then why offer a word-based password generator in the first place?
@twilsonco: Word-based passwords are important in cases where a password must be entered manually, especially on a device without a keyboard (audio- or remote-control-entry on a "smart" device for example) or given over the phone — especially useful for "security questions/answers".
Making it convenient for users to choose word-based over random, combined with the increased ease of use of word-based passwords, aren't you inadvertently putting users at risk, especially without any sort of caution to the user to elects to generate a word-based password?
Just because word-based passwords are generally not as strong as character-based doesn't mean they are necessarily weak. Certainly one could generate very weak passwords with either method. I wish it weren't necessary to include that capability, but this is the only option in some cases. A fairly weak randomly-generated password will still be better than ones we make up ourselves. I think it's our job to give people the tools to use the strongest passwords they can, but we cannot stop people from using weaker passwords than is absolutely necessary. And I do believe that ore people are likely to use a stronger password as a result of us making it easy to generate them using 1Password, rather than going out of their way to use the weakest ones, since they don't have to remember them — or, in most cases, fill them — anyway.
So I see your point and even agree with it. In my case I'm always trying to push 1Password on friends and family, so a would-be attacker that actually knows me has probably heard me rant and rave about 1Password and the use of word-based passwords enough to assume I use it. But your points seem to imply that 1Password users would be much better off without the word-based generator in the first place.
I'm sorry if I gave that impression. That's certainly not the case, and I hope my comments above clarify that. To try to sum it up more succinctly, people are going to pretty much have to use word-based passwords in some circumstances anyway, so having the ability for 1Password to generate these will give them better results than they would get on their own.
If there could be an advanced mode that would allow users to customize the recipe further, a 1Password specific cracker would be unfeasible. This mode would allow the user to specify, for random passwords, which characters/digits/symbols are to be included/excluded (either by providing a character string, or maybe with a series of checkboxes if only symbol exclusion need be specified).
A 1Password-specific cracking tool is still infeasible provided the length is sufficient (4+ words or 20+ characters), at least in any useful time frame. But that's today. We do recommend pushing it even farther if possible so we're not all scrambling to change passwords if some new energy technology comes along that makes it feasible to brute force this stuff before we're no longer using these accounts. A "series of checkboxes" sounds like a bit of a mess, but "a character string" for either inclusion or exclusion is something we might do. The most important thing is that most people will not bother reading about this stuff or participating in discussions like this, so the easier we can make it to create a useable passwords without making it too easy for users to shoot themselves in the foot without knowing it, the better.
For word-based passwords, the advanced mode would at most mimic the options at https://xkpasswd.net/, and at least allow for changing delimiters, word case, and front/back padding.
I love XKCD and that website is a great tool. But is a bit of a mess, usability-wise. I think it's a stretch to expect more users to not see something like that without having their eyes cross, much less use it. As far as actual password generation, 1Password is a better solution most of the time. And I do feel that gets users much better results than something more complex like that site in 80% of cases (taking into account that most users will never seek out or use something like that site). But we'd very much like to push it to 90% or higher, hopefully without sacrificing usability, to better cover edge cases like sites which are more finicky about password composition. That's our goal.
The App would suggest that users stick to random passwords as much as possible, but also provide a secure and hard to target word-based generator in advanced mode so that, if a user really wants a word-based password, they're getting a more secure one from the great minds at Agile Bits! The last thing you want is for users to go elsewhere for potentially unsafe password generation, such as actually using the web-based generator I linked. Likewise, it's undesirable for users to stick to the current word-based generator thinking it's more secure than it is.
We're in complete agreement on this. There just isn't an easy or obvious solution. Once we're able to ship a revamped password generator across all platforms, I truly hope that it seems obvious in retrospect. We haven't yet been able to come up with a clean solution, but we're working on it.
0 -
@brenty I guess we've said about all there is to say :-)
At some point I'm defeating my own interests since I'm taking you away from valuable developing time.
I'll continue using 1Password for all my needs, only reaching out to alternatives when absolutely necessary.
Hopefully others find our discussion as useful as I did.
Take care.
0 -
@twilsonco: You too! Awesome discussion! I'm sorry that we're not able to implement changes to the password generator right now, but this is great food for thought once we're able to get to that. Have a great weekend! :chuffed:
0 -
Seems like a simpler solution for passwords that may need to entered may be:
- Choose the appropriate word length and generate a word based password using the defaults (i.e. lowercase, space)
- Add ".X6" or your favorite three chars that include symbol, uppercase char, numberIf you chose your word length appropriately, it shouldn't matter that you use the same 3 chars at the end of every such pw.
0 -
i.e.
"horse battery staple shoe.X6"0 -
That's an interesting solution, @steven1. You'll get dinged a little with measured password strength with 1Password if you do that (any password that's edited by a person is considered less strong than one randomly generated, even if adding to it).
There are arguments that could be made for why that's a bad idea, assuming it's always the same suffix and someone can figure out the suffix. It could help an attacker crack the other passwords.
My official recommendation in this case is to not use words based passwords. Don't get me wrong, I love word based passwords... but they excel in cases where you need to remember the password in your head. If you don't, then it's probably best to use character based passwords.
Rick
0 -
Hi Rick,
I don’t pay attention to the strength meter…it is easy enough to see that I get ~5.7bits of entropy for even just a alpha char password, or ~6.5 bits if it is alpha numeric with symbols. With your diceware list it is ~14bits per word. I can do the simple math.
I do like to use the diceware passwords for passwords I know I will need to type, not necessarily just ones I need to remember.
These are also generally lower value passwords. E,g news websites on my work computer. I can live with a 5 word password, ~70bits of entropy for this sort of stuff. This is a conscious tradeoff for not accessing my vault from devices I do not fully control. Of course, the typaiity of such pws is greatly superior.
For higher value sites that I need to type, I will increase the word count (assuming arbitrary password length limitations don’t kick in), or just use random chars and suck it up when typing.I have heard you guys mention not getting into security theater quite a bit…but “hiding” my system of “.X6” would be exactly that. If ex-ante I was happy with
horse battery staple shoeI should be equally happy withhorse battery staple shoe.X6. I have no problem you knowing that I use.X6to append to diceware passwords on sites that require symbol, uppercase, number.
:-)-Steven
0 -
P.S. just to clear...all passwords whether diceware or random chars, are generated by 1PW. Its just the
.X6appended to the randomly generated password to "pass" site specific requirements that is something I add.0 -
I have no problem you knowing that I use
.X6to append to diceware passwords on sites that require symbol, uppercase, number.Actually, I wonder if knowing part of the key could make an attack easier. I'm thinking of something like related-key attack. But I don't know enough to say if this applies in this case.
0 -
Actually, I wonder if knowing part of the key could make an attack easier.
Right, that's what I was getting to. I'd have to go poke Goldberg to point me to the proper literature, but I'm pretty sure that it weakens all passwords to have a known prefix or suffix to them (possibly even a known part within it). I mean, there'd be a good amount of assumptions that would have to be made in order to get to that point, but since we're in the business of hypotheticals I figured I should mention it.
Rick
0 -
Hi @pervel:
Like i said, I use this scheme for low value passwords I know I will need to type, even if only occasionally. Wo knows how these sites even handle the passwords. Do they store as plaintext or hash with salt? i would hazard a guess that the site's password storage means is a larger threat vector than you knowing my
.X6.This scheme allows me to easily type these passwords into devices/computers I don't fully control by just looking at it on my phone. I would rather you know my scheme for these sites than take the risk of entering my master password to access 1PW Account from an unknown computer.
My threat modeling for these sites lets me be at peace with my decision...after all, all my other passwords for sites that I access just from my own devices are random char to the max length allowed by the site/app.
0 -
Thanks for elaborating on how you use those, @steven1.
Rick
0 -
It would be great to hear @jpgoldberg opine on this...but my understanding is that the related key attack vector is pertinent when you think you have the security of a larger key, but part of that key is fixed / repeated.
In this case, let's say I am happy with the security offered by the key
horse battery staple shoe. Or any other 4 word diceware (1PW generated of course) password for that matter. In this case does it matter that the key is actually longer and includes.X6at the end?0 -
I've asked Jeff to comment here when he has time. I'm looking forward to hearing what he has to say.
Rick
0 -
That is a really interesting idea. @steven1. And related key attacks aren't (really) relevant.
My one concern is the while the people in this discussion understand that such a suffix isn't making the password stronger, that others won't.
It would be Bad Thing™ if people went with a three word password, but replaced one of the words with their
.X6. So we have the problem of how to present this if we were to offer anything like this in our generator or even recommended manually doing this. Again, everyone here understands what such an extra component does and does not do, but I am not sure how to offer/encourage this sort of scheme for most users.Keep it as a suffix
There might be a teeny tiny cryptographic advantage of using this as a prefix rather than a suffix, but considering the number of sites and services that actually truncate passwords, it is important to keep this as a suffix instead of as a prefix.
Related keys and related passwords
As passwords aren't directly cryptographic keys, related key attacks are not relevant here. (Unless someone is turning passwords into keys were truly awful key derivation functions that don't involve even a single hashing.)
But we should look at related passwords. We should assume that an attack will learn (though some breach of something or other) that you use
.X6as a suffix to all of your pass phrases. Assuming that we are considering the strength of the password to be what it is without the suffix, this knowledge offers very little advantage to the attacker.There may be some slight optimizations that an attacker can make depending on the suffix and the hashing scheme by knowing what part of the password is. An (extremely unlikely) example is if the passphrase without the suffix is exactly the block size of the hash algorithm and the hash algorithm is a Merkle-Damgård construction (MD5, SHA1, SHA2, but not SHA3). Now it is exceedingly unlikely that the password would be exactly that length and that the attacker would know that, but it does illustrate that point that there are some small optimizations an attacker could make. (This is the case were using a prefix rather than a suffix would help, but that is vastly overshadowed by the reasons to use a suffix instead of a prefix.)
That is one just off of the top of my head. I can kind of half guess at others, but again, I really doubt that such optimizations in cracking would be worth the effort. Highly optimized cracking systems already try related guesses near each other to reduce some memory setting operations. So this might save a few steps of for the attacking software and may keep some useful bytes in registers.
But I can't imagine this making a meaningful enough difference. Particularly if the rest of the password is securely generated. So my only worry is about non-experts misunderstanding what the suffix does, and thus using passwords that are much weaker than they think they are.
0
