Linked by Howard Fosdick on Sat 10th Nov 2012 07:28 UTC
Bugs & Viruses If you want to ensure you have adequate passwords but don't have the time or interest to study the topic, there's a useful basic article on how to devise strong passwords over at the NY Times. It summarizes key points in 9 simple rules of thumb. Also see the follow-up article for useful reader feedback. Stay safe!
Thread beginning with comment 542148
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[15]: make 'm long
by Laurence on Mon 12th Nov 2012 14:28 UTC in reply to "RE[14]: make 'm long"
Laurence
Member since:
2007-03-26


They don't need to know your password. They just need to know if the hash they generated managed to authenticate themselves to a site as you. ie:

1) Estimate your passphrase
2) Generate the hash
3) Use the hash to try and authenticate

Sure, it's a few extra steps than

1) Estimate your passphrase
2) Use the passphrase to try and authenticate

It's one more level of indirection, but it still begins with a passphrase.

lol it's not nearly as simple as that.

Even just one character different will generate a completely different string of characters. So they have to know all of the following precisely:

* how you decide your salt (ie is it the full website address inc protocol handler, the URI or just the website name?

* the passphrase (obviously)

* how the salt is encoded into the passphrase (eg is the salt and passphrase concatenated, and if so in which order? or is the passphrase hashed then the hash salted? etc)

* exactly which encoding algorithm used (there's multiple different routines for sha alone. So it's not even a simple as predicting everyone would use sha512)

* which output encoding (will the output be a standard ASCII character string? Will it be Base64 encoded? is it unicode?)

* has there been any post processing (eg has the output hash been tampered with?)

Sure you could make a number of assumptions, but the level of complexity involved is massive and the difference between getting one details even 99% right but not completely accurate is the difference between eventually cracking the password and never cracking it ever.

So no, in all practicality you cannot reverse engineer in the method you describe and using "raw" passphrases like you keep advocating is still quite a bit less secure in comparison.


Seriously mate, I urge you to read up on this stuff as there's clearly some large gaps in your understanding here; which would be fine if you were asking questions, but instead you're trying to argue facts based on these gaps of knowledge and -with the greatest of respect- it's getting quite frustrating having to debunk all these misconceptions which you'd easily be able to debunk yourself if bothered to do a little independent research ;)

Reply Parent Score: 2

RE[16]: make 'm long
by kwan_e on Mon 12th Nov 2012 15:13 in reply to "RE[15]: make 'm long"
kwan_e Member since:
2007-02-18

* how you decide your salt (ie is it the full website address inc protocol handler, the URI or just the website name?


If they can analyze raw passphrases for behavioural patterns in chosen words, they can surely do the same for the salt. As you say before, they don't have to break everyone's - just the easy ones.

* how the salt is encoded into the passphrase (eg is the salt and passphrase concatenated, and if so in which order? or is the passphrase hashed then the hash salted? etc)


They can just use the service to generate the hash, so they don't even need to figure it out. They'll probably be able to automate the whole process and just target the, say, top 20 most used generators.

So no, in all practicality you cannot reverse engineer in the method you describe and using "raw" passphrases like you keep advocating is still quite a bit less secure in comparison.


They wouldn't need to reverse engineer. They could figure out the most popular generators and get those generators do the work of generating. All they will have to do is to get all the output variants and try it. They could even just use the web service you linked to, feed in its guesses, then scrape the returned webpage for the generated hashes.

Seriously mate, I urge you to read up on this stuff as there's clearly some large gaps in your understanding here; which would be fine if you were asking questions, but instead you're trying to argue facts based on these gaps of knowledge and -with the greatest of respect- it's getting quite frustrating having to debunk all these misconceptions which you'd easily be able to debunk yourself if bothered to do a little independent research ;)


I'm not even trying to argue anything.

Reply Parent Score: 2

RE[17]: make 'm long
by Laurence on Mon 12th Nov 2012 15:27 in reply to "RE[16]: make 'm long"
Laurence Member since:
2007-03-26

If they can analyze raw passphrases for behavioural patterns in chosen words, they can surely do the same for the salt. As you say before, they don't have to break everyone's - just the easy ones.

You can't unless salts like that get leaked. They never have.

They can just use the service to generate the hash, so they don't even need to figure it out. They'll probably be able to automate the whole process and just target the, say, top 20 most used generators.

This is another example how why you need to read up on the subject. It's not as simple as you state there. There's a number of different ways a salt can be incorporated and each method would create a completely different and incompatible result.


They wouldn't need to reverse engineer. They could figure out the most popular generators and get those generators do the work of generating. All they will have to do is to get all the output variants and try it. They could even just use the web service you linked to, feed in its guesses, then scrape the returned webpage for the generated hashes.

That's exactly what I was discussing what I said "reverse engineer".

Given the massive range of variables involved, what you're describing would be the least accurate password attack routine to target the smallest subset of passwords (as not everyone currently employs this method). Maybe if 10 years from now everyone used my method, then you'd have a point - after all, security is an ever evolving fight. However in the current here and now, trying to identify which routine created the hash and then what the input values were for that is such an impracticality that brute force attacks are much more efficient. Thus making such hashes a reliable password generator.

As always, things might change in later years (just as how passphrases were best practices in security just a few years previously). But at the moment, what I'm recommending is a decent solution ;)


I'm not even trying to argue anything.

to be honest, I'm not convinced that you're now just trolling me.

Edited 2012-11-12 15:47 UTC

Reply Parent Score: 2