> So? If not randomly assigned, the best you can do is enumerate all users in an unpredictable manner. It's not like sequential usernames allows you to easily g

> So? If not randomly assigned, the best you can do is enumerate all users in an unpredictable manner. It's not like sequential usernames allows you to easily guess the username for a specific person. ... or just use their account number that's on their website. Really, what's your point? Yes, you can potentially use some usernames as passwords. Doesn't mean it's somehow more sensible than using passwords as passwords. > It solves the DoS risk because it makes subsequent attacks sufficiently hard to perform afterwards. If your username can be leaked within seconds, the attacker probably has access to perform more devastating attacks than a simple DoS. What? Denying you service prevents denying you service because it makes denying you service any longer sufficiently hard, except it doesn't, because that's just another three requests? > You might not be able to change your username online, but support can probably change it. So, now you are just pulling stuff out of your ass? And in any case, how does any of this make any sense? Having bad passwords is a good idea, because we can use the username as a sort-of password? Sure you can, but why the heck not use the password as the password? > And the guy really does have resources for a botnet, then all bets are off. He could use amplification attacks to take down the bank's website by raw bandwidth alone. Erm, yeah? And why should he do that if a low-bandwidth attack does the job just fine? And in any case, how is the fact that there is one kind of DoS attack vector that you can not prevent a reason to also add another DoS attack vector, and to then use that to justify that you put in effort in order to weaken password security? Like ... what's your point? > Strange. I can log into my financial accounts while using VPN without a problem. You'd think that a VPN service that anyone can sign up for anonymously would invite more abuse than an ISP that you need to provide real credentials for. Which is a reason for building weakened security how exactly? > You seem to be misunderstanding Troy's position. He's not saying it's ideal, or even good practice. He's merely saying it's not as bad as you think. ie. having a 6 digit numeric password doesn't mean you're going to get you hacked within minutes. Yeah, having a root ssh account on your server with password "test" doesn't get you hacked within minutes. So, how is that an argument? There is real security, which doesn't get you hacked in decades, and then there is everything else that is pointlessly insecure, and in this case way less secure than he suggests in any case. > I have a feeling that businesses that need low latency transactions aren't doing so by scraping their bank's web page. They're probably using some sort of payment provider, or the bank has an API. ... and banks use the exact same idiocy on their APIs, correct. Why would they not if they are convinced that that is how you are secure, as they seem to be? > If anything, having a weak password gives you more plausible deniability than having a 256 bit entropy password. Well, sure. But then, not ever having any unauthorized transactions means you don't have to worry about plausible deniability? > That's the point of obligating it by law. It's consumer protection to give them the benefit of the doubt. Erm ... you do realize that that can not possibly be the case, right? That a bank can not possibly be obligated to give money to a customer simply because the customer demands it? > If you have an airtight case against the bank you wouldn't need it in the first place. I'd think you understand this concept, given that you're from the EU. You are completely missing the point. There are cases where the bank is at fault (like, they simply handed your money to someone else for no reason) and you can show it. That's the case where the bank's general liability would be all you need. Then, there are cases where the bank received an order to execute some payment that was authenticated with your credentials. Now, as subcategories of that you have the actual legitimate payment that you ordered, the somehow fraudulent order where you were defrauded and the bank can tell, somehow, and the somehow fraudulent order where the bank doesn't see any signs of fraud and you can't demonstrate it either. Banking regulation and/or voluntary guarantees usually (mostly) cover that second subcategory. But there is no way to possibly cover the third subcategory: That is the category or fraudulent transactions that are indistinguishable from legitimate transactions by anyone but you, and you obviously have a conflict of interest, so your word that some transaction was fraudulent obviously is worthless in determining whether it was. Anyone who wanted to defraud a bank could submit a legitimate transaction and then claim that is was fraud, so that alone can not possibly be sufficient to get your money back.