They also only enforce SMS as two-factor authentication.
The idea of this SwissID is to become a nation-wide identity service, yet they manage to do everything wrong. Yeah, this annoys me to no end :(
It’s the idea that knowing that an account exists somehow represents a compromise in the accounts security posture that I generally reject.
Perhaps you could measure the time of the login process and adjust the random delay based on how long the process has taken. If you can get this to average to a <1ms difference between the "email exists" and "email doesn't exist" you could probably defeat any timing attacks over the network.
That, or just limit retries and have different random timeouts for every login. Now you can't try enough times to get a good estimate of the mean for each login path, and you can't use other logins to help you refine your estimate because each has different timeouts.
I mostly don't bother anymore, because an effective timing attack for account discovery against something that's doing everything else correctly should take so many attempts that it should wake up whatever brute force protection sites should be running now anyway.
Given the number of dumb automated brute force probes against just about anything with a login, you can't just allow an infinite number of requests from a single IP (or a handful of IPs).
The random sleep is to prevent obtaining enough samples and provide reasonable noise at this small sample size. Given enough samples until the end of time, patterns can be obtained. This is not breaking TLS here, this is login, and seconds of sleep vs microseconds makes a difference.
Granted, this doesn't apply to eg banks, but there's plenty of websites where this could apply.
As to preventing timing attacks you can add a delay to give a uniform response time.
You have to be very careful with how you implement the delay to prevent the timing signal from still propagating to the attacker.
You find out that an email address belongs to a Swiss citizen?
The fact that the Swiss Post requires it as login method makes me uneasy.
Also, would a fix be a password manager that just ignores the forbidding or is it done with JS somehow?
(Most PW manager plugins I know already ignore pasting properties, though a bank I was customer of circumvented that; the textbox was actually a DIV and they had coded the functionality of a textbox into it to prevent pasting)
I answered all of them (and put my answers down in my pw manager) with something like "X bank has terrible security, I hate this bank" - hoping that one day I'll have to answer those by phone haha.
Rep: "Tell me the answer to this question."
Me: "Ok, let me see what I set it to..."
Me: "Oh... Oh no."
Lately, I've been making up a seemingly correct, but random response (and different each time). My favorite vegetable? Sea cucumber! I store that in my password manager.
I can confirm that this is the case. I provided a gibberish answer to a security question for Blizzard. I didn't bother to write it down, relying on not forgetting my password.
I never forgot my password, but Blizzard shut down my account anyway because I was making payments with a card that was not listed as the account's "primary payment method". (The card I was using was listed on the account, but another card was the "primary payment method".) When I had to call support and answer my security question, the answer I'd filled in just meant that I wasn't required to provide the correct answer.
This way "it's a bunch of gibberish" doesn't get past their security.
Never had to use these for real yet, but it should be a bit harder to be seen as a “a bunch of gibberish”.
Remember, an attacker can call support hundreds of times, getting a different rep every time. There's a good chance it'll work eventually.
Random but outwardly appearing valid ones are fine (but you'd want to avoid using the same answer on different sites). One site's "first car" could be Porsche 911, another's Aston Martin. Both aren't true, but the support rep doesn't know that.
Me: "Ok, let's see.....ah. So, it looks like a random string of gibberish, right?"
Rep: "Um, well...(unsure if he's allowed to say Yes or No)"
Me: "Yeah, I use a password manager for all my stuff, so all my passwords are randomly generated. I didn't think I'd ever have to read it over the phone. Sorry about that! I can read it out for you, but it might take awhile. If I read you the first three characters and the last three characters, is that sufficient to demonstrate for you that I know the Answer?
Rep: "Yes, I think that would be fine."
Me: "Alright, then! First three, 'F', 'caret', 'capital O'. Last three, 'capital G', 'lowercase l', 'dollar sign'.
As I said, I've never had anyone challenge me to read the full thing out. When I explain why it is that way and give them the bookends, they are usually convinced that I'm me.
Some of those reps may have been fine with you saying "oh no. I didn't think I'd ever need that and just mashed the keyboard".
Better to use something that's still made up, but is plausibly true.
What garbage string is there doesn't matter. Just as long as it is recognizably garbage and you know it.
In my most recent experience with them, the company allowed to be set both the question AND the answer. So, they had to read a random string to me, and I had to read one back. It went quite well, actually.
Not only are the questions picked from a list, but the answers are. http://www.slate.com/articles/technology/future_tense/2016/0...
Basically if you wanted to reset your employee password, which gave you access to corp vpn etc, you could call a 24/7 support line and give them your security answers.
The problem with this is that most of the questions were not things that are inherently secure, things like "what was the name of your primary school" are easy to guess or research.
They're also inherently unanswerable in many cases.
As an example, I went to two different primary schools. I don't have a favorite musician or sports team, and the answer to "where did you meet your wife" might be the school, the city, or "in class".
Last time I had to update my Apple security questions a good 80% of the questions weren't ones I felt I could answer in a way that'd be memorable a few years later.
Fortunately, I don't notice too many services requiring security questions these days. Unfortunately, most of them are banks or other services that probably also have my SSN.
* you leave the password in the clipboard, and another website copies it (used to be a thing, I think it's patched now)
* same case, but now a coworker comes to your unattended PC and retrieves the password by pasting it somewhere
* allowing pasting would undermine the idea that you should never write your password down, and lead to a proliferation of files called "passwords.txt" on everybody's desktops
None of this arguments is really good, but I can believe that they would be the result of a world without widespread password managers (also known as "the 90s") and tradition.
"Never write a password down" has always been a bad idea. A file named "passwd.txt" on my desktop still is better than using a trivial password or the same password on all sites. It still requires compromise of my machine and prevents the password from being recovered from a dump of the pw-hashes.
Modern browsers and OS kernels have extensive mitigations against this. Reliably extracting a password from a browser process's heap would be newsworthy today.
A sandbox escape that allows the attacker to trick the browser into sending arbitrary files back is also substantially different to having malware on your system that can read arbitrary memory.
MacOS has the option to purge decryption keys from memory on lock, but that effectively puts the computer to sleep on lock. It’s more secure, but annoying as hell since all network connections die (VPN, ssh, ...)
The fact that password managers use it at all is simply because it is the only hack that works to reliably get data into password boxes. Yes, its a hack. The HTML5 spec should have exposed a mechanism to securely insert data into an element tagged for such a purpose. A one way mechanism.
Well. The moment you have evil code running on your box, as you, then I'll naively assume you have a bigger problem to deal with anyway.
> The clipboard is a big public billboard visible to anything running on your computer.
And everything from client work to love letters in my home folder is available to anything that runs as me, unless I've gone out of our way to secure it - and succeed.
Not saying the clipboard isn't a problem.
Not saying browsers shouldn't expose a carefully thought out API.
But the way I read your post it might scare people away from password managers and back to a single password or passwords written on papers stored within reach from the workplace.
So is your keyboard buffer. If someone's already in your computer watching your clipboard they're probably also watching anything you type too
Eventually everyone should be using https://github.com/flatpak/xdg-desktop-portal/blob/master/da... (which is based on https://pipewire.org )
For now, e.g. https://github.com/fzwoch/obs-gnome-screencast uses org.gnome.Shell.Screencast
Even if it were not patched, how a site disabling "paste from clipboard" remove my password that I have already copied to clipboard.
Note that I would copy the password first and then I would realise that the site is not allowing me to paste it.
It's not a completely left-field position - it's definitely wrong in a modern context - however, previous years of security advice did focus on not writing passwords down.
I have also heard that they believe the removal of the option to paste removes the ability of attackers to exercise brute force attacks against their site. This betrays a lack of understanding of multiple technologies, though.
"They" often also disable pasting of other duplicated fields, like bank routing number, email address. So this shows why it is done (but misapplied to password). It's so you don't just copy and paste a wrong value that is hard for them to verify and leads to support calls. By forcing you to retype from scratch, the theory is you will either get it right twice or the error will be flagged.
That's copying it though. I know a decent password manager will clear the clipboard after an X amount of time too, mitigating the risk somewhat. But that's copying, not pasting in a field.
Why do people do it? The same reason people believe /dev/random provides security benefits.
It's important to ignore the correct things. (But it's often hard to figure out what to ignore.)
They really are just that clueless...
Regarding can you trust Troy, check this out https://news.ycombinator.com/item?id=17398821
Personaly I like mobile Id which makes logging into PostFinance or swisscom easy but not all phone providers are able to offer it.
Sucks that for post and sbb I need yet another system, Swiss id....
It also didn't notify me that it didn't allow such passwords, it just went right ahead and created an account it was impossible to log in to.
Thankfully, I was able to reset the password to one which is far unsafer.
Well done everyone.
How did I figure out what was going on? They would happily email your password in plain text. </facepalm>
I've stumbled upon login fields that just dismissed everything after the 16th character a few times.
We have security vendors who have sslv2 enabled and they can't understand why that's an issue.
We have huge fortune 250 companies that we exchange full credit card data with that have TLS 1.0 enabled with Symantec certs and only two weak ciphers. I sent them an ssl labs report and they accused me of breach of contract for hacking the site.
This list of security and finance related vendors that are double facepalm worthy is just astonishing.
The site isn't winning me any design awards and needs expanding of the advice articles, but dozens of local companies are immediately spurred to action when they appear in the "Sites requiring extra caution" section. Thousands of local users have directly benefited by the added security, even though they are completely unaware of why it was upgraded.
The reaction from some business has been very predictable, with a mix of hostility, threats, confusion, outright lies, but enough respond politely and want to fix things, and I go out of my way to help those who want to learn.
Source is public and if you want to try this locally, I highly recommend it: https://gitlab.com/tombrossman/insecure.org.je
I had someone well known in the local tech community call it "The most unprofessional thing I have ever seen" but later he was using it as a sales tool to persuade one of the companies listed to hire him to upgrade their site. I don't condone this but once the info is public I can't control what people do with it.
Though, imo, they should be sorted with the worst offenders on top.
"FedEx will renew the security certificate with Symantec for the following FedEx Web Services servers at 11 pm CDT on September 15, 2018. Please note that these certificates are valid for two years and will expire on October 4, 2020."
I could not agree more with this statement.
Public shaming of a person is never the right response, in my opinion -- live and let live.
Public shaming of a corporation, on the other hand, may be the only way to get the attention of the decision-makers.
Let's be kind and compassionate to individuals.
The thing is, publicly shaming someone is a very lazy way to effect change. Sure it might work for corporations, but if there's resistance it may be necessary to try reaching out to the decision makers via a different communication channel. I don't think it's appropriate to ratchet up the shaming and outrage.
Effective, too! Sounds like a win for me, a human being who isn't paid to ensure that other companies keep their systems secure.
That's why official corporation tweets often carry a signature with a person first name - it reminds me of Pennac's Malaussène, who by trade is a professional scapegoat.
Okay: "that is a dumb policy." "Big Corp's security wicket is hilariously wrong."
Not okay: "You are a moron." "This customer service rep should go find a fast food job."
In the examples he posted, Troy seems to be staying strictly on the side of shaming the companies. Yes, he's doing it by interacting with a customer service rep, but that's their job: to represent the company. He's not attacking the CS reps directly, and I couldn't quickly find any examples from his Twitter account to the contrary.
That may be a reasonable compromise for some, but I’ve seen some weird broken behaviour as a result of people using this FF toggle.
Perhaps it's not a good idea to code too much browser-specific behavior into this stuff on the other hand.
I think this is what Safari does at least, because the Google website tells me to hold and copy the links instead of just holding it like on my Android phone.
I can't tell you how many times my 1Password generated password was disallowed because of a special character that I ultimately had to delete by trial and error.
This means when I created my account with a 63-character password, which it let me do, and then I logged in for the first time, literally minutes later, with the same 63-character password, it told me it was invalid. Of course, at the time, it didn't tell you what the length limit was, and the login and signup forms didn't limit it either. If I didn't have the bright idea (and prior experience elsewhere) to try "maybe it's only the first n characters of the password", starting at 8, and finally succeeding on 20 (thanks to no rate limiting), I would have never figured it out.
I saw a comment once explaining why this might make sense to prevent replay attacks. But it seems awfully absurd.
To the extreme, a former employer suffered a major breach (after I was gone) and from what I heard a really great dev was distraught to the point I worried he might be suicidal.
All made worse because the organization as a whole didn’t learn, there were no obvious consequences for the management at fault, so he took it even more personally, when it truly wasn’t his fault a breach happened.
We need a way to give these people a voice before bad things happen, not just therapy after something they saw coming goes bad.
For those that would prefer other methods because public shaming doesn't fix everything: Let's look at some scenarios what (successful) shaming of publicly available services could do:
1. lead to audit and discovery of the issues in the internal services
2. bolster the argument of internal people who argue for security improvements
3. reset priorities to fix issues in public instances instead of fixing internal ones
An email box is specifically meant to be opened anytime from anywhere on the planet. It's insecure by design.
Not malice, just management that doesn't properly account for the negatives involved in poor security policy. Banks are no exception to the rule that all the managers are humans, and may not have the best information / mindset.
Fix the lowest hanging fruit as fast as possible, and raise the mean incrementally.
Maybe Troy Hunt can publicly shame them into more secure practises but I'm not hopeful.
I asked them for TOTP 2FA, but never got a response...
Why is it always banks who have some of the worst security posture out there? I fully expect my bank to eventually implement 2FA ... by SMS! Thinking that it's a good idea!
It's usually a PIN that is set by the bank rather than the user, to prevent people from using 123456 or their date of birth.
smaller scale: http://plaintextoffenders.com/
This is when I lost it. Bloody good read.
this leads to a situation where I have a 100 digit hashed password I have to type in by hand.
usually I just create a new account, preferably somewhere else.
Imagine my surprise when I went to login to the newly created account only to find out that the login screen enforced a character limit of 8 characters (both with a textfield attribute and js). This limitation was not enforced during registration!
I had to edit the page in developer tools so I could actually paste my full password to login. The limitation was purely client side.
at least they had implemented the first rule of it-security:
perform all checks client-side only ;)
Troy Hunt's post is really told from the victor's perspective (likely a bias rather than intentional or arrogance), but to form a well-rounded view, understanding how many false negatives would likely help...
I think it’s about time browsers start ignoring any onpaste events on password fields. I’m curious what Chromium folks think - have there been tickets about this? It would be a great way to end this dumb practice.
The real question is why isn't there a mandated list of global best-practice for web app security that can direct any acceptance test of any web site? Can't people like isaca and isc2 agree something and make it the gold-standard?
Never underestimate the power of inertia.
Sounds like justification for bad-security whistle blowing too. The downside of encouraging it is that you are easily deanonymized if you had attempted to bring it up internally before. We need a, possibly crowd funded, corporate bad-security whistle blowing foundation that contacts your own company on your behalf and then publicly shames them if they don't fix the issue.
Not sure if that's what banks are thinking about.
Obviously this is an extremely bad way to "protect" yourself (since you keep your password in plaintext on your PC), but it does protect against keylogging, right?
Another basic features is logging the active window/process to know where the user is currently writing to.
Not sure if it’s still the case (think they recently did a redesign and hopefully fixed it; I’ll check tonight). If it is, I would appreciate some more attention on this issue!
I'd love to "bank local", but when shit like that happens, the only way I'd feel safe with my finances is by going with the Bank of Americas/Fidelity's/etc. over Mom & Pop Credit Union.
It's even better when the internal person tips off the press to initiate the public shaming to take to management. Never happened in an organization that I worked in, but I know security people in other orgs that had to resort to these tactics.
At that point, you need pressure to create change. Shame definitely works, but it isn't professional, and it isn't nice at all. Many people may be open to help if you can get off of Twitter.
You can send a positive letter through a private channel that details the problem and offers help in fixing it. You can make an automated, impartial test that clearly proves the problem and provides links to fixes. Failing these, you can start a petition. You can have famous, well respected, and powerful people sign it. You can add carrots and sticks, like an award for security response, a hall of shame entry, or the nuclear option, a PR release and interview with national media about the dangers of the problem.
Even just sending a list of these problems as they have happened in the past and how they resolved to executives at the company is probably all the visibility needed to get the ball rolling.
Once a process is in place, it takes a well delivered argument to make a change. Not allowing paste into password fields is a prime example of something that seems like a good practice, but isn't. If anyone is reading this and needs to convince others to allow paste, NIST says to allow pasting passwords, and that it improves security:
> Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets. 
People will no doubt still say it's bad, but its a fact that the National Institute of Standards and Technology says to allow paste, and that it improves security
Of bad practices.
And as we've seen over the past 2+ decades - FD works. Once you draw attention to an insecure system, resources to fix it will be found. (Enough of the time, at least.)
I think companies need to mandate some kind of improved protocol for responding to these sort of tweet storms. It always seems to be people who are technically inclined talking to a social media representative with little to no knowledge of standard security practices, which leads to attempts to calm the masses, but ultimately backfires.
Is the shaming necessary? Do corporations only respond to an issue when it blows up? Seems like bad stewardship.
Let's say we have a giant backlog of work, each item ranked by voting by employees
Now the security team adds their "Stop sending passwords in plain text" item.
Which companies will it get voted up in?
It's so common we've become oblivious to how frightening this is.
We are talking passwords here, for god's sake, I want nothing be sent nowhere, let my browser and me alone.
It isn't sending a plaintext password, not even a full hash of the password. This is entirely fine..
... until it doesn't. Any update on did this HIBP 'feature' made it into Firefox?
One of the first scenarios that comes to mind - some implementation queries API for every key press. Suddenly you are sending your password out.
I guess time will tell, but human-generated passwords have proven their ineffectiveness anyway.
Should I read how Troy's API service works? No.
I'm now entirely comfortable with this product/service. Read how it works.
Yes. Until you do that, you are arguing in utter ignorance - and you’re wrong, to boot.
From FAQ ... flagging a story that's clearly on-topic by the site guidelines just because one personally dislikes it— eventually gets an account's flagging privileges taken away.
"k-anonymity" model which works like this: when searching HIBP for a password, the client SHA-1 hashes it then ... sends this to the API.
What exactly appears to be the problem?
The reasoning for this feature is clearly laid out, and the underlying "ethics of running a database breach search service", while controversial, are also something Troy has thought about very carefully:
My trusted browser should not send out any sensitive information.