Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re: There we go again (Score 1) 383

If they do, there are botnets that help you try lots in a short period of time.

After the first 5 failed logins you don't allow ANY logins for the cooldown period so having a botnet does't really help you. Also, it would be trivially to detect that someone is hopping from IP to IP to try to login to the same account as this would not be something a normal user would ever do. At that point you simply lock the account entirely, ban any of the IPs that continue to try to login to the account and then work from there.

Most attacks involve dumping the password hash database.

Which is a different scenario than what I was referring to. In that case you better hope you detected the attack or else you are basically fucked.

And even brute forcing is getting easier. If you need a SPECIFIC password, it's not any easier, but if you have a bunch of hashes and you want a good chunk of accounts (without caring if you have every account), it's actually easy. In fact, Ars Technica covers a domain-specific brute forcer [arstechnica.com].that relies on terminology from the sites cracked to get a list of potential passwords EXTREMELY quickly. Follow this with trivial modifications to get more. If you have a list of a million passwords, you could easily derive half of them this way, and then move on to the next list.

Brute forcing is getting easier. That is why you simply make your site an unattractive one to attack by making it so they can only do a very small amount of attempts before hitting a cooldown and then an eventual total account lock. Sure, this can be an annoyance to a user, but it's much better than their account being breached. But again, if the attacker already has a password hash list from already cracking your system, they have a much easier go at you especially if they can find out you didn't salt the hashes (or you used a weak PRNG for the salting, etc.) or do any other proper procedures.

Comment Re: There we go again (Score 1) 383

This of course assumes the administrators are paying close enough attention to notice in short order when the database has been compromised, and that all users define a secondary means of contact through which to send a reset password. It also ignores the issue that most users use the same username and password across multiple sites, such that a pair compromised on one site and invalidated as described would still be valid on another site.

A very valid concern and as I address in another post it is not a perfect solution. There is no way to prevent users from reusing passwords across sites nor will there ever be foolproof way to spot every intrusion. But then again, no security procedure is perfect and anyone stating otherwise is selling you snake oil.

And as I've had to state over and over again (and this isn't meant against you wagnerrp), my statement about rate limiting, etc. was in the context of a post that did not mention an attacker already having compromised the system and having a DB dump with all the password hashes. That is a completely distinct scenario than the one I referred to and obviously would require other mitigations.

Comment Re: There we go again (Score 0) 383

By your previous posts it seemed you needed things put in simple terms, especially since you claimed that 1) knowing the hash is the same as knowing the password (it's not) and 2) rate limiting could defeat offline password cracking (it can't). Do you stand by those claims?

Nope, because I never claimed that. You misunderstood my point and started falsely assuming things.

That's no solution: 1) Relies on the attack being detected in the first place.

Of course it is predicated on knowing you've been attacked. I was pretty sure that would be quite obvious. Of course, if you've been attacked and have no knowledge of it that these security measures won't prevent an attacker from being able to attack you again after offline brute forcing a password.

It's also completely irrelevant to the question of being able to dictionary attack a password.

And I never said it had anything to do with that scenario. You've basically have been twisting my words into something I never stated or implied and then have applied them to scenarios outside of what I originally responded to. At this point I'm simply just going to ignore you.

Comment Re: There we go again (Score 0) 383

Yes, they aren't. But all these scenarios are orthogonal to what I was responding to originally which is someone talking about using a dictionary attack to brute force password.

As I originally responded to AC-x, if the attacker already has the hash and can then brute force it, of course what I mentioned doesn't stop them, but that scenario is no different than knowing their phone's PIN and being able to side step any of the very same protections I mentioned that phone OSes use which is to use a lock-out after a certain number of failed attempts.

Comment Re: There we go again (Score 1) 383

Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.

Except what you are talking about was not what I was originally responding to. You basically injected yourself into the conversation and completely changed the context and then started calling me an idiot. I suggest you re-read what I originally responded to:

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

What I do is have a single, strong password that I have stored only in my brain and all other passwords are hashed on-the-fly from that and the domain or name of whatever I need the password for. I get unique, strong password for everything, but only have to remember a single one.

Do you notice that nowhere in that quoted statement is there anything about the attacker already having the password hash?

Comment Re: There we go again (Score -1, Flamebait) 383

You probably shouldn't try to write about things you don't know about or understand.

My irony meter exploded.

1. The industry accepted way to store passwords securely in a database is with a one-way, salted cryptographic hash (using as CPU intensive algorithm as possible).

Duh. Being Captain Obvious again?

2. Many organisations have had database intrusions where these password hashes have been stolen (eg. eBay [threatpost.com], Linkedin [sophos.com], LivingSocial [arstechnica.com] etc.)

Yes, they have.

3. When this happens (i.e. "they have a copy of the password hash") passwords can be cracked offline. Strong passwords are safe (too hard to brute force), but weak passwords can be found using a dictionary attack.

Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone.

4. Once the password is found offline a hacker can log straight in to the victim's online account with a single password attempt.

Only if you're system admins are dumb enough to not do what I state above.

Comment Re: There we go again (Score 2) 383

Only if the passwords haven't been salted properly. Even then, a rainbow tables attack can also be thwarted by the same techniques I mentioned above. Allowing any attacker the ability to do 10s of millions if not a couple of billion (with powerful enough hardware) tries a second to brute force a password is just the height of idiocy. Using constant time password checking, rate limiting, cooldown periods and as a last resort IP bans makes you such an unattractive target that they usually just move on to some other insecure site.

Comment Re: There we go again (Score 1) 383

Forgot to close my quote tag so fixing it.

However if a chosen password appears in a password dictionary than you can cut down your brute force search space by so much it goes from taking years (even centuries) to crack a password to taking a few hours (sometimes minutes).

Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary.

Comment Re: There we go again (Score 1) 383

You seem to have no clue what a password hash actually is.

Nope, you're just a poor mind reader.

Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary.

Comment Re: There we go again (Score 1) 383

To add above, just because the brute forcing theoretically might take a long time is no reason to allow someone to have unlimited tries. You never know when exactly their brute forcing will stumble upon the password. The user's password could potentially be within the first billion or so tries which means they could potentially brute force it in the first second with powerful enough hardware.

Comment Re: There we go again (Score 1) 383

Thanks for suggesting everyone configure their system such that I can DOS them!

It's better than allowing someone to brute force account passwords. When combined with IP banning when seen that someone is just trying to attack the system your DOS attack would be short-lived.

Slashdot Top Deals

To program is to be.

Working...