robtoo

So user feedback should be speedy enough.

Only once the password is deemed acceptable does the system need to pre-calculate the hashes for the next time the password is changed.

Of course, pre-calculating 10,000 bcrypt hashes might be too computationally expensive anyway, but the user wouldn't see a delay.

The end result? A user starts with the password "Seekrit1" when they join the company, then the next month they change to "Seekrit2", "Seekrit3", and so on.

This is hardly what the security policy intended, so stopping that happening isn't actually a bad idea.

Obviously storing a complete password history in plaintext (which would even have to be online for the consultants' plan to work) is ridiculous, but pre-calculating a bunch of hashes of similar passwords every time a new password is set would certainly be feasible.

Changing passwords is usually a rare occurrence, but making this at least slightly computationally-expensive shouldn't be a problem. Of course, the more expensive the password-hashing algorithm, the fewer "similar" passwords you would reasonably be able to pre-calculate, which is an odd trade-off to have to make a call on.

One thing to be wary of, though: by pre-calculating and storing a bunch of hashes of similar strings, this opens you up to (what might be called) a related plaintext attack. I have no idea if existing password hashes are specifically designed to be resistant to this, but would guess not. (edit: I didn't think this sentence through correctly. Thanks, Joachim)

We've created a marketplace built on trust, transparency and authenticity within our community, and we hold the safety of our community members as our highest priority.

I'm really not sure how he can reconcile that comment with the actions described in this post.

Well, for starters: company officers shouldn't be using weasel words to try and take credit for things they haven't actually done.

I hope this will prove to be a good quick-and-dirty way to add SPDY support to existing web services (which I expect will in turn help drive users to Chrome.)

Unfortunately, it's looking hard to test as webpagetest.org is going to be hit with long queues for a while...

Not if this quote from the linked article is true, you haven't...

airbnb.com tightly controls the communication between host and traveler, disallowing the exchange of personal contact information until the point in which a reservation is already confirmed and paid for.

Indeed: "When..." But AFAICR, Anonymous didn't gain control of either FBI or CIA assets. Hacking a self-described FBI "affiliate" and DDOSing cia.gov are hardly the same thing.

Also, holding up HB Gary Federal as an example of an organisation with "rigorous security protocols" is an amusing claim with no real evidence.

But he very specifically didn't say that he had "decided [Thomas Monopoly] can't have his account back".

This is presumably because that decision isn't even Matt's to make. (He is the head of the webspam team at Google.)

And even if this hypothetical layperson doesn't know how far a light-year is, 12 billion certainly gets across the point that it is an awful lot of them.

No description of what Amen actually do, but they themselves think they're pretty great.

And ... that's it?

The seomoz profile lists a couple of websites. One of those sites has a phone number on the /contact page, and the /about page on the other links to another business (not totally sure how I originally found that, but this is currently the quickest way to get there.)

That business has a couple more phone numbers listed on their homepage, which also matches the phone numbers on the shopfront on google street view.

This can also be cross-checked with whois.

A bit more googling (literally) of your names found an alternative (possibly old?) address in the same town, and googling that pulled up a fourth number.

If a password database is compromised, you have a problem, but you can change everyone's passwords.

If an iris database is compromised, you really have a problem.

Biometrics are also susceptible to replay attacks, where sort-of-alternatives (such as tokens) aren't.

It's not clear how using iris fingerprints rather than passwords really adds anything other than to increase the risk of a false negative, and introducing a third party dependency.

(I do take your point about storing a hash of the iris fingerprint, though. How this would intefere with the matching process is, I guess, outside of both our areas.)

To do iris-scanning security, there must be a back-end database with the characteristics ("fingerprint") of each user's iris.

This database will be secured as strongly/effectively as a password database because it contains authentication credentials.

Unfortunately, password databases get broken into, and similarly iris databases will also get broken into.

The attacker then has to simply convert the iris fingerprint back into an image to replay to the authentication process.

This is probably easier than reversing a password hash (because the fingerprinting algorithm is unlikely to be optimised against reversing), and certainly no harder.

(This is assuming untrusted client-side hardware.)

The back-end could be using bcrypt with a ridiculous work factor, and server security could be state of the art, but choosing your phone number as a password will always be a poor decision.

If his pay increase was less than inflation, then many people would say he did actually earn less.

There was just an SEO blogger with poor reading comprehension and an axe to grind.