Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Length Matters
Message
From
14/03/2017 04:24:39
 
 
To
13/03/2017 15:54:19
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows Server 2012 R2
Database:
MS SQL Server
Application:
Desktop
Miscellaneous
Thread ID:
01648941
Message ID:
01649011
Views:
59
>>>>>https://blog.codinghorror.com/password-rules-are-bullshit/
>>>>>
>>>>>I keep pointing people at the XKCD cartoon, but Atwood expounds further on the topic.
>>>>>
>>>>>If you're a dev or sysadmin in a position to influence password policy, PLEASE do the right thing.
>>>>
>>>>Hmm. Since most servers just store a hash value of the password why would longer be better ?
>>>
>>>If you're talking about password hashes being compromised, the answer boils down to the fact that the hash value of a long password is different from a short password.
>>
>>Different in what way ?
>
>Digests of all possible password strings up to some fixed length (say 8 characters) have been precomputed and stored in cloud storage, so getting back the password associated with that digest is basically a lookup. In contrast a long password has a different digest which is not stored in lookup tables.

Ha. I thought you were implying that there was an intrinsic difference in the actual hash of long and short strings.....

>>>That means that attacks such as cloud-based rainbow table lookups will likely fail; those tables have precomputed hash values typically only up to some (relatively short) length and limited character set. In contrast, the hash of a short password will be included in rainbow tables and getting the password is just a lookup.
>>>
>>>AFAIK salted hashes are best-practice for storage i.e. https://en.wikipedia.org/wiki/Salt_(cryptography) . If a server stores salted hashes then from the POV of that particular attack vector a long password would have no advantage over a short one.
>>
>>I've been using a PBKDF2 implementation (with 12 byte salt and 12 byte hash) for a while - good enough for the sites in question.
>>
>>>But all this is just discussing the subset of problems related to compromise of stored hash values. The article (and the original XKCD cartoon, for that matter) point out the practical advantages e.g. greater resistance to brute-force attacks, less chance of Post-It notes on monitors etc.
>>
>>True. But of course, if we are discussing web sites then, given that HTTPS may be the weakest link, the whole discussion is irrelevant :-}
>
>HTTPS is a high-value target so one may expect clever attacks e.g. https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html . Dunno how much has changed in the year since that article.

Looked at the NatWest site mentioned in the article. They are using 'Upgrade-Insecure-Requests' in the header which, I think, is similar to 'Strict-Transport-Security' except maybe only applies on a page by page basis ?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform