111–120 of 128 posts
Earlier quoted context omitted.
CHAR(8)
Worse yet, it seems to imply that they aren't hashing, which is simply preposterous for a financial institution.
Wow what a dumb question obviously the OP has very little experience in dealing with real people, probably one of those code monkeys disconnected from the real world. Tune out of World of Warcraft, turn off your Xbox and think for a second: If people could choose long passwords with special characters how could our customer support reps read them back to the users in case they loose it? How could they check them on t…
I'm not up on this topic, but I've always wondered why password length is so important if dictionary and other automated attacks aren't allowed. I hope you don't tell me that banks allow millions of password attempts in a short period of time, certainly not from the same ip address and even from what might be a bot net.
Which gets us to the strange part. Who hacks a bank's service to steal a password DB in hopes of using the passwords against some other target? I'm thinking nobody. If you managed to compromise a bank's web service to that extent, you'd be trying to transfer all of the money from all of the user's accounts to one you control, not trying to crack their passwords.
That means that your bank's password storage method and complexity is not very important. What is important is that, whatever password you use, you never use that password on any other site. And that you use a bank that requires real 2-factor authentication, via text or mobile app or something like that, not with "security questions".
I'm not up on this topic, but I've always wondered why password length is so important if dictionary and other automated attacks aren't allowed. I hope you don't tell me that banks allow millions of password attempts in a short period of time, certainly not from the same ip address and even from what might be a bot net.
The usual concern is the database storing the passwords/hashes being stolen. This has happened to dozens of small to medium size web services. The attacker could then hash away at the passwords to his heart's content. Then end-goal of this is to get user/pass combos to be tried on other, higher-value sites, like email services and, uh, banks. Which gets us to the strange part. Who hacks a bank's service to steal a pa…
If an attacker got hold of a large number of bank account user logins, I'm not sure what they'd do. My bank doesn't provide a feature to quickly transfer cash from the website... Several hundred large billpay changes would show up and be easy to cancel... Perhaps they'd just gather personal info useful to a social engineering attack...
Earlier quoted context omitted.
Typically bank tech support have no idea about the inner workings of their website. My bank uses 2 stage auth to login which works really well. However, they have a sort of shortcut service where you can activate and pick a password and then use that password to do quick stuff online or in their mobile app. The quick stuff still let's you transfer away all your money to someone else so it's basically a gaping hole. T…
I imagine there's the possibility of a huge PR scandal, especially if a blog post is written eloquently and carried by the right news sources. Unless the bank doesn't care about their image, of course.
I've spent the whole day thinking about this and now I've been looking up ways to write a PoC. Because I don't think a blog post without a proper PoC will do much good.
So first of all assembling a wordlist was easy using Python. The hard part will without a doubt be interacting with one of the entry points to their service.
It's a flash application, with a login form.
I've discovered Selenium for this purpose, and theoretically Selenium can act as a browser, clicking input fields in the flash form relative to where the element is created on the page. And then I can take a picture of the current page after each operation and compare it to how the page should look at login, or at failed login.
Jesus did you just ruin my weekend. ;) (in a good way)
Edit: Found sikuli and was amazed by how simple it is. Jython script that let's you essentially use images from your screen as conditional expressions in Jython. So you can do
if exists(screenshot of bank login form.jpg):
click(screenshot of first input field.jpg)
type('bla')
Wow what a dumb question obviously the OP has very little experience in dealing with real people, probably one of those code monkeys disconnected from the real world. Tune out of World of Warcraft, turn off your Xbox and think for a second: If people could choose long passwords with special characters how could our customer support reps read them back to the users in case they loose it? How could they check them on t…
if you don't keep the password lists in plain text you wont have this problem...
I'm not up on this topic, but I've always wondered why password length is so important if dictionary and other automated attacks aren't allowed. I hope you don't tell me that banks allow millions of password attempts in a short period of time, certainly not from the same ip address and even from what might be a bot net.
The usual concern is the database storing the passwords/hashes being stolen. This has happened to dozens of small to medium size web services. The attacker could then hash away at the passwords to his heart's content. Then end-goal of this is to get user/pass combos to be tried on other, higher-value sites, like email services and, uh, banks. Which gets us to the strange part. Who hacks a bank's service to steal a pa…
Earlier quoted context omitted.
If you don't use SSL and the attacker can sniff the stream, chances are he can inject JavaScript to send him the password. SSL is just indispensable nowadays for authentication.
And if you have SSL anyway, why use passwords when you can use certificates?
Earlier quoted context omitted.
May I ask what bank you bank with?
This was HSBC in Canada. I am not a security expert, and realize that this may not be the right thing, and the implementation might be horrible, but if there is a reason to limit password to 8, this was a good enough reason to do so :)
Earlier quoted context omitted.
I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing tha…
Now you have quite a restricted domain, so if your database is compromised there are a lot fewer values an attacker needs to enumerate to try and crack the password.
I would expect the image of MD5 on its codomain is almost a bijection (would love to be demonstrated wrong here, if anyone knows of a paper that studies this, but it seems reasonable that any good hash would have this property).
This doesn't really protect against a dictionary attack, but to guarantee a collision, an attacker would still need to try approximately 2^128 passwords for each password in the database, which is already the worst case for the attacker, so no strength is really lost.