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)
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).
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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]
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.
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.
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 :)
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?
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.
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"
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.)
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.
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.
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.
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.
> 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.
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)
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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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'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.
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 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?
>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.
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.
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.
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.
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.
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?
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.
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.
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
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.
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?
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.
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.
>> 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.
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.
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.