Re^2: Adjust bcrypt cost to prevent future password hash attacks

Data must be secured in transit and at rest. TLS protects data in transit only, and does not prevent offline attacks (e.g. recent Linkin breach).

We need both TLS and bcrypt, not just the former.

--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

Comment on Re^2: Adjust bcrypt cost to prevent future password hash attacks

Replies are listed 'Best First'.
Re^3: Adjust bcrypt cost to prevent future password hash attacks by Anonymous Monk on Jun 12, 2012 at 08:52 UTC
and does not prevent offline attacks of course not :) I wasn't suggesting switching away from bcrypt, merely that the cost is not as important for online attacks, those can be throttled effectively but, for offline, you should use encrypted harddisks and not rely on bcrypt alone	[reply]
Re^4: Adjust bcrypt cost to prevent future password hash attacks by dsheroh (Monsignor) on Jun 12, 2012 at 17:25 UTC
You seem to be associating "offline attacks" with physical theft of the hardware. However, they much more often (including in the recent LinkedIn/eHarmony cases) involve cases where an attacker has duplicated the contents of the user database. In such cases, encrypting the hard drive is completely irrelevant. Each of these measures is only applicable to certain types of attack: TLS only matters if someone is attempting to access data in transit. Disk encryption only matters if the hardware running the system is physically stolen. The hashing method only matters if the attacker has direct access to (a copy of) the password database. Whatever you may be trying to secure, you need to assess which threats are actually relevant to you and implement the appropriate security measures based on that (and on the value of the system/its data).	[reply]
Re^4: Adjust bcrypt cost to prevent future password hash attacks by Jeppe (Monk) on Jun 13, 2012 at 08:32 UTC
I beg to differ. Ideally, it should be safe to publish the hashes online as no-one should be able to search the password space in reasonable time.	[reply]