And should we be using your same random-generated secure password for ALL of our sites - or a separate one for each.

If the latter, presumably we'd need much thicker wallets.

Gilles Schipper 
Sent via mobile
416-702-7900

> On Apr 10, 2014, at 1:21 PM, "James B. Byrne" <[log in to unmask]> wrote:
> 
>> On Thu, April 10, 2014 10:41, Bahrs, Art wrote:
>> Hi All :)
>>   Ok... some things to think about concerning the HeartBleed
>> vulnerability....
>> 
>>   - Change your passwords
>>      - This is a 'DOH'... as we all should be changing our passwords every
>> 45-90 days as a minimum... You do change yours regularly don't you?
>>   - This is not a new vulnerability!
>>      - it's been around for a couple years...
>>      - we must assume that the exploitation of it has been around for some
>> time... just not in the news
>>   - Remember this hasn't been remediated yet by a WHOLE LOT of sites!
>>      - this means that we need to keep changing our passwords regularly with
>> a very high frequency until patching is complete
>>   - Use good passwords...
>>      - I used 'good' rather than 'strong' for the simple reason of
>> dictionaries and/or Rainbow Tables
>>      - At least 10+ characters long
>>      - Use Mixed Case
>>      - Use Special Characters (@, !, ^, $)
>>      - SPELL THINGS WRONG intentionally!
>>           - e.g. EyeR3edB0ok$ instead of IReadBooks
> 
> The problem being is that many public websites do not allow special
> characters, including those run by many banks. Some operating systems only
> permit at most eight characters (cough, cough).  L33T spellings for most
> English words are already in the password cracking dictionaries and
> statistical analyzers and therefore provide no more security than the word
> properly spelled to being with.
> 
> Ten characters give at best 15 bits of entropy if just made up of Latin
> letters and the ten digits [A-Za-Z0-9] chosen from English words and phrases.
> On top of that, the password hashes that are passed over the wire are
> frequently un-salted and are created by crypt functions that themselves are
> not much better than SHA1 which itself is trivially cracked with today's
> processors.
> 
> Anything that you make up on your own without using some unbiased randomizing
> method will be easily cracked.  If you can make sense of what you have written
> for a password then, trust me, a statistical analysis will reveal it to
> someone else.  As an alternative, I have seen it recommended that one have a
> memorable phrase and take the first letter of each word to comprise your
> password:
> 
> A rose by any other name would smell as sweet. == Arbaonwsas
> 
> I have grave reservations about the efficacy of this approach to creating
> passwords, XKCD's https://xkcd.com/936/ take on the matter not withstanding.
> The reason being that common English speech employs something on the order of
> just 2000 distinct word stems and their common arrangement is guided by the
> rhythm of the language itself all of which which lends itself to statistical
> analysis.
> 
> Presently, anything containing less than 64 bit of entropy from a crypto
> standpoint is not much more secure than the lock on your car. Actually,
> anything less than 128 in today's world is only little more secure from a
> dedicated attack by people who know what they are doing.
> 
> This is why the move to personal X.509 certificates is unavoidable for high
> security applications. However, challenge and response password protected
> systems are not going to disappear overnight. So the alternative is to
> generate truly random passwords.
> 
> If you have access to real random number generator (not /dev/urandom) on a
> system with OpenSSL (of any recent vintage regardless of whether it has the
> exploit) then you can do this to create a reasonably secure password.
> 
> openssl enc -base64 <<< $(head -c 32 /dev/random)
> 
> which will generate something like this:
> 
> Qywh/2qrcQ5cPSWwSMyeozhQZm5Sc3ZbJ6iHLX39lwo=
> 
> And that, believe it or not, is representative of what it now necessary to
> create extremely hard to crack passwords.  If 256 bits of entropy seems
> overkill then you can simply reduce the byte count to some value that you are
> content to use, say 64 bits (but bear in mind that reducing entropy reduces
> strength):
> 
> openssl enc -base64 <<< $(head -c 8 /dev/random)
> 
> TNKv/RYRLqkK
> 
> 
> I advise my staff to write their password down on a plain slip of paper with
> no other information whatsoever contained thereon and to place it in their
> wallet.  Take it out to log on and then put it away again.  This idea that one
> should memorize a password and then change it every 60 days is utterly bizarre
> to my way of thinking.  It plays to the weakness of every human being, poor
> recall, and promotes trivial passwords.
> 
> Take heart, just because they are out to get us does not mean we should be
> paranoid about it.  Just be cautious.
> 
> -- 
> ***          E-Mail is NOT a SECURE channel          ***
> James B. Byrne                mailto:[log in to unmask]
> Harte & Lyne Limited          http://www.harte-lyne.ca
> 9 Brockley Drive              vox: +1 905 561 1241
> Hamilton, Ontario             fax: +1 905 561 0757
> Canada  L8E 3C3
> 
> 
> -- 
> ***          E-Mail is NOT a SECURE channel          ***
> James B. Byrne                mailto:[log in to unmask]
> Harte & Lyne Limited          http://www.harte-lyne.ca
> 9 Brockley Drive              vox: +1 905 561 1241
> Hamilton, Ontario             fax: +1 905 561 0757
> Canada  L8E 3C3
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *