12 ms·

Sorry, but that article is just dumb. For one, obviously, the possible existence of other security mechanisms is exactly no reason for intentionally breaking pa

Sorry, but that article is just dumb. For one, obviously, the possible existence of other security mechanisms is exactly no reason for intentionally breaking password security. Either you store passwords as plain text, in which case you have just failed, or you are storing a hash, in which case there is no cost to doing the right thing and accepting arbitrarily long passwords. There is no way to start with "we have other security mechanisms in place" and end with "therefore, we should weaken password security". And if an organisation is incapable of understanding that trivial piece of logic, I have very little hope for their supposed magic security solution. But even worse: The idea that locking users out after so many failed attempts is a security mechanism. When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. If you have proper passwords, locking users out is completely useless for security, but it's still a DoS vulnerability. A brute force attack will not crack a 128 bit random password, no matter the rate at which it is tried. And while non-public user IDs can help mitigate that risk, it is not at all a given that banks don't use essentially public account numbers as user names, even ones that have 6-digit password limits. Plus, the user ID at that point effectively becomes part of the password, just that it's a password that you can't change, which isn't exactly brilliant either. And finally: It's quite a failure at assessing attack scenarios if you think that user lockout actually solves a problem. Your typical bank has a failure counter per account. A failure counter that is reset on every successful login. So, the real number of attempts an attacker could make is the number of attempts you have before lockout minus one, multiplied by the number of successful logins by the customer. An attacker might not necessarily be able to know very well when the user has logged into their bank account, which sure will limit the exploitability somewhat, but then, that very much depends on the circumstances. If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, or ~ 70000 per year, without causing lockout. If you instead want to target the general public, you might also just use a bot net to attempt login into accounts only occasionally, risking some lockout, but statistically compromising a certain number of accounts over time. And all of that when proper passwords do solve all of those problems perfectly reliably. Oh, yes, and the idea that some banks will give you your money back? Seriously? Now, if that isn't a failure at assessing risks, I don't know what is. Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did. If the attacker is good enough at making it seem like the customer authorized the fraudulent transaction, obviously, the customer won't get back a cent. Those claims by banks are marketing bordering on fraud, and obviously not something anyone claiming to be an expert in security should just trust to be something you can rely on.

gruez 7y ago
>When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. But what's your threat model here? Some attacker who's targeting you that somehow got your randomly assigned username but not your password? Or someone hitting every account number for "the lulz"? In the first case, it can be resolved with a 10 minute call to the bank to get your username changed (although you have bigger issues if your attacker was able to get sensitive information such as your banking username). In the second case, the attacker will get ip banned/rate limited very quickly. >If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, Sounds like a very non typical use case. Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious. >Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did. AFAIK they're obligated by law.
- deleted 7y ago
  [deleted]
- zAy0LfpBZLC8mAC 7y ago
  > But what's your threat model here? What do I know? DoS attacks are a thing, so that's the threat model?! > Some attacker who's targeting you that somehow got your randomly assigned username but not your password? You are assuming the username is randomly assigned. > In the first case, it can be resolved with a 10 minute call to the bank to get your username changed Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds? If your suggestion is that using the username as the password somehow is supposed to protect you, I have bad news for you: You usually can't change your username, so you can not change that "password" to something the attacker doesn't know. > (although you have bigger issues if your attacker was able to get sensitive information such as your banking username) You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password. > In the second case, the attacker will get ip banned/rate limited very quickly. You have heard of this thing called a bot net, right? Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account. You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought? > Sounds like a very non typical use case. The idea that banks should only be secure for "typical use cases" primarily sounds like a very bad design principle. > Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison. > Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious. Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you. And also, regardless, the problem still remains: There definitely is no permanent login fail counter. Customers occasionally do mistype their passwords, and that does not lead to lockout. But whatever the real maximum rate of failed attempts is: The total number of possible attempts is more than the advertised supposed maximum number of attempts. > AFAIK they're obligated by law. They are obligated to do what? Give you back your money because you say so? Certainly not. Be able to determine with 100% accuracy whether a transaction was fraudulent? Yeah, sure?!

gruez 7y ago

>When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. But what's your threat model here? Some attacker who's targeting you that somehow got your randomly assigned username but not your password? Or someone hitting every account number for "the lulz"? In the first case, it can be resolved with a 10 minute call to the bank to get your username changed (although you have bigger issues if your attacker was able to get sensitive information such as your banking username). In the second case, the attacker will get ip banned/rate limited very quickly. >If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, Sounds like a very non typical use case. Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious. >Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did. AFAIK they're obligated by law.

deleted 7y ago
[deleted]
zAy0LfpBZLC8mAC 7y ago
> But what's your threat model here? What do I know? DoS attacks are a thing, so that's the threat model?! > Some attacker who's targeting you that somehow got your randomly assigned username but not your password? You are assuming the username is randomly assigned. > In the first case, it can be resolved with a 10 minute call to the bank to get your username changed Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds? If your suggestion is that using the username as the password somehow is supposed to protect you, I have bad news for you: You usually can't change your username, so you can not change that "password" to something the attacker doesn't know. > (although you have bigger issues if your attacker was able to get sensitive information such as your banking username) You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password. > In the second case, the attacker will get ip banned/rate limited very quickly. You have heard of this thing called a bot net, right? Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account. You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought? > Sounds like a very non typical use case. The idea that banks should only be secure for "typical use cases" primarily sounds like a very bad design principle. > Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison. > Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious. Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you. And also, regardless, the problem still remains: There definitely is no permanent login fail counter. Customers occasionally do mistype their passwords, and that does not lead to lockout. But whatever the real maximum rate of failed attempts is: The total number of possible attempts is more than the advertised supposed maximum number of attempts. > AFAIK they're obligated by law. They are obligated to do what? Give you back your money because you say so? Certainly not. Be able to determine with 100% accuracy whether a transaction was fraudulent? Yeah, sure?!