Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Length Matters
Message
De
14/03/2017 04:24:39
 
 
À
13/03/2017 15:54:19
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows Server 2012 R2
Database:
MS SQL Server
Application:
Desktop
Divers
Thread ID:
01648941
Message ID:
01649011
Vues:
60
>>>>>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 ?
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform