The “Cobra Effect” that is disabling paste on password fields
troyhunt.com
troyhunt.com
Their support forum is full of angry customers, people who can't use their screen readers anymore, etc. They argue [1] it's to protect their customers from key loggers.
[1]: https://community.tradeking.com/forum/categories/suggestions...
Two factor is their best bet.
If they are too fucking stupid to implement a password text field correctly just imagine the byzantine nightmares that their infrastructure is. All you are doing is volunteering to be part of the next major security breach.
By itself, this doesn't rule out a man-in-the-middle attack, but it might prevent an attacker from setting up bonkofamerica.com and using it capture valid username/password pairs "offline", which could be reused on the real site. Of course, this depends on people noticing (and caring) that the image is missing or incorrect, so who knows...
Exactly so. That was a pretty frequent vector when those images became popular, so it wasn't a crazy defensive move. Even though there are ways for criminals to defeat it, proper mitm for one, those were more complicated measures that weren't as commonly used. Higher risks, development costs, trouble with scaling, or just unnecessary, for whatever reason, the static dumb credential harvesting pages that look "legit enough" were most common.
A company with limited defensive resources could approach security like a greedy algorithm. Just constantly ask, "How are most customers at institutions similar to my own getting compromised right now? How do I prevent that with as much blunt force as possible that I can deploy as soon as possible?"
That would probably get you some bizarre defensive solutions that reduce usability. But it's not an obviously crazy general strategy.
Well, major caveat: presuming you're at least doing the basics right. If you aren't bothering with hashes, then your men are already dead.
Could you explain how this works? I've never ran into this and I'm curious as to what it solves / they claim it solves.
They probably ask to enter e.g. 3rd, 6th and 8th letter of the password. Supposedly if someone logs it it supposedly won't be as useful, because next time it will ask for different letters.
Not sure why won't they use rsa keys or similar technology. Also if it is the way I think it is, then you know that your passwords aren't hashed on their servers.
Only if the developers are extremely lazy. A proper implementation would precompute a series of hashes for different subsets of the password and store them in the database instead. Similar to how Facebook stores both the password and its reversed-case form as a convenience feature for people who forget to turn their CAPS LOCK off.
I presume a good implementation hashes and salts each "sub-password" separately. Since it's the server that decides which subset it wants, I don't think it reduces the search space, unless the hashing/salting algorithm is vulnerable to differential cryptanalysis (which it may be, I don't know this aspect of state-of-the-art hashing functions).
Also in any bank that's even remotely sane this is just one leg of a 2FA; often a kind of a "delayed" 2FA - where one factor is enough to get you mostly "read-only" access, and any important changes or wiring actual money requires one-time SMS codes.
This is the immediate alarm that went off in my head reading about this. I've never seen this before either and it sounds like an idea from someone who means well but doesn't understand what they are doing.
I agree that they probably haven't hashed the password. Any time that I complain about this sort of thing the company agent usually doesn't know what I'm talking about.
[ ][X][X][ ][X][X][ ][X][ ][X][X][ ][ ][X][ ]
The idea is supposedly to protect people from keyloggers. But the side effect is that more sophisticated passwords get excruciatingly annoying to type in.
Edit: Just saw that others have already brought this up below. Sorry for the redundancy.
So my password manager enters my password, and then on the next screen I am asked for the (for example) 4th and 5th letters of the street I grew up on. The requested letters change and the question is pulled from a saved list of question/answer pairs.
I am not aware of how the bank deals with accessibility limitations of this system.
Instead of all the work banks put into chicanery around this secret question and answer security theater, they should just roll out real Two Factor and save us all some hassle.
Alternatively, you can work with your clients' ISPs. Most malware still exhibits visible communication patterns, either by getting in touch with other bots or by contacting command-and-control servers. Once you get ISPs to notice that sort of behaviour, they can sandbox their clients and have them clean up their systems before they reach the Internet (and disclose all of their data).
Related: https://paragonie.com/blog/2016/03/client-authenticity-is-no...
Like a Bloomberg terminal.
IIRC can't it communicate directly to the keyboard,screen and the network?
Besides DRM, this is probably the next best killer feature for the system if it's as secure as they claim.
Hoekstra and fellows at Intel have created a PoC secure browser plugin that utilizes an enclave.
Use of middleboxes that are hardened and have iSGX support can be used as a proxy as well to limit exposure.
Features such as PAVP via Intel Insider are not accessible in the current implementation (version 2) of Intel Software Guard Extensions. Access to PAVP and other powerful features of iME such as iAMT has been restricted to Intel and Intel Partners (M$, DoD) through obscurity and no available documentation. However, that being said, there are several white papers authored/co-authored by Intel employees who do make use of these immensely powerful features.
iSGX (nor any current technology that is known to the public) is capable of ensuring input CIA properties (without utilizing Intel Insider/PAVP to display a digital keyboard, transmitted via direct bus to NIC/eth.)
Other security technologies, specifically Sanctum does provide different coverage than iSGX but there is no "unified" security technology that is a one-size-fits-all solution.
iSGX's main PoF is poor security implementation by ISV's/enclave writer's. That being said it is better than TrustZone, TXT, XOM, Bastion, Aegis and Phantom in regards to the ratio of return:implementation cost.
edit: additional information
> I agree, it’s a little more inconvenient than before.... but for now we’re asking you to accept a little inconvenience for the sake of greatly enhanced security.
This gives people incentive to pick the shortest possible easiest to input password. Definitely not good for "greatly enhanced security".
[1] http://community.tradeking.com/members/bigdog/blogs/7546-a-w...
Shamelessly stolen from SE.
I got so fed up with TradeKing (which has horrible security practices in general) that I close my account.
Wow that's just insane. I'm glad I haven't run across any services like that. I'm not sure what their line of thought it; it only inconveniences normal users. A person attempting to try multiple passwords can likely figure out how to get around that restriction without issue.
It's theoretically a defense against key loggers. Of course, if someone has compromised your machine to the point where they're tracking key strokes there's no reason to assume they can't also grab your mouse presses and websites.
This isn't even their worst security practice. What truly got me to leave was their security questions: they're presented as multiple choices. My randomly generated string stands out rather obviously next to the "typical" choices.
Which is pointless anyway because at the point you access the keyboard buffer you can as well install a certificate and get a proxy going
If your account is interesting enough for criminals to break into your computer room and attach dongles to your PC (I'm imagining a Mission: Impossible style break here), congratulations: you've clearly made some good financial decisions in life :-)
(Curious as to whether it would actually work though.)
All this scheme does is limit an attacker to gathering three letters per login attempt. Given an eight-letter password, three logins will probably disclose most of it; or at least enough for an attacker to pass the challenge when he tries to log in.
In addition, if the attacker is actually interested in your data, he can easily inject a fake "wrong password" message after your first attempt and have you try again, gathering 6 characters per login.
First you enter a password, then you have to enter a pin using a on screen numpad with jumbled placements.
And likely the game will be doing all manner of things client side, thus it is cheaters all over the place.
Tell me why plaintext password storage is bad, and you'll defeat your own argument.
They also have the most complicated 2fa I've seen. You get a pocket-calculator-like device where you need to insert your card (chip and pin type), then you enter your personal code, and then you do a challenge-response thing where you enter a code generated from the website into the device, and it responds with a number you have to type into the website.
They also have this anti-paste function that was triggered by me typing too fast.
Such a thing is rather common in The Netherlands, though it's often not a second factor but just the way you log in to online banking. It avoids having you remember yet another password, instead you just use the same card and PIN you need "offline".
Side note: At the end of 2014 Rabobank (one of the banks with such a system) replaced those devices (which they called "random readers") with "Rabo scanners", which have a built-in camera to automatically read an image from the website instead of having you manually enter a code.
That's still 2FA though, isn't it? You're proving to the server that you have the card and the pin.
You insert card and enter PIN, then scan the QR code.
The device actually displays amount+account that you are transferring money to. Then asks you if that is correct.
If you enter "yes", it will give you a 8 digit code that you can enter in the website to confirm.
[0] https://www.rabobank.nl/images/how_does_the_rabo_scanner_wor...
[1] https://www.youtube.com/watch?v=f5FIxRsqFUA (work flow - in dutch, start at 20 sec, before that they show the old reader)
These devices are very common in Germany as well but I heard they are phased out and replaced with a solution using a mobile phone.
> have a built-in camera to automatically read an image from the website instead.
In Germany we have a variant that has five photo diodes along one edge. You hold it against a flickering pattern on your screen. This works reasonably well. In my experience it is about equally fast as typing, just a little less reliable.
You can also use it to login with Nationwide, but they also allow login with a password, which is far simpler (and you don't need to find your card to do so either)
You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
Store in DB id position hash user_id 1 0 x0 1 2 1 x1 1 3 2 x2 1
The question is not whether on a technical level something got hashed. The question is whether a hash protects the password against brute forcing. And the answer is no.
Why do hacker news people think they are better at security than multi billion dollar banks?
Many banks (I work for one of them) follow reasonable best practices, allow or require strong passwords, store them safely and require sensible second security factors. Others are decades behind in security, using nonsensical security schemes like the ones morgante and mng2 described above or requiring your password to be letters and numbers only between 6 to 8 characters.
If you care about security, stick with the banks who do as well. Make sure their password guidelines are in order, go with the ones that make you use a second factor, and if you ever see any hints they're storing your password in plain text, run.
Banks are good at not losing money.
But website security is an afterthought for them.
It's easy to make a website that has better security practices than a typical bank website.
It's not about having better skills or resources, it's about having the motivation to do it in the first place.
A bank could set up spectacular security, but that doesn't mean they usually do so.
Everybody knows that we are hopeless at it, and often the flaws that are exploited are just as simple as this.
To be fair, they're right in the middle of rolling out a new banking site which I think has proper passwords. The current system is a holdover from when they only had phone banking.
Re brute forcing, some like firstdirect make you type a word as well and they probably block you after 3 fails so it would be quite hard to brute force. Tddirectinvesting only ask a 7 digit account number and 3 digits from the password so you could probably brute force coms of those with a botnet though they only let you transfer money to a pre nominated bank account so it would still be hard to nick people's money.
Actually it's very simple to achieve.
First, those digits will not be randomly placed among all the things you've typed, but they'd follow some specific patterns (the most obvious one being you typing all of part --due to autocomplete-- of the bank's url).
(Of course if you can run a keylogger you can also check what website is loaded on the browser and log that information alongside the keys too, but you don't even need to go that far).
So, we established that the attacker checking the keylogger logs can trivially tell - "now they're typing their banking password".
If they also knew the correct placement that would be handy, but they can do without it too. Just knowing those N characters are from your password (in any order) really improves the possibilities they need to search.
Even if it takes a year, either they are very dedicated to you as a special (large bank account) profile target, so they can wait, or they are logging tens of thousands, via some malware, so it's still worth it to wait.
Such attacks rely on large scales rather than being targeted.
If you target a specific account there are much better attacks out there to do if you target specific individuals or organizations.
Yes this isn't the best method and I've had and still have a lot of objections to it (it requires the password to be stored in a reversible encryption, but that is also sadly a regulatory requirement).
But I've tested it a 10 character password using their random characters random order request method took at the least 413 (that was the lowest in my case, I didn't run a full statistical analysis on it) login requests. This is because that asking for 1st 2nd and 3rd characters, and 2nd 1st and 3rd, and 3rd, 2nd and 1st etc. are all considered "different" authentication requests by the bank.
Your keylogger would have to be also able to read the page and know that the 1st box wants the 4th character and the 2nd box wants the 3rd and the 3rd want's the 7th. This isn't that trivial, and this doesn't scale for an attack that can target 10,000's of users over a short time period.
You need to understand that banks constantly change their web pages, they monitor for bank related malware and some of them even use additional protection like for example randomizing the names of the input fields and even the number of the fields to make effective keylogging with full browser compromise even harder.
You also are incorrect when assuming that if i know the 1st 3 characters of a password it somehow helps me it doesn't because you do not have an authentication mechanism to brute force against there isn't some login page that takes the full password, and 3 incorrect login attempt lock your user and require you to initiate a recovery by phone or by visiting a branch.
This system overall is pretty good at preventing direct attacks against the bank's own system, it's resilient to phishing, brute forcing is not an option, and a keylogger can be active for 1-2 years without effectively getting the password. Effective security isn't black and white, there are is a lot of grey areas that might seem asinine and many of them are but they do work when you have the proper mitigating controls.
But let's ignore all of what we've established so far and go back to your assertion you assert that this attack is effective against high value accounts / individuals. Well that's great, because from the point of view of the bank it says hey look we've put in a control that can effectively protect 99% of our users, let's see what can we do to protect the 1%. That's how you achieve good security, you don't pool everyone into the same group, accounts with an average balance of 5000$ do not have the same risk portfolio as accounts with an average balance of 1M$. Differential security and risk management is how you apply effective security on very large groups, you employ shared controls that cover the basics and add mitigating controls based on the individual risk portfolios for each sub group.
The scrambled on-screen keyboard / n-th character request only poorly "protects" against cases where the attacker has full root access to the customer's machine (how would it protect against phishing?), and in those cases the attacker is likely already capable of making all kinds of payments, even without access to the online banking account. If security is done properly, an attacker can't make direct use of a banking account anyways: creating a new transfer recipient should require phone confirmation by default.
All you'd have to do is iterate every potential answer into a bloom filter and store that. The math gets a little hairy around the 50 character mark as you'd have 117600 operations to do to construct the bloom filter, and it gets worse if you expect more characters.
Here's how you would construct it.
For every 3 choose n of the password, insert a value of those 3 characters ("abc") + delimit (":") + the positions (1,2,4), You can't just insert the characters because the index of characters is part of the answer.
all you'd need to do is store... a ~1MB bloom filter per client. Huh, that number was bigger than I thought it would be.
Well nevermind. Fun thought though.
If an attacker is running code on your system, you are already lost.
[1] http://i.imgur.com/QCGPDWz.png [2] http://i.imgur.com/VdtGC4T.png
I really really dislike HSBCs online banking as a whole, the password system plus the constant “We encountered an error, please try again later” messages.
Still a lot easier to guess a portion of a password than a password, but it doesnt follow in my mind that it is definitely in plaintext.
However this is a memorable phrase (not password), similar to a security question. These are not generally hashed because customer service uses them to confirm authorization to reset a password.
The "password/memorable phrase" is only used as a secondary authentication measure and in order to initiate a token recovery procedure on the site.
P.S. I still use the physical OTP token, just got a new one last month it's a Vasco Digitpass 270 supports upto 8 digit pins and it locks out automatically after IIRC 5 attempts.
I don't recommend using a phone authenticator for the sole reason that losing a phone is annoying enough on it's own you don't want to lose your bank account access too :)
Edit: I realise you're probably referring to proprietary bank authenticator apps
see http://willtracz.co.uk/shamir-secret-sharing-and-passwords
Above is on the page you're linking to.
Still crappy entropy, though. An eight char password has 56 combinations of 3 positions each, so with N character choices that's 56 * N^3 vs. N^8 the normal way. Gets much worse in comparison with longer passwords.
Why does the "confirm password" field exist anyway? It exists to remove the risk of input error. They want to avoid you locking into a mistyped password and not being able to recover. To this end, it makes some sense to prevent copy/paste, as a user may simply copy their mistyped password and paste it into the confirmation field. Especially risky if the input fields are obfuscated with placeholder characters (*).
Not to argue that it's the right answer, it certainly makes more sense than a heavy-handed enforcement of character limits.
Also, while it sounds silly, disabling copy doesn't mean a user can't type the PW somewhere else and paste it in. I've totally done that before and suspect it's not super uncommon.
It seems silly to force everybody to doubly enter their password, when I'd guess at most ~10% of people might enter an incorrect password on their first try at which point those unfortunate ones are only a few minutes away from a password reset... where they would be sure to get the password right that second time.
My father, on the other hand, hunts and pecks and I can't get him to use a manager despite my best protestations. Having to retype his password certainly avoids mis-types on his part, even if it encourages other bad behaviors in the process.
Is it Dickens that you're currently reading?
Given that the contents of a password input can easily be revealed, the only security obscuring the input provides is from an attacker who can see the screen but not the keyboard, and has no physical access to the device - a pretty limited threat pool.
I guess the answer is that users expect passwords to be hidden. So we make their lives more difficult purely to keep them happy.
The procedure for the mobile version is to input your phone number and birthday on the login and you get a popup on the phone (via the gsm network and sim toolkit, not ip) to input your password along with a short phrase like "pink bridge" so you can verify that it was the web page that sent it. This also works with a lot of credit cards for paying online via 3dsecure.
It's become so common that a large majority of our customers (I work in a bank) are using this as the sole mechanism of identification.
(And yes, for the non mobile version of BankID you can paste the password!)
Isn’t that the same as the Social Security/National Insurance number you get in various countries? In France you have a unique number that depends on your sex, where you’re born, 3 more digits to differentiate you from all other people of the same sex that were born the same day at the same place and then a final digit for a checksum.
For more info: https://en.wikipedia.org/wiki/Personal_identity_number_(Swed...
However, there are a few reasons someone will get a new SSN number. Witness protection for example.
I know someone with misspellings of their name on one bureau's credit report and its never caused a problem (he's too lazy to ask them to fix it). The misspelling is listed as his name and the right spelling is listed as "other name" (or something like that).
SSN and ITIN: nnn-nn-nnnn EIN: nn-nnnnnnn
So it covers not only all the individual taxpayers but also all the employers and businesses that are taxable separately from individual income tax payers.
Someone was interviewed on the subject and said that if they built the system today, they would totally go for randomly generated number sequences rather than relying on a system based on birth date etc.
What if you have more than 10,000 people who have the same birthday? Let alone people with similar birthplaces/gender/etc. If that's all there is to it it seems like you'd run up against a combinatorical ceiling pretty soon.
Sweden has added two million people in the last half century. In net terms, essentially all of those two million have been immigrants rather than born in Sweden. They're de-populating when you exclude immigration, because their birth rate is so low.
10,000 people per day would be like Sweden adding 1/3 to its population in the next year. That's never going to happen. They're #166 when it comes to birth rate. Based on their population gain rate, they'll need to worry about the four digit limit in about 2,000 to 3,000 years give or take.
Also you have variability, there will be some days that are much more populated than others.
The last digit is just a checksum digit, so we're left with 3 digits per day. But that still would give some leeway for each day. The problem seems to be that some immigrants have been assigned a default birth date (Jan 1 and Jul 1) as their exact birth date is unknown.
Another issue which is not mentioned in the article is that we're only using two digits to encode the year (i.e. YYMMDD-XXXX), which causes problems now that many live to be 100+ years. Most banks and other places now requires you to enter a four digit year, even though that technically is incorrect. The correct way to annotate that someone is over a hundred years old is that the dash changes to a plus sign (i.e. YYMMDD+XXXX), although I've never seen that implemented anywhere.
[1] https://translate.google.com/translate?sl=sv&tl=en&js=y&prev...
In Sweden we use https://www.bankid.com/en/ which doesn't use SMS for authentication, it's mobile app based.
What about customers who are traveling overseas, or live in a different country?
Attackers convinced (either with their official badges or by conning) the targets' cell service providers to change the SIM info associated with the accounts, and thereby intercepted SMS authentication codes.
I hope this gets fixed.
Edit: This is regarding account creation/changes like the PayPal example. I have no idea why login forms would disallow pasting.
If you're security conscious, you shouldn't be typing passwords at all. You should generate them from a password manager and paste them into the field both times.
It boils down to security theater making us all less secure.
That way, password manager users can paste into both fields, but users who are hand-typing are forced to avoid mistakes.
A user typing the password elsewhere probably means they were able to see it while they type, and are therefore less likely to make a mistake.
Also, if you're someone who uses a password manager, does disabling pasting really make you less secure? I assume you're still generating passwords; you just have to retype them. So maybe less convenient, but less secure is kind of a stretch. (By the way, I personally use KeePass, and I generally use auto-type instead of pasting, so I'm not inconvenienced at all.)
Allow pasted passwords if they meet a very high password-quality heuristic; deny them if they seem too guessable.
People will almost never manually type out high security (>20 random characters) passwords themselves. So if someone enters a high entropy password, you can fairly confident that mistyping is not an issue.
1) Aren't there people using generators like Diceware that don't do the password management part?
2) The industry's definition of "high security" is constantly changing. Password strength measurement makes assumptions about what is and isn't guessable, and a lot of that depends on what techniques the common brute-force crackers are employing. So finding the right heuristic is also problematic.
I'm not sure they're actually that common. Moreover, if someone is sophisticated enough to use a password generator I assume they have some sort of system for ensuring integrity.
Also, if you're worried about someone changing their password to something they don't know, simply force a relogin and have effective password reset mechanisms.
> 2) The industry's definition of "high security" is constantly changing.
Industry might be getting more serious about encouraging higher security passwords, but standards for high security passwords haven't really changed much. People are just becoming less tolerant of low-security ones.
In terms of estimating security, you can use something like https://github.com/dropbox/zxcvbn which does a pretty good job of evaluating entropy and resistance to brute force attacks. Ultimately, a password with sufficient entropy will be resistant to any brute force cracker.
isolate the users so they cannot destroy your system when they get hacked, because they will always get hacked.
No, I recognize that most users probably don't use password managers. But I'm not convinced that disabling pasting helps much.
For one thing, I don't actually think it's that common for someone to copy a mistyped password. Browsers disable copying from password fields, so they would have to type it in a third place and copy it into the fields from there. Most users are not sophisticated enough to do that.
> Also, if you're someone who uses a password manager, does disabling pasting really make you less secure?
It directly encourages people to use less secure passwords. If I try to manually retype a 50 character password myself, I'm very likely to make an error. This isn't theoretical—I've often purposefully lowered the complexity of passwords for sites with these kind of arbitrary restrictions.
It's too bad 1Password doesn't have an auto-type feature.
So I do think that retyping passwords has value, but disabling pasting may have questionable value. (In my experience, disabling pasting on email confirmation fields does reduce the rate of error there, since lots of people copy-paste)
Edit, threw an example together. Ignore the horrible code ;P
Http://jsfiddle.net/6gc2d6hb
Type in one of the PW fields then double-click it. Doesn't overwrite populated PW fields.
No. But, consider that the segment of your users who don't use password managers is also very likely 100% intersecting with the segment of your users who do not ever attempt to paste a password into a password field.
So by blocking paste you have zero effect on the users you wish would improve their password practices, and a 100% negative effect on the set of users who are creating and using secure passwords.
I guarantee you are wrong about this. For example, a lot of people receive passwords via email, and then paste them in.
These days, I will refuse to log in to any website which doesn't support https.
A few years ago they dropped this requirement and you can now login using just an email and password.
The certificate-based identification process was really bad UI-wise so going with passwords probably helped them get more people to interact online instead of via paper forms.
Your suggestion of disabling copy instead of paste may be a better solution, though.
Except no browser ever allows you to output data (as a clipboard copy-operation is) from a password field.
This is not a real scenario.
I like the idea of two factor input; enter/select a password on a phone and send it over WiFi to the pc to paste into the field. Does this exist?
In addition, the whole point of making someone type their password twice when changing it is because you can't see what you are typing in a password field. You also can't copy what is in a password field, so there is no danger of someone copying the typoed password in the normal case. You are only stopping people from using something like a password manager.
I only was able to figure it out when I changed my gmail password to something stronger and couldn't log back in and had to google the problem.
In fact, now that I'm thinking of it, I can use it to trigger a script which will type whatever is in the clipboard. Silly javascript script kiddies think they can control a user's behavior like this.
I find it absolutely infuriating that this is necessary even when "purchasing" a free app.
The #1 reason I will not buy an app is because I do not want to deal with entering my Apple ID password yet another goddamn time.
If your phone shuts all the way down with any regularity, it's a nightmare.
https://github.com/jswanner/DontFuckWithPaste
(I usually keep it disabled, but enable it when I'm about to use a site that has paste disabled on any fields.)
(Temporarily disabling JavaScript is sometimes an option.)
Shouldn't chrome itself be a "don't fuck with paste" tool ?
As the world moves to the browser as the OS (essentially) it's imperative that the browser respect end user wishes and behave as a sentry against malicious websites and malicious website behavior.
When would I ever want a website to know the difference between me pasting and me typing some text?
Edit: Does anyone else feel... increasingly... trapped?
Sometimes password managers don't recognize the target form fields correctly, so copy/paste is the next step. The act is even encouraged through the use of convenient helper buttons in the password managers.
However. In MacOs Sierra, Apple will introduce the Universal Clipboard feature. This means when someone copies a password on desktop, it would be available on their phone. Which is just one step away from being pasted, by mistake, into an IM chat or worse.
I'm uncomfortable with the idea that when I copy something it's being sent around to different devices, and available to everything running.
I've actually made the terrible mistake of doing that - pasting a password into a group chat my accident, because I didn't copy text correctly, and my last paste buffer was still around. Or messing up when using pbcopy/pbpaste in a shell script.
1Password for instance can actually reset the copy/paste buffer after some time, but the settings need to be enabled. I wonder if Apple has any kind of security around this planned. Maybe applications and scripts should not be able to access the paste buffer until the user explicitly allows it (via the act of using it)?
If Apple has any sense at all they will allow apps to mark content being put in the clipboard as local-only. Otherwise this feature will leak all kinds of information intended to be private (passwords, stuff copied from incognito browser windows, financial information from tax software, etc).
If they aren't, there's a lot of "debt" in the passwords space, like Troy mentions. This is just something that will get better as websites get better. Webapps are much more complicated today than 5 years ago, on average, and as complexity increases things like user auth will get better and more homogeneous. This is especially true if Google and Apple have their way with the Credential Management RFC and get people to have a reason to save their passwords with chrome.
"Passwords" are getting better but we need another 5 years to get us there.
It is only stupidity if you assume the only purpose of a password (or a physical key) is security, and not also authorized entry. It may still be a poor engineering solution to the requirement (because engineers were told the solution, to asked to meet the requirement). But it is wrong to assume there is no reason for the requirement.
You can't paste your legally binding electronic signature either, I'll warrant. I've had to type out my name plenty of times, in digital contracts, even though my browser is quite capable of auto-filling.
That might be plausible if anyone actually thought that.
E-contracts require typing out a signature, not a random phrase.
The article advocates breaking the bank's protocol for your own convenience because you supposedly know more than the other party. In general, in life, this is bad advice.
Please do not ask people to do things against the will of the other contracting party for their own convenience, without considering the risks of doing so.
This may be hard for you to grasp.
What's the difference really? I'm either way blocked from accessing my account. I don't give a damn what that some idiot nontechnical lawyer put into the ToS. I find these kind of services annoying anyways and the first sign is usually forcing me to pick a less secure password.
It doesn't trigger not copy events (so the website can't mess with the text), nor paste events. Just the way it should be.
Honestly there's no reason to do this bullshit of disallowing pasting client-side. If pasting is a problem, if your machine is compromised, it's got a key-logger too.
Those on-screen keyboards to try and foil that vector basically presumes everyone's infected, and so, encourages weak passwords that are more likely to be brute-forced by an adversary not using that interface.
Not that I necessarily agree with that notion (just make it easy for me to change it again) but that's the idea. I thought.
Sometime in the 1960s we realized that we can't reduce fatal car accidents by "holding people accountable for their own mistakes". We actually have to make cars safer.
For the whole of human civilization, generation n-2 can complain that generation n is turning the world into a padded room. E.g., if you have a car, you expect it to just start at the press of a button or the turn of a key. But starting the Model T required physical strength and an intimate knowledge of the engine:
https://www.youtube.com/watch?v=OfQWnaWLDeQ
People who grew up on the Model T surely bitched about how later cars were making whippersnappers soft, what with their electrical starters and things just working reliably. But nobody today would say, "back to Model Ts so we can toughen up and really learn how internal combustion engines work". We have better things to do. Very smart car designers have made it so that we mostly can just get in and go. Soon, we'll just get in and the car will do the going.
That's what technology is for: We solve problems so other people can do what really matters to them. There is no sense in stopping now and saying, "Fuck it, 5000 years of technological progress is good enough."
Especially ever since Apple disabled pasting for decrypting external drives.
note: sorry, accidentally deleted earlier version of this comment.
http://superuser.com/questions/858082/how-can-i-selectively-...
javascript:void(document.onmousedown=null);void(document.onclick=null);void(document.oncontextmenu=null);void(document.onpaste=null)
Of course, in an era where weak password re-use and leaked hashes are one of the biggest problems facing normal internet users, we really should re-evaluate all the above assumptions.
Or if it's too hard, let email providers handle the login security requirements... Since most places allow email-based password resets anyway.
> we really should re-evaluate all the above assumptions
I would not consider anyone supporting these practices remotely competent. There should not be any need to re-evaluate anything.
Starting with the premise that users should be remembering passwords at all is a mistake.
That said, we should never have let websites have this kind of control over the user agent. For the one time disabling right click was helpful (context menus in Google Docs), 99% of the time it's something dumb ("don't steal our images!").
Finally, I loved the comment about losing their security certificate. I'm sure the average CA will give you a cert for google.com if you ask nicely enough.
> But there’s one angle to this that helps explain the madness and it goes back to that earlier PayPal screen grab. This was of the change password page, not the login page. You can easily paste into the login page and in fact you can even paste into the original password field on the change password page, just not the new password field or the other field that confirms it.
> The reason lies in the earlier message I showed from PayPal, in particular this part of the password criteria:
> Use[] 8-20 characters
> Ah, so because you’ve gone and put an arbitrary limit on the length of my password and taken away my ability to create a nice a 50 character random string, you’ve had to kill the paste function because otherwise I’d go around thinking I’ve got a 50 char password but it was actually truncated to 20 due to the maxlength attribute of the password field. Nice one guys, good work there
Having spoken to no one about this, I'm still confident that Troy Hunt is full of crap. The reason to disallow copy-and-pasting into the new password field(s) is obviously the same as the reason you have a confirmation field in the first place: you want to make sure the user hasn't entered the password wrong, inadvertently locking themselves out of their own account. Allowing them to enter their password once and then paste it, typos and all, into the "confirm password" field completely defeats the purpose of having the confirm password field at all.
All joking aside, that's why you have password reset functionality. The reason I can't paste in most cases makes me choose another site. One that takes my security seriously. I'm the kind of user that wants to paste in a 40 character long password and store it in a manager that will allow me to forget all my passwords except one or two.
https://news.ycombinator.com/item?id=7832938
There were 33 comments on that submission, so that discussion might be relevant. I wonder if this discussion repeats any of the points made there ...
A .txt file on the desktop is actually probably a lot more secure than using the same shitty password on every site.
I submit, I give up, you win. There's a file called "plaintext-passwords.txt" in my home directory. I keep the account information for these services in there. I've thought of keeping it encrypted, but if they don't want my account to be secure, why should I?
Anyway, if I had to type these passwords in rather than paste them, that would not stop me. All it might do is incentivize me to make them shorter.
You won't ever believe how often this work while gibberish keychain-generated passwords get rejected because they contain a "-" character ...
Wake up IT departments it can't always be users fault. People born with Window95 starts to work, they won't take your shady security reasons for granted as did people born in the 60's! They just will just think that your are incompetent...
And in Bulgaria I saw use of client-side certificates.
But for login, I see no reason to prevent it.
But it seems like an actual captcha would be better, then.
Link for the interested: https://www.grc.com/sqrl/sqrl.htm
I store my credit card data in 1Password - so I dont have to pull out my card each/every time I want to buy something online.
Not been able to paste my credit card number into the field is a PITA.
I often wonder how much the security of email (and by extension, every other account online) depends on people just not knowing how simple and easy it is to break into. If everyone knew, we'd be living in chaos right now, right?
In return I assert a well deserved facepalm when I see a friend log in on his e-mail account with a variation of "Password1".
Just use a strong password ( https://xkcd.com/936/ )
The funny thing with having email as a username is, how sometimes people can use social engineering to gain control of your account, non of that fancy "hoaxer" stuff are needed when your service providers put untrained people in charge of your accounts. Hacking human stupidity is a more effective way in to get in to a secure system.
( as an example, this was on reddit just yesterday https://www.youtube.com/watch?v=lc7scxvKQOo )
Also worth mentioning my e-mails are not hosted on gmail or any big cloud player. I actually pay for my imap, when you don't pay you probably in some way are the product...
Paranoid? Maybe
Safe? More than others
email recipient: Pasword123
me: thanks.
JOB DONE :-)
"Hey, how are you?"
"Pretty good. We're thinking about getting a dog so I went to the shelter this morning."
"Oh really?"
"It's tough to find one that's a good match though."
"Definitely"
"You ever have a dog?"
"Nah, wife's allergic. Had a snake as a kid though...called him Mr. Slithers."
Here's how I deal with sites that require them:
site: "What is your first teacher's name?"
me: "'Fx|<n8K@W8#[_,[ (1p)jqPC"
The answer is a password equivalent, so I just treat it like a password.
Or is this for when the account is locked for some random reason?
Some of them are lightweight virtualizations where a priviledged outside user can run processes inside the VM without requiring authorization or without being logged.
How is this a meme that needs to die?
Not if they self provide their own email (by running their own mailserver).
Emails from residential modems are not even worth scanning - they are practically guaranteed to be from botnets. Emails from commodity hosting providers are also pretty suspect, because they're very easy for spammers to get their hands on.
If you want your mail delivered, you need to send it from IP addresses that don't have those obvious red flags, don't have a reputation for sending spam any time in the distant past, and also have a long-term positive reputation for sending non-spam email.
In practical terms, you need to be in the professional mail server administration business full-time (be extremely careful to shut down abusive customers/tenants rapidly, never make a mistake that would let an attacker run an SMTP server on your network, etc.) or you need to pay someone who is, and who trusts you to cloak yourself in their reputation and not ruin it.
They didn't advise me to change my security question, no doubt because the name of my favorite childhood pet isn't likely to change.
I also think 2fa is ridiculous for 99% of applications. The widespread adoption we've seen is largely the result of developers trying to solve for user error, which as I stated in a previous comment is a waste of time and can never succeed (unless your goal is to find the flaws in your system).
The worst part is that some companies (TradeKing) turn these into multiple choice questions, where a password-like answer will stand out like a sore thumb.
Do security consultants just completely lack common sense?
That's why you should use Lastpass.
I hope they can improve that one day.
I have no idea where they thought any of that UX would be even remotely a good idea. Everything about it is misguided to such an extreme I'm left wondering if there's a single human on their development team.
1password may not be perfect, but their attention to usability is obvious!
http://www.tomsguide.com/us/lastpass-phishing-attacks,news-2...
Not all users realize this, and so .. don't 'clear' the clipboard after logging in .. which means their password is still available to anyone else who might use that computer.
On the other hand, maybe development of software is a mindless endevour, and so the labor in this area must be cheap, right?! </sarcasm>
It requires getting promoted to management or board level to get the ultimate decision power. Some companies are more progressive when their board chooses to be but they can always revert back if they choose or get taken over.