Hacker News new | past | comments | ask | show | jobs | submit login

I'm not sure there is much significance to this article.

It points out "The technique doesn't apply to online attacks, because, among other reasons, most websites limit the number of guesses that can be made for a given account."

Same applies to Windows.




I think what they're referring to is having access to the physicial harddisk. In linux terms it would equate to having a copy of the /etc/passwd file.

For example the FBI seizes someones computer. This would allow them to brute force without said restriction.

So yes, from an online, or standard entry viewpoint this is a moot point. Also a properly encrypted hard drive using something like truecrypt is still pretty impenetrable regardless.


I've grabbed the SAM file from remote IIS servers in my younger years and cracked the passwords locally.

Buffer overflow the web service, bind a command shell to a port running as the system account (by having the system execute shellcode used in the buffer overflow), netcat to your open port, ftp the SAM (located in the repair directory) to somewhere you can retrieve it, download the file, delete all of the logs, crack the file.

Hard drive encryption would have done nothing to prevent this.


> Hard drive encryption would have done nothing to prevent this.

And it's quite common in corporate environments for PGP Desktop HDD encryption to be setup to use the Windows password as the key to accessing the HDD encryption key(s).

For this reason we're advised not to put out laptops in sleep mode when transporting the laptop as someone finding the laptop could do something like the above (remote exploit and then get access). When coming out of hibernation PGP desktop requires the HDD password to be provided so that it isn't in an exploitable state.


I doubt law enforcement would go that route if they seized your stuff.


Technically you want /etc/shadow as that is where the actual hashes are stored.

On a Linux system usually any user has at least read access to /etc/passwd but only root has /etc/shadow.

This attack would presume that you already have either physical access to the disk or you have already compromised the machine remotely to basically root or admin type level.

Of course being able to get the actual passwords of users would be useful to an attacker because they might be able to use them to elevate from access to one system to potentially other systems where users might well be using the same password.

Not sure how drive encryption with Truecrypt would work in this case. I presume password hashes are stored outside of the encrypted part otherwise every user would have to enter the volume key before they signed in regardless of their access level. Which would mean distributing the volume key widely.

Truecrypt is also vulnerable in the sense that it is often possible to grab the volume key straight out of DRAM if the computer is on or has only recently been switched off.


Offline attacks matter. The last few years have seen a continuous stream of high profile account database leaks. There are now some 1 billion known real user selected passwords that are readily downloaded from any of a number of shady sites.

It is irrational to assume that password database leaks won't continue.

The hashing scheme and salting matters less and less, as the total entropy humans can conveniently recall is quite limited and moore's law keeps marching.

We need a fundamental rethinking of security and identity on the internet, and IMHO the OSS world needs to get there before partisan commercial interestes.


I saw a talk on Mozilla Persona [0] the other day from one of the devs. I like the idea of these decentralised authentication systems. I was (and still am a fan of) OpenId too.

There is no practical reason that website operators need to know that a user typed in the right password, only that they are who they say they are. Anything which is able to prove this (to a satisfactory level) with the least amount of information being stored by the website is good in my books.

[0] - https://www.mozilla.org/persona


Thinking about it some more. Is the only practical exploit of this the case where a rogue sysadmin wants to figure out user passwords (without resetting the password and therefore alerting the user)?


I disagree. If a website gets hacked and its customer database is stolen, then this could be used to crack the user passwords.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: