back to article Confused by crypto? Here's what that password hashing stuff means in English

Cryptography is dead hard. But being conversant in the key aspects of cryptography – to the extent that you could even explain some of it to colleagues and management – puts you one step ahead of most. Here are five things that'll make you sound like you know what you're talking about. 1. Digital certificates The most common …

  1. JeffyPoooh

    Recurring history of crypto

    New = secure

    Middle age = not secure, but hard to crack

    Old age = don't rely on it

    Author touched on this towards the end of section 3.

    Failures are most often due to subtle flaws, not speed up of brute forcing.

    All cryptos seem to fail eventually, and not once has it taken 10^77 years.

    1. Anonymous Coward
      Anonymous Coward

      Re: Recurring history of crypto

      Because you are mistaking brute force time to the time to find and exploit a specific weakness.

      1. BasicChimpTheory

        Re: Recurring history of crypto

        Surely that was his/her point?

  2. knottedhandkerchief


    Good of El Reg to have bluffer's guides, but no mention of salts with hashing? A fundamental requirement, otherwise if you've got a table with lots of hashed passwords, just look for matching pairs and you can be pretty sure they are weak passwords, crackable with a dictionary of common passwords. Solution is to store the hash and a random salt in the table.

    1. Novex

      Re: Salts?

      This article seems to be a good one for crypto and hashing with salts:

    2. werdsmith Silver badge

      Re: Salts?

      I was on my way in here to mention the overlooking of salting, but you got there long before me. Well done chap.

    3. Adam 1

      Re: Salts?

      For unsalted hashes, you can usually get the raw password in 2 seconds by simply googling the hash.

    4. JerseyDaveC

      Re: Salts?

      Fair point: it was a question of where to stop - I was way over the word count already and there were other things I'd have liked to squeeze in too. But you're right - salting's an essential consideration.

    5. Anonymous Coward
      Anonymous Coward

      Re: Salts?

      I did something like this manually in the late 90s when I'd only just started in IT. My boss had written a program which would add the admin accounts for all of his IT staff to different domains, I was given the job of driving around running it on the servers using floppy disk (ah bless good old 3.5inch).

      At home I decided to open it up in a hex editor out of interest and noticed the usernames in plain text and hex next to them, I only knew my own password so could figure out which set of hex was mind thanks to thankfully having my word end in "wood", those double "o"s were indispensible.

      After sitting with pen and paper deciphering my own password and figuring out how the hex related to the letters and numbers in it I went back and took note of everyone else's password.

      I never used the knowledge, it was just a bit of a challenge at the time.

  3. PaulAb


    With all the other stuff you have to day to day, this is a nice, easily digested, memory aid.

    Obviously I do know everything, as most users know(even several hundred passwords - apparently).

    Thanks for this.

  4. regadpellagru

    good article

    Maybe for the sake of completeness, you may add certs can optionnally also be used to authenticate client users.

    I know, almost nobody has ever used it, the only web site I've seen use it was the french online tax declaration web site, 10 years ago. But they removed it 3-4 years ago, probably because no-one was able to install a client cert on their browser :-)

  5. MotionCompensation

    Newer is better?

    "...since SHA-3 was officially released as a standard in 2015 you should choose that if it's available in your implementation... it's only been around for a short while and hence people have had far less opportunity to break it than the its 2001-launched predecessor."

    Wouldn't it be wise to wait a while, give more people the opportunity to try to break SHA-3? I'd say we're less sure of how secure something is, if less attempts have been made to break it.

    1. JerseyDaveC

      Re: Newer is better?

      It's an excellent question - and one that we debated at length with the instructor (a time-served, PhD-holding security guru turned security instructor) on my CISSP course last year, actually. You're absolutely right to point out that it says something when an algorithm has been around for years without being (knowingly) broken. On balance, though, we decided that the goal of making SHA-3 significantly stronger than SHA-2, combined with the intense competition and scrutiny involved in the selection process for the algorithm of SHA-3 (it literally was a competition - check out probably made it the one to choose.

      In practice I'd be happy with either SHA-2 or SHA-3. And for reasons others have alluded to in comments here, you wouldn't touch the previous versions with a bargepole.

      1. MotionCompensation

        Re: Newer is better?

        The mathematics behind SHA-3 may have been scrutinized very well. But how good are the implementations that we rely upon?

  6. petef


    You correctly state that MD5 is no longer up to the job for hashing but do not mention SHA1. That elicits warnings from Google based browsers at the moment and Microsoft say that they will not accept SHA1 after 2016.

    1. Adam 1

      Re: SHA1

      For some perspective, the cost of generating a collision for md5 is less than a dollar. Generating an sha-1 collision is in the order of 75,000 dollars.

      For most threat models, collisions on sha-1 are not a real world issue just yet; but it takes a while for it to work its way through the system. If you keep using sha-1 certificates, then by the time those new certificates expire then the collisions will probably be heading towards half that price. The point was to sunset it before it got to the point of actually being insecure.

      1. Michael Wojcik Silver badge

        Re: SHA1

        Generating an sha-1 collision is in the order of 75,000 dollars.

        Probably more, since no one has published a true SHA-1 collision. The $75K figure is a wild-ass guess, extrapolating from a free-start collision. While that free-start collision is an important result, it is by no means a true image collision.

        The fact is, at this time, SHA-1 remains more than adequate under many reasonable threat models. People are deprecating it mostly because it's easy to do so (since the SHA-2 family is widely supported, and SHA-3 is getting there), so we might as well get started.

  7. Anonymous Coward
    Anonymous Coward

    One more rule

    One final item you need to know regarding crypto: Don't ever try to write your own! You will fail, completely, dramatically, and embarrassingly.

    1. JeffyPoooh

      Re: One more rule

      "Don't ever try to write your own! You will fail, completely, dramatically, and embarrassingly."

      That rule applies to far more people and organizations than is widely believed. Orders of magnitude more. Further up the crypto hierarchy than can fit into naive minds.

      E.g. Right now, somebody is working the long weekend to crack open a certain 'uncrackable' iPhone.

      It's hopeless.

      Better read Asimov's 'The Dead Past', because that's exactly where we're headed.

      1. EddieD

        Re: One more rule

        +1 for the Azimov story reference - one of his more subtle, but extremely good, short stories.

    2. JerseyDaveC

      Re: One more rule

      Yup, I'll second that. It's a mantra that you can apply to pretty well any field of computing, actually - these days there's not often an instance where you have to write something from scratch in its entirety. In fact I can only remember one instance* in recent memory where I've had to do so - most of the time there's something out there that you can use to solve part or even all of a problem.

      (* If you're wondering: it was a code library to enable a Mac to interface directly to an Inter-Tel phone system's CTI stream).

  8. Anonymous Coward
    Anonymous Coward

    "To obtain a certificate from a CA you have to convince them of your credentials"

    Unluckily, even if it was meant to work that way, is not how it works actually - because CAs are commercial entities and certificates are a business. Thus plain certificates can be often be bought without much vetting from CAs - unless they are the more expensive Extended Validation ones.

    Some CAs are known to be too little careful about what they issue, up to the point some (i.e. Google) is putting them in the "you should not really trust them, or trust them at your risk" lists.

    Moreover now in the push to encrypt communications for fear of three (or four) letter agencies intercepting them, there are now non-profit entities issuing them, again without much vetting.

    Given the increasing importance certificates have, IMHO that should become a regulated market as other are (i.e. banks) with full accounting and liability if something goes wrong (not that bank are held much liable, though...). After all, nobody ever said certificates should be very cheap.

    1. Preston Munchensonton

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      Given the increasing importance certificates have, IMHO that should become a regulated market as other are (i.e. banks) with full accounting and liability if something goes wrong (not that bank are held much liable, though...). After all, nobody ever said certificates should be very cheap.

      I'm sure the NSA and GCHQ applaud your sentiment. Do we all really need certificates to become as screwed up as health care or taxes?

      1. Anonymous Coward
        Anonymous Coward

        Re: "To obtain a certificate from a CA you have to convince them of your credentials"

        Would you like everybody being able to setup a bank - without any check, or make/sell pharmaceutical? I'm not saying those markets are often bad as well because people with a lot of money can easily lobby and deceive a lot - but without regulation people would be exposed to even more bad guys exploiting them. Would you like passports and driving licenses being issued like certificates are? Very little checks, just pay?

        Face it, if you can't trust who is behind a certificate, certificates are useless. Actually for NSA & C. the situations is far better now, and for crooks as well. Far easier to MITM whoever you like - making encryption just a fake one. You have very little chances of being sure a certificate is issued to a verified entity. If the big names are somehow protected, the medium/small ones are not.

        Then you can believe government and any rule are always bad - you should just try to live in a true anarchic society - usually they don't end well and degenerate in the worst way.

    2. Dave Howe

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      Worse yet... effectively to get a certificate from a CA you have to convince them to take money from you. In the case of EV, you need to convince them that you are a company before they will take your money. That doesn't always mean you need to *be* a company, just that you have to convince them you are. Easiest way to convince them of course is to actually be a company, which (taking a quick look at off-the-shelf pre-registered company suppliers) will set you back all of £60....

      1. Doctor Syntax Silver badge

        Re: "To obtain a certificate from a CA you have to convince them of your credentials"

        "(taking a quick look at off-the-shelf pre-registered company suppliers) will set you back all of £60...."

        That's inflation for you. IIRC they used to be a tenner.

    3. Nick Kew

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      The CA model is broken, as demonstrated by a fair few incidents reported in El Reg and other techie media.

      In the absence of a WoT made simple enough for Joe Public, a move to a distributed trust authority is overdue. M-Pin gives us the framework for that.

    4. JerseyDaveC

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      Yeah, it's an interesting point. I remember applying for my first digital cert back in the 1990s - it was an absolute ball-ache as we had to send all manner of documentation to the CA - articles of incorporation, the lot; I was half-expecting to have to send a vial of blood. It's a whole lot easier these days. One would hope that the browser/OS makers would remove trust for CAs that get themselves a reputation for being over-easy ... whether that actually happens is another thing entirely, of course.

    5. Allan George Dyer

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      "nobody ever said certificates should be very cheap" -

      but they are a lot more useful if they are cheap AND trustworthy. If they are cheap, then everyone can afford one, so everyone expects them to be used, and all transactions become more secure. If they are expensive, then the expense excuse is routinely accepted, and even organisations that buy the expensive certs don't get the full benefit because their customers can be fooled by the excuse.

    6. Anonymous Coward
      Anonymous Coward

      Re: "To obtain a certificate from a CA you have to convince them of your credentials"

      I think this article has lost the fundamental point about certificates, which is that the certificate declares that *the holder of a specific private key* has the asserted identity.

      The way this article reads, you'd think that certificates are something private - something that you have to keep secure and not give away, like a passport.

      This is simply not true. You can publish your certificate to anyone who wants to see it. Indeed, when you make a TLS connection, your certificate is returned directly to the person connecting, no questions asked.

      The certificate is a document which binds together:

      1. an identity (e.g.

      2. a public key

      3. a validity period

      4. a signature (created by a CA using their private key)

      The website has to go through a dance to convince you that they possess the *private* key which corresponds to the public key in the certificate. Then you have to validate the signature, using your local copy of the public key of the CA. And you check the current time is within the validity period.

      Once you've done all this, you know that the CA asserts that the server you are talking to has the given identity.

      This article leaves all mention of public/private keys until point 6, and as far as I can see, makes no mention of the intrinsic use of public/private keys with certificates. If you don't understand this, then you don't understand the risks with certificates (e.g. if your server is compromised and the private key is lost).

      If you want a non-technical analogy, then the certificate is like a glass slipper. The identity is Cinderalla, the private key is her foot, and the Certificate Authority is the Fairy Godmother (who made the glass slipper to fit Cinderella's foot and no other).

      The other point about certificates is that they normally make no assertion about the principal apart from "this key belongs to the owner of domain". With the advent of free CAs like startssl and letsencrypt, all you need to do is to prove you can add a DNS record or receive an E-mail at the domain contact address, and you get a certificate.

      In particular, a certificate provides *no* assertion that:

      * This site is a particular type of institution, say a bank registered in the UK

      * This site is "trustworthy" or "safe to do business with" (for some definition of those terms)

      However, if you're lucky, an "EV" certificate will give you a verified company name of whoever you are talking to.

      1. EnviableOne

        Re: "To obtain a certificate from a CA you have to convince them of your credentials"

        A certificate islike an ID card or passport, you can show it to anyone you like and it says the issuing authority trusts the person detailed within, but you missed one thing, the user provides the certificate along with a signature, it's hostname encrypted with the corresponding Private Key which the user decrypts using the Public Key on the certificate and checks against the hostname on the cert hence verification.

        I.E. cert says "I (CA) certify that if you decrypt a signature using a set algorithym, using this public key and it has this identity (issued to), during this period (Validtity), the identity is trusted by me (CA.)"

  9. Stevie


    Nice one, Dave. Short, sweet, to the point and factually correct.

    An object lesson in how to communicate complex ideas with simple methodologies so that they are understandable for a user.

    And while I agree that salt techniques are important, I disagree with a commentor that they were "missing" from this document. That subject belongs on a follow-up article.

    I'm bookmarking this so I can share it with interns and new hires.

    Have beer.

    1. Charlie Clark Silver badge

      Re: Bah!

      And while I agree that salt techniques are important, I disagree with a commentor that they were "missing" from this document

      An unsalted hash is merely obfuscated and not encrypted, this is why salts are essential and not optional.

      1. Michael Wojcik Silver badge

        Re: Bah!

        An unsalted hash is merely obfuscated and not encrypted

        A salted hash isn't encrypted either.

        this is why salts are essential and not optional

        There are many applications of cryptographic hashes where salting is not required, such as typical MAC and HMAC applications.

        But I suppose this is the sort of comment to expect on an article that claims ECC is an asymmetric encryption algorithm.

  10. Anonymous Coward
    Anonymous Coward

    Chrome's "Pinning" doesn't appear to work

    Unfortunately, where I work they snoop everything. Our wonderful IT guys have installed a fake certificate into all the IE browsers (the official browser), and they launch a "man in the middle" attack on any https traffic. (That's why they don't have time to FIX the many problems our systems have, because they're too busy playing Secret Agent Man. Well, one has to prioritize.)

    I use Firefox and was warned immediately when they started this snooping. Firefox warned me that every SSL conversation was not to be trusted. That was clearly because Firefox did not have the bogus certificate installed. I know this is true because I tried installing the bogus cert into Firefox, and the warnings stopped instantly.

    On the other hand, after reading this article, I installed Chrome, and I did NOT install any certificates into it. I navigated to, and Chrome was completely happy with the web site. I checked, and it's showing the bogus self-issued certificate as completely trusted. I wonder what is going on with that? Firefox detected the snooping, and Google completely ignored it.

    Maybe I'm missing something, but it seems that Chrome's "Pinning" needs work.

    AC for obvious reasons.

    1. Anonymous Coward
      Anonymous Coward

      Re: Chrome's "Pinning" doesn't appear to work

      Not sure what version of Chrome you use but for me (Chrome 49+) Google "breaks" at one customer site because they MitM via a "transparent" proxy. These SSL deal breakers are arguably valid in a school for the kids only but legally suspect in a business IMNSHO.

      I once pointed out to someone in a NHS hospital that their WiFi had a MitM proxy and that hence they would be advised not to use it for online banking. Strangely enough a proper(ish) warning appears now when you connect.

      I use an OpenVPN through the proxy back to base. Their logs must look hilarious and the content checkers must have fun looking at gibberish. A funky L7 filter could block my VPN but it will hard fail safely unless the server cert checks out properly. I'll just use my mobile instead via tethering.

    2. Chris Miller

      Re: Chrome's "Pinning" doesn't appear to work

      More or less every organisation will do something similar, not because they want to read your billets doux to your significant other, but so they can check that attachments in encrypted emails are free from (obvious) malware. Most security devices come with such a global certificate, which the sysadmins can install on all machines under their control.

    3. hazzamon

      Re: Chrome's "Pinning" doesn't appear to work

      Chrome on Windows uses the Windows certificate store, the same one that IE uses. Firefox, on the other hand, uses its own built-in certificate store. Hence, the discrepancy.

    4. Danny 2

      Re: Chrome's "Pinning" doesn't appear to work

      Steve Gibson has some nice freeware to check for that, if anyone is worried their employer is doing the same - Fingerprints

  11. Anonymous Coward
    Anonymous Coward

    Good read as other Reg articles starve the reader of technical info...

    Why not offer more 'learning' articles? Three stories El Reg ran this week on Ransomware / USB-Malware didn't have enough 'insider' or technical content imho (see below). Users asked me challenging questions I couldn’t answer, as nothing I'd read on the Reg was in-depth enough, just the equivalent of the BBC 'dont scare readers' etc...



    Question: Can you slave the drive / use a USB enclosure to get at the files?



    Read the Reg article and the linked one, but not clear about something:

    Q1. Connecting the USB causes install driver code to run off the device itself (firmware)? I thought driver install code only ran from drivers installed on the windows side? (assume 'Autorun' disabled)

    Q2. Does the Trojan use a Hidden partition to store itself or the offline captured files? (Reported free space gets masked etc)



    Starved of information: 3 things never learned from Randomware tech articles...

    Q1: Any of the Ransomware variants show up in Task Manager... If not, are they using $Hidden processes or obfuscated as windows subsystems (i.e. svchost etc)?

    Q2: Does running a profiler like SysInternals-ProcMon, help? If you set Winrar to backup your entire hard drive etc, it has a noticeable effect with greater hard drive activity and a slowdown in performance (even running in the background). So is ransomware running at low priority yielding to the OS and other tasks to help keep it hidden?

    Q3. Saving M$-Office files without file-extensions... Does this offer a shred of protection? (Lets say you're giving out advice to friends / family who you know always ignore errors and only update AV / anti-malware at Christmas, if ever)?


    1. JerseyDaveC

      Re: Good read as other Reg articles starve the reader of technical info...

      Thanks for the positive feedback. If you're old enough to remember Network Week (launched 1995, ran for a few years), you may remember a column entitled "RTFM". This came about by accident: on press day the ed came to me to see if I could throw a thousand words together to fill an unexpected gap. So I did a basic intro to something (IP networking, I think it was) - really noddy but it got us out of a hole. Then we got loads of email from people saying: "Hey, that taught me enough to understand some stuff that people were saying, and helped me be a little bit conversant". So we did loads more over the weeks, and they went down well.

      I'll have a chat with some of the editorial gang at the Reg and see what they think.

  12. TRT Silver badge

    Short, sweet and to the point.

    He encrept into the encrypt, encrapped and encrept out again.

  13. cantankerous swineherd

    unfortunately it seems to be possible for someone (actually, anyone) to get a certificate for my domain without me even knowing. this state of affairs is what passes for a secure internet.

  14. Anonymous Coward
    Anonymous Coward

    Thanks, more please...

    The article had just enough info to gain a deeper understanding or to refresh known facts. But was never so in-depth it left you feeling glassy eyed. More concise learning articles like this from El Reg please!!

  15. jonha

    512 bit ... 32 byte ... TGIF

  16. Anonymous Coward
    Anonymous Coward

    Mistake in Whats Hashing section

    512 bits is 64 bytes, not 32 bytes.

    1. JerseyDaveC

      Re: Mistake in Whats Hashing section

      Oops - good spot. In my defence it's nearly 40 years since I learned my two times table, so I've started getting forgetful ... :-)

  17. Anonymous Coward
    Anonymous Coward

    Great article !

    Thanks for this, and it's even on one page !

    I'll click a few more so you still get your crucial page views :-)

  18. Derpity

    Idea for next article

    Maybe you could put up an article explaining what DevOps is in a similar fashion?

    1. Captain DaFt

      Re: Idea for next article

      DevOps articles have me rooting for this guy. :/

  19. TeeCee Gold badge


    So, in other words, pinning means: "We trust the following CA's, but not enough that we think they won't issue a bent cert purporting to be for our site. We need to check to ensure that the cert is from the right trusted CA...."?

    If bent certs from trusted CA's is a real risk, then the word "trust" is being heavily misused by someone and fixing that, rather than sticking a layer of tape over the hole, is the right way to go.....

    1. Derpity

      Re: Pinning.

      I can see how the description given in the article could lead you to that conclusion.

      The below website has a differently worded description where its less about dodgey CAs and more about "pinning" the cert to the host.

    2. JimBob01

      Re: Pinning.

      "If bent certs from trusted CA's is a real risk”

      A major issue is the transparency of “Trusted CAs”. Who decides which CAs make the list?

      MitMing is very common in larger orgs but requires installing the cert on all user machines (twice if FF is available). If you are on the trusted CA list then you can easily create a certificate to match * that no browser will bat an eyelid at.

      Wonder how many trusted CAs are fronts for 3+ letter agencies, eg looking at my Keychain ...anyone really trust “DoD Root CA 2”, “Federal Common Policy CA” or the Taiwanese “Government Root Certification Authority” (also in FF)?

  20. Anonymous Coward
    Anonymous Coward


    I learned a lot from this article.

    As an attentive student I have a question though. Why would one send a message twice (second time in hashed form)? If A would encode his message first with his own private key and then with B's public key, would that not do it? In order to decode, B would first use his own private key, which means that nobody but B can read the message. Secondly B would decode with A's public key, so that B knows for certain that A is the sender.

    So, it seems to me that sending a single message, twice encrypted, would be safe. Or do I overlook something here?

    1. Kanhef

      Re: Question

      I think it's just a matter of efficiency: the hash is much shorter than the original message, so encrypting and decrypting the hash takes less time than double-encrypting the entire message.

      1. Anonymous Coward
        Anonymous Coward

        Re: Question

        I take it from Kanhef's answer that I understand the public key procedure correctly and I believe Kanhef that working with hashes takes fewer CPU cycles, less bandwidth, etc. However, if the procedure (hashing of A's earlier message and comparison with the hash sent later) at B's side is not automatic and if the messages are not too long or frequent, double-encryption may be easier for the average terrorist, methinks.

        1. Michael Wojcik Silver badge

          Re: Question

          I take it from Kanhef's answer that I understand the public key procedure correctly

          Probably not - at least as it's implemented in practice. The article necessarily provided a high-level gloss of a theoretical description of the use of asymmetric cryptography. It bears only a vague resemblance to what actually happens in widely-used protocols.

          For one thing, it only talks about authentication, not other uses of asymmetric encryption or key exchange; and only sender authentication, not other applications of digital signatures; and omits many other complicating factors.

          But the short answer is that asymmetric encryption is orders of magnitude more expensive than symmetric encryption, and several more orders of magnitude more expensive than hashing. Encrypting the message twice would also mean transferring more data. There's absolutely no reason to do it.

          double-encryption may be easier for the average terrorist, methinks

          I have no idea what this is supposed to mean. I very much doubt "the average terrorist", insofar as such a bugbear even exists, knows fuck-all about cryptography.

  21. AndrueC Silver badge

    Digital certificates are all about trust: basically the CA is vouching for the identity of the Web site

    Although the level of proof varies. For my own domain (a I was required to add a record to my DNS. I did this by emailing my registrar who always do anything I ask regarding my domain even if I accidentally use my work email account and thus have no obvious link to it. As it happens they were a bit slow in responding and GoDaddy eventually accepted my certificate before my registrar made the change.

    So I apparently got a certificate from GoDaddy just because I paid them £40 on a credit card.

    Oh well. Hopefully .com and require more careful vetting :-/

  22. Paul Moore

    Sorry David, but your explanation of password hashing is entirely wrong.

    You cannot "decrypt" a hash. It's not enciphered, it's digested/hashed... it's dangerous to swap the terms "hashed", "encoded" and "encrypted", as they're entirely different principles.

    If you're looking for a message digest algorithm, SHAx will serve you very well. If you're after a password storage algorithm, never *ever* use MD5/SHAx etc. It is not intended to be used to store passwords in a secure fashion.

    Research sCrypt, bCrypt, Argon2i or PBKDF2; something which adds a significant work-factor to generating the hash. SHAx may be cryptographically secure, but it's not computationally secure (MD5 is broken on both counts). Each login needs to consume sufficient resources to slow the hash generation by 0.2/0.5 seconds but not enough to burden the server in the event of an attack/load. It's important to establish a happy medium for your server, mindful that algos like PBKDF2 reach the point of diminishing returns very quickly. For example, there's little appreciable difference between 100,000 and 200,000 iterations in terms of actual, real-world strength.

    Set a reasonable password length limit (50 is plenty with no other constraints), validate the input meets any strength requirements and hash the input. Never derive any other data from either the original secret or the output digest (think Ashley Madison) and don't force the user to change their passwords at regular intervals. If you must use "security questions" (I highly recommend you don't), treat the answers as you would a password.

    1. Will 28

      Why do you want to limit a password length


      I have to ask, as you clearly know a fair bit about this stuff, but then have dropped in this suggestion that you would have a length limit on a password. Why?

      I had a quick search on the subject, but cannot find any security benefit to applying a limit.

      1. Paul Moore

        Re: Why do you want to limit a password length

        Hi Will

        Algorithms like bCrypt limit password length to 72 characters, though many people use SHA256 to "pre-hash" the input in a futile attempt to increase security. Even algorithms which don't specify a max limit can adversely affect performance at higher numbers, thus forcing a sensible limit to be imposed by the developers.

        I won't bore you with chapter & verse, but it essentially boils down to this.

        If your password is chosen at random (ie - by a password manager, not a human) and you're allowed to use mix-alphanumeric (a-z, A-Z, 0-9), there's no appreciable security benefit between 15 characters and 500, even if the site uses something as weak/broken as MD5. 62^15 (62 possible characters - to the power of 15, the length) is such a monumental key space, it's already computationally infeasible to break. Adding another 15/30/50/100 characters is technically "more secure" but in terms of mitigating real-world risk, there really is no benefit at all.


        If a site limits the character set (for example, you can't use uppercase), the length must be increased to make up for the loss in entropy.

        log2(26) = 4.7 bits of entropy per character (26 being a-z)

        log2(52) = 5.7 bits of entropy per character (52 being a-z, A-Z)

        To achieve 80 bits of entropy (very strong, sufficient for financial transactions etc), you'd need 17 characters with just lowercase... or 14 with upper & lower.

        I recommend 50 characters because it strikes a balance between robust security & performance, as modern hardware can churn through a 50 character password almost as quickly as 15 characters.


  23. Doctor Syntax Silver badge

    "Sorry David, but your explanation of password hashing is entirely wrong.

    You cannot "decrypt" a hash. It's not enciphered, it's digested/hashed"

    Which article were you reading? The one I read said nothing of the sort.

    1. Adam 1

      > A hash function, in a cryptographic sense, takes a chunk of data and makes it into another anonymous-looking chunk of data that is, to all intents and purposes, impossible to revert back into the original form

      Using the phrase that is to all intents and purposes impossible to revert hits pretty close to the complaint.

      It implies that maybe some TLA has enough resources to do it but no bad guys can. It is the wrong way to think about hashing. It is absolutely impossible to determine the source value. The process is deliberately lossy so it isn't just a matter of CPU power. It isn't just a trapdoor function like prime factorisation (hard) vs multiplication (easy) or the discrete logarithm problem.

      Literally the only way to find the source is to try and brute force or dictionary attack the hash. But in any case, a reversal isn't normally the goal. An attacker is usually only after a reversal or collision because either way you can authenticate with it.

      1. Michael Wojcik Silver badge

        Literally the only way to find the source is to try and brute force or dictionary attack the hash

        Even this is wrong. By the pigeonhole principle, you can't find the preimage for a given hash value, unless you have additional information about that preimage. At best you can find one or more of the infinite1 number of preimages.

        A bigger problem with the statement in the article, though, is that "to all intents and purposes" is wrong, because often it is possible, in practice, to find a preimage - as many have pointed out in the comments.

        So it's wrong from both directions: On the one hand, you can't, with complete certainty, find the original, unless you have additional information. On the other, you can often find something that may be the original, or something else that will let you defeat whatever cryptographic mechanism you're attacking.

        1Assuming unbounded input length.

  24. brotherelf

    Minor quibble:

    Of course you can have public-key crypto without signatures, then you just don't know who the message is from, so what's signing doing in 5?

    And even if it's never done in practice as far as I know, you might want _different_ key pairs for signing and encrypting. If your signing private key is lost, you can revoke it and get a new one, no harm done. If your encryption private key is lost, your data is gone. On the other hand, somebody with your signing private key can impersonate you (very bad), somebody with your encryption private key can "only" read encrypted communication directed to you.

    1. Michael Wojcik Silver badge

      Re: Minor quibble:

      And even if it's never done in practice as far as I know, you might want _different_ key pairs for signing and encrypting.

      Actually, it's quite common. See for example this discussion.

      Some cryptographic applications, notably common SSL/TLS cipher suites, avoid the issue by not doing general-purpose asymmetric encryption at all. Instead they use one of the various key-agreement (aka key-exchange) protocols to derive the same sets of session keys on the client and server. Thus we don't need two keypairs for each participant in a TLS conversation that's using a suite with RSA.

      (These days many people prefer ECDHE for TLS key agreement, because it provides Perfect Forward Security, more or less; and then use RSA or ECDSA for authentication.)

  25. Lucasjkr

    Correct me if I'm wrong, but the suggestion to use SHA for password hashing seems not appropriate. SHA2's hashing function, at least, runs easily on AMD Radeon chips, as a result it's trivial to set up password hashing farms. SHA is still useful for verifying the integrity of data, but a more secure function should be used for password authentication purposes.

    1. Michael Wojcik Silver badge

      If you're using unsalted hashes as password verifiers, you're doing it wrong. The choice of hash algorithm really doesn't matter.

      If you're using salted hashes and the password space is large enough, and you have measures in place to prevent weak passwords, then attackers can run all the crypto accelerators they want and build huge rainbow tables if it pleases them; they aren't going to be able to search that space anyway.

      (And they're not going to do it with general-purpose CPUs. GPUs are way faster.)

      As Paul Moore pointed out above, even using a salted cryptographic hash really isn't a great practice either (though whether it's worth doing anything more is a more complicated economic question than he admits). Something like bCrypt or PBKDF2 increases the work factor significantly.

      But, as Paul also noted (though not in so many words), you can't reasonably increase the work factor enough to defend weak passwords against offline attacks, if an attacker gets hold of your verifiers and salts. Such an attack can run through commonly-used passwords quite quickly.

      Here is a discussion from 2012-2013 about brute-forcing PBKDF2. Note one comment estimates - at the time - calculating ~4 billion PBKDF2 salted hashes per second, on a single GPU-equipped machine. If you have a 36-character alphabet for passwords, that's about two seconds to check all the 6-character passwords, if my back-of-the-envelope calculation is right.

      In short, if you're concerned about attackers finding preimages for your verifiers, implement decent verifiers and password-strength rules. But using SHA-1 (salted, or as part of a construct like PBKDF2) is not the problem.

  26. -tim

    I found the simplest way to discuss hashes as used in passwords is by oversimplifying them. One of the simplest hashes is "count the letters in the password". So "1234" would have a hash of "4" and "letmein" would have a hash of "7". It is trivial to see how collisions would be an issue for using that hash algorithm as any 4 character password would work for any other 4 character password. Another weak yet slightly stronger hash would be convert A -> 1, B -> 2 and then sum the digits but "AD" then collides with "DA", "BC", "CB", "AAAAA", "ABB" and others. A typical mistake in cryptography is to try to combine excessively weak components to make them stronger such as start a hash out with the count and then the 2nd character would be the sum of all digits (without carry), and then the 3rd character would be the sum of all the digits but the 1st. While it complicates things, a bit of reverse engineering shows it is not very good and yet a brute force attack would show far too many collisions. Similar techniques were used in old programs to generate encryption keys which were quickly broken.

  27. Alistair

    This article neglected to mention

    Pepper too!

    If you need salt, you should have pepper too!.

    Mooooooooore Pepper.

    <no, actually, Alice through the looking glass, not the musical pair....>

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like