A More Correct Horse Battery Staple

Passwords are terrible. The usual requirements of a number, capital letter, or punctuation mark force users to create unmemorable passwords, leading to post-it notes; the techniques that were supposed to make passwords more secure actually make us less secure, and yes, there is an xkcd for it.

[Randall Munroe] did offer us a solution: a Correct Horse Battery Staple. By memorizing a long phrase, a greater number of bits are more easily encoded in a user’s memory, making a password much harder to crack. ‘Correct Horse Battery Staple’ only provides a 44-bit password, though, and researchers at the University of Southern California have a better solution: prose and poetry. Just imagine what a man from Nantucket will do to a battery staple.

In their paper, the researchers set out to create random, memorable 60-bit passwords in an English word sequence. First, they created an xkcd password generator with a 2048-word dictionary to create passwords such as ‘photo bros nan plain’ and ’embarrass debating gaskell jennie’. This produced the results you would expect from a webcomic. The best ‘alternative’ result was found when creating poetry: passwords like “Sophisticated potentates / misrepresenting Emirates” and “The supervisor notified / the transportation nationwide” produced a 60-bit password that was at least as memorable as the xkcd method.

Image credit xkcd

97 thoughts on “A More Correct Horse Battery Staple

          1. The mooltipass is huge: it’s like an oversized box of playing cards. It makes it inconvenient to carry it around, so it really only works as a password manager if you are willing to carry that much crap around with you at all times. The response they gave regarding the size of the mooltipass was that there’s a tradeoff between size and usability, but I personally find it pretty useless at this size.

            You can kind of get the usecase they were optimizing for based on the fact that they sell a laser-cut stand for it. It’s basically meant to hold your usernames and passwords that you don’t “always” need with you. It’s meant to hold a whole bunch of usernames and passwords which you need in a specific place: your less commonly used passwords at work and at home.

            But the worst part for me is the software. There are a bunch of tiny decisions which drive me insane:
            1) Literally unusable unless you use Chrome (the browser). This makes it worthless for me. I literally have never put a password on my mooltipass because I don’t have, want, nor will I use Chrome (or Chromium or any of its derivatives)

            2) The physical interface you use to reprogram the device is the same as the physical interface you plug in to the computer you’re going to enter the password into. This means I cannot safely plug in a mooltipass into a computer I don’t trust, because there’s a chance it could exploit and reprogram my device

            2.5) It’s Arduino compatible. This is something I don’t want out of my secure device. It means that reprogramming it is “easy,” and it means there’s a whole new attack vector present in the device I don’t want to think about

            3) The computer can communicate down intent, meaning that when connected, independent of the Keyboard interface, there’s a separate USB channel which must be secured (or a normally open attack vector for malicious firmware). This one I understand the rationale behind it: it was really difficult to make a palatable UI experience on a tiny screen, so they made something which made the device easy to use

            All these decisions undermine everything I bought it for: I wanted something I could plug into my friend’s malware-laden machine and expose a *single* website’s password. I wanted something where I could carry around my passwords in my pocket and not have to worry about them getting lost, nor worry about leaving my encrypted passwords at rest on a big server somewhere. Mooltipass solves none of these problems because the implementation is terrible.

          2. Hello Kit,

            My replies follow:
            – today we will release our completely rewritten app to beta testers
            – we will also announce a cross platform compatible daemon for the mooltipass
            – Arduino compatibility has nothing to do with the lack of security.If the MCU was locked, nothing would prevent someone from tearing appart the Mooltipass and resoldering a new MCU.
            – I fail to understand why you can’t use the Mooltipass in the scenario you described… is the main problem the size?
            – please note that if you’re not happy with the mooltipass, we’ll be glad to offer you a refund

          3. Hey Mathieu,

            Glad to hear you’re still working on the software side of things! To reply to your reply:

            – Is the completely rewritten app still for Chrome? It unfortunately won’t much help me if it is.

            – Great! I was mostly disappointed when I received the device that I couldn’t interact with it at all. I didn’t appreciate that there wouldn’t even be a command line utility or something, it was jarring to have a piece of hardware which depended on Chrome

            – Well I would argue that there are different expectations based on the cost of an attack:
            – If it was easy to carry the mooltipass around, I would just assume that if it left me for a significant period of time it was/is compromised. Since this implementation encourages me to leave it with desktops, you’re correct that someone could swap out the MCU, though I still don’t consider that a concern, as that requires someone to be willing to target me personally (which I’m pretty confident I’m not important enough to warrant attacking)
            – If I was a malicious user, and I wanted to get a lot of passwords, I could distribute malware which identified and reprogrammed people’s mooltipass so that it had the same UI, but removed the confirmation for if it should transmit a given username and password. The UI is easy to emulate because the software is open source (not saying that open source is bad, just pointing out its utility in this specific context). Then I would just use the same path the chrome extension uses to request each username+password get dumped into a text file on the infected machine. Assuming that I already had a large botnet/deployed surface of hardware, and the mooltipass had taken off as a popular password manager, this seems pretty straightforward.

            – I’m not sure which scenario you’re referring to. There are three main deterrents to regular use of the mooltipass:
            1) The size – I am not motivated to carry it with me and thus I can’t keep any of my regularly used passwords on it because there’s a fair chance I won’t have a mooltipass + USB cable + smartcard on my person when I would need that password
            2) The reprogrammability – if the malware example I gave above was on a friend’s machine, I couldn’t safely plug in the mooltipass and know that the device was unaltered
            3) Host HID communication – because the mooltipass communicates with the machine directly and continuously, I have to trust that you guys have no exploitable holes in your USB HID implementation (no buffer overflows, accidentally incorrect error handling paths, etc). This is another big attack surface because you already have a parser and command interpretation section on the mooltipass which allows you to do just about anything (request passwords, status, initiate reprogramming). And if there was an exploitable hole in this part of the implementation, you could probably also dump the AES key from in memory. I was hoping that you would have the hardware implementation be a second IC which only communicated via UART to the IC which handled usernames/passwords/keys

            – Hmmm, maybe I should take you up on the refund. At least for one of the two devices I received. I guess I’m less disappointed at having spent the money and more disappointed that an idea that I loved didn’t work out the way that I’d hoped. The core principal I liked about the mooltipass is that it didn’t require me to trust anyone with my database of encrypted passwords. I don’t have to load the entire database of passwords onto every machine that I want to use to enter my passwords. I don’t have to put software on my friend’s computer to use the device.

            Thanks for taking the time to reply!

    1. That’s *awful.* If letters can’t repeat that dramatically reduces the amount of entropy. Shitty password rules make me angry, and no one likes an angry booby. >:C

      1. The only time i have seen that rule in action was when it would create an arbitrarily long password from a simple word. “loooooongsword’ or “AAAAAAAA” which wouldn’t have been very safe anyway. I’ve yet no see a site prevent you from using *any* repeated words, and i probably wouldnt use that site if i ever did.

    2. The worst I have ever seen was a site only allowing [A-Za-z1-9] and only eight characters.

      I don’t remember but I would not be surprised if it also was one of those sites which confirms your account by sending back the user name and plain text password.

      1. The Australian welfare system logins require no more and no less than 6 chars, A-Z, a-z and 1-9 only. It’s extremely worrying there, as being hacked can implicate you for fraud and/or leave you penniless.

      2. My previous bank had (for some unknown reason) a 10 character limit.

        My current bank has no such limit (if they have a limit its high enough that I haven’t noticed it) and in fact insists on both capital and lower case letters in the password.

    3. I actually won an argument with a director of IT at a former company about complex passwords, and got the policy changed. He had implemented some insane rules about passwords for the company. No dictionary words for any part of the password, must have #’s & Caps & Special Characters, no strings of two or more characters, no more than two characters next to each other on the keyboard, and the list went on and on. The result was 12 digit randomness. And that’s why I bet him he could pick up any 5 keyboards and find at least 2 passwords stuck to the bottom. He went 9 out of 10. Next week the policy was changed.

      As an aside, the shipping manager had the best solution to the complex password problem. He had a package scanner hooked up to his computer that acted like a keyboard. His “Password” was one of the many bar-code shipping labels on his desk wall. Truly hidden in plain site.

      1. My friend that works in a bank has told me a story about a customer’s pin. The customer has written his PIN on the wall, just above the ATM. One day the guys comes to the bank and asks for a new PIN because the wall has been repainted. I guess it’s pretty clever because noone knows what card the code on the wall is for.

    4. An application we had, had stupid users. They would type ‘*’ as the item to search for and the database would return a report with all the records. All of them. 2 hours of system crawling when the report got run. So the dweeb in the basement added a check to make sure an “*” wasn’t used, which really made searches tedious.

      The dweeb did not think to look for “**”, which worked for a fairly long time. And no, I wasn’t dumping the database into a report, just ordinary searches for docs, like “1223**” so I didn’t have to type 122341889-8990. Cripes.

  1. I have used random 10Words26Seperated2015By3Numbers! ending with punctuation for a long time. I usually randomly make the passwords from words and the date, time that is in my immediate vicinity, and 99% of the time end with . or ! They are trivial to remember. I also have a standard garbage password that has a standard sequence I add to meet requirements (eg. capitalization, number, punctuation). I have used this password and its 4 variations for approximately 17 years.

    My bad passwords are ones that have a high error rate (even as I type them ~50 times a day), I just flushed an awful one a few weeks ago (Putin07:43Alzheimer’s7Phone2) that I would mistype 20% of the time. I won’t use a colon again or an apostrophe or a word I can never spell.

  2. Good grief. I’ve wrote about this before. It’s really simple. You take a phrase that has about 8 words or so in it. You use the first letter of each word to make up the password. Like “I sure hate winter in Missouri so bad”. So it becomes IshwiMsb. Then if it allows more characters I can add a number to the end. I’ve had some that look like missile launch codes. The point is the phrase is easy to remember and the password contains nothing looked up in any dictionary and is cryptic.

    1. It doesn’t matter if the password contains dictionary words if it has as many of them as a regular password has characters. Even restricting yourself to very common words gives you thousands of options, compared to a few dozen typable characters. It’s That’s the whole point of battery staple.

    2. The thing is IshwiMsb is no easier to remember, but it is vastly easier to crack. By about 20 orders of magnitude.

      A word has as much entropy as a single character when comparing dictionary versus a brute force attack. A list of common words that a hacker would use has something like 10,000 words in it. That’s compared to 50 for lowercase and uppercase characters.

      (I * 50) * (s * 50) * (h * 50) * (w * 50) * (i * 50) * (M * 50) * (s * 50) * (b * 50) = 3.9e+13 guesses.
      I winter in Missouri so bad
      (I * 10000) * (sure * 10000) * (hate * 10000) * (winter * 10000) * (in * 10000) * (Missouri * 10000) * (so * 10000) * (bad * 10000) = 9.9e+31 guesses.

      That’s assuming that you use common words. If you replaced “Missouri” with something like “chaulmoogra” you are looking at needing the full english corpus to crack it. And that’s something like 1e+48 guesses to crack.

      1. You don’t remember the password here. You remember the phrase and arrive at the password when you need to type it in again.

        I just use the one as an example. A lot of times I use word numbers in the phrase so that the password has letters and numbers. I wasn’t trying to get into a mathematical discussion. The rest can show off their prowess on that and have fun.

        It’s a heck of a lot better than people using their pets names and familiar names for the password itself. That is far too common. lol

        1. Still, an 8 character password, however derived, is cracked by a Rainbow Table in a few seconds.

          It’s probably also relevant to this article that real word phrase passwords are akin to Brain Wallets which can be dictionary attacked.

        2. That sound you heard was the point flying right past you. You’ve done all the work to have a good password by remembering the long phrase, then you go out of your way to use a weak password. That was the takeaway here.

          1. That first part wasn’t really necessary. I was addressing the issue of how it’s remembered. I’m trying to learn here too. I am taking away what is said to improve.

  3. The problem is that well over 90% of all websites and services are so poorly coded that you cant do this.
    “My voice is my password, please verify me?” is more secure than QWERf43tv3 and 9000% easier to remember yet the bulk of websites out there are coded to 1996 standard and don’t allow spaces or passwords longer than 16 characters, etc..

        1. that makes it easy to hack now because the length of the password is known and you only need to use 8 spaces.

          of course as long as the bank does not lock down accounts then it is easy to guess using brute force.

          i suspect the bank is probably a pre paid credit card or gift card.

          1. Yes, that’s annoying. The mobile app for my bank defaults to an initial capital letter for the username so I have to hit shift twice to force it into a lowercase since their usernames are case sensitive.

        2. Wells Fargo is a crummy bank in my opinion. My bank is nice enough to use 2 factor auth. I get a SMS text message with the one time password valid for 5 minutes. If I need to enter user/pass again or if you login from any new device/ip it asks several verification questions to ensure your the right person.

          One thing I have noticed on some banking sites is that they redirect to HTTPS after you put in your user/pass, others use very poor SSL certs etc.

          Not all banks are created equal or care about security

        3. I remember an issue with Oracle 10g database. If the user machine was using Oracle 11g client the database was unable to deal with mixed case passwords. In the code we were supporting we had to do the same thing, convert the password to all the same case.
          Another fix would have been to upgrade the DB or downgrade the client machines, but our customer didn’t want to do either of these.
          I wonder if Wells Fargo have the same problem?

      1. My bank uses 6 letters and 4 digits for user name and a password that is 16-40 letters long. From that long password one must type only five letters selected at random. Three tries and they block account access for an hour. So for my password I used a title of a random book on my bookshelf.

  4. The reason you should not use only actual words strung together is because they might be cracked using wordlist attacks. I usually add a word that doesn’t exist (at least not in English) or a name. Since you know that only certain combinations are not possible and the passwords follow certain patters (i.e. the first letter in the password/each word capitalized, numbers at the end/between words etc) you can vastly reduce the search space needed and speed up your guessing algorithm. Also, the specific XKCD-password is probably one of the worst to use, since all guessing programs would have this specific password as something to try at first.
    For those of you interested in further reading, check this paper out: http://www.eurecom.fr/en/publication/4711/detail/monte-carlo-strength-evaluation-fast-and-reliable-password-checking. Very interesting an highly recommended.

    1. If the sequence of words is not grammatically correct or in some other way obviously sequential then you would supposedly need to run a dictionary/wordlist attack for each word. Say there’s a thousand words in the English language that are commonly used (obviously you could work around this by taking words not commonly used, but lets assume worst case) and your phrase contains at most 6 words (per the example in the article), then that means there’s roughly 1000^6 = 10^18 possibilities. Which isn’t too bad I would say.

      The tricky bit I think is that they use proper grammar and rhyming. Say you have some algorithm that generates grammatically correct sentences and figures out if they rhyme, suddenly you have a much more limited set of possibilities.

      Another thing I really worry about is that people will be silly enough to use famous quotes from movies/books/history, and all the cracker would need to do is download wikiquote and go.

  5. It is a huge pain trying to type in the 64 random characters WiFi password on a mobile device using on-screen keyboard that you have to switch alpha/numbers/symbols; lack of copy/paste across apps/storage;OS level security that only shows * while you type; lack of editing; scrolling entry; and in some cases without warning truncations.

    e.g. I think my Canon point and shoot camera limits that string to 32 characters or less. I took on average 5 tries to enter that on iOS with a Bluetooth keyboard.

      1. That’s why you get more then one try ;-)

        btw my wifi password was generated literally by keyboard bashing and yes it sucks to type it one by one into devices that lack copy-paste :D

  6. For online services, the implementation of password is a much larger issue. It makes very little difference for 1 in 100,000 or 10^34 password complexity if the service limits the rates of password retries and locks out the account after a limited number of unsuccessful attempts. It should also ignore the connection from that IP address whether it is related to the same account or not.

    There is often the issue of the web service not securing the entire account/password database from the internet. What good would the complexity of the password be if it can be crack offline using precomputed tables?.

    1. It does not even need to lockout the account, just increase the timeout between retries.

      And on a successful login notify the owner with a summary of the failed attempts, how many failed attempts, from which IP addresses at which times, and ask if they would like to block any of those IP addresses (with the ability to remove them from the blocked list at a later date, in case of human error [oops I blocked my mobile phone]).

      Of course if someone logs in with the correct password and changes it, they could block the account owner. So that is where you require a confirmation email(/SMS) to allow new IP addresses access but only upon a successful login.

    2. Which actually raises the point: wouldn’t it be better than, requiring the password to match exactly, you have it be “close enough”, and then reduce the number of retry attempts allowed? (Or be clever and not lock out the account if the guess is close).

      If you look in the paper, the passwords that humans didn’t remember were close to the original. They remembered a good amount of the entropy in the password, just not all of it. So you basically need something like ECC for passwords: you make sure there’s enough entropy so that random guessing is still crazy-unlikely, and then allow enough fuzz so that humans can remember easier. The goal isn’t to make it impossible to guess – it’s to make it easy to remember and impractical to guess.

      To be honest this could also increase the difficulty of offline cracking too, much like shadow passwords – if the heuristic used to effectively generate a comparison function was locally fuzzed (i.e. slightly different for each server), you wouldn’t have an easy way to offline-crack at all.

      1. That would not work because it is unlikely that the system even knows what the correct password is. Something as basic as MD5 hash of passwords makes the results totally different rather than off by 1 character. For example the hash of iamnotarobot:(aa11701496d2d57ceb97c59305910c04) vs Iamnotarobot:(eb5d1dbd400d223e3d2f7af9a7256403). No way to tell from that that they are off by only 1 cap letter.
        Also if you were able to implement this it would be providing hints to the cracker that it was getting closer/farther from the correct answer when the timeout or retry attempts value changed.

        1. “That would not work because it is unlikely that the system even knows what the correct password is.”

          Right, so you’d have to come up with an algorithm that broke down the input response into core elements, and then hash *that*.

          Is this easy? No, of course not. But we already do things like this. This is what voice recognition software does anyway – breaks down a complex input waveform into simple ASCII characters. Same deal.

          “it would be providing hints to the cracker that it was getting closer/farther from the correct answer when the timeout or retry attempts value changed.”

          Yes. So the key would be to make sure that the increase in the timeout/decrease in retry attempts outweighs any information gained.

          I mean, the only reason those ‘timeouts’/retry attempts before locking aren’t at maximum (e.g. wrong password -> you’re never allowed to try again from that IP) is because it would inconvenience the user a ton.

          If you fuzz the recognition so that the chance of an incorrect password is lower, then you can increase those times without actually practically affecting the user.

    3. Forcing complex password onto end users is only masking the problem of poor password database security. That’s one of the main issues these days. Once you get beyond the silly 4 numeric passwords limits, there are only so much you can crack with a limited failure attempts and no access to the database.

      If “fuzzy” password matching become popular, then it won’t be long that some of the poor implementation would put the actual password in the database instead of one or more hashes. There are far too many combinations of human fuzziness for remembering the password that it becomes impractical to store all the combinations in hash. Yes, you can come up with a hash that mimic that, but the hash would probably not do a good job of spreading out the password in the noise.

      1. “There are far too many combinations of human fuzziness for remembering the password that it becomes impractical to store all the combinations in hash.”

        I don’t think this is necessarily true. I mean, this is a social engineering problem – you find a way to characterize a sentence/phrase such that humans can remember it easily, and then you use those characteristics as the password. Then you hash those characteristics. Done.

        The stupidest (and totally not useful) example you can imagine would be what’s given above: take the first letter from each word in a phrase, and just store that (hashed) as the password. But if you want to be smarter, you get some natural-language parser, and ‘prune’ those outputs somehow, and hash that output.

        You could also use a fuzzy match as a 2-part password, where if, say, 90% of the elements of the phrase match, you provide a (user-supplied) hint. Yeah, stupid users might put the full password as the hint (although that’s trivially protectable) but the benefit there is that it uses a characteristic of human memory (associativity) that random password cracking does not.

        “Yes, you can come up with a hash that mimic that, but the hash would probably not do a good job of spreading out the password in the noise.”

        It doesn’t have to do a perfect job. It just has to do a better job than using a crappy short password. That’s actually a lot of the point of the XKCD comic: yes, using words hurts you because the cracker can use a wordlist. But random crackers are random – so you can just figure out how many words you need to equate to the random-character password. And the answer is ‘probably a lot less.’

  7. Why did I immediately think of having batteries on horses or horse powered batteries. (maybe manure)
    Then I thought hmm, wouldn’t it be great if horses had head lights. Sadly someone already invented that one.
    Although all be it not horse powered.

    1. If it ever gains popularity you can be sure credit card scammers will come up with sniffers they can use at the local coffee shop or airport terminal. Wireless just adds another attack vector so IMO, there should be a more compelling reason than convenience to use bluetooth.

  8. My question is, is someone out there really using a computer cluster to brute force my password to a third rate forum related to my unpopular hobby? Any serious service today blocks the account after few incorrect tries, making the complexity of any password above “password” or “1234” pretty much pointless…

    1. They pull down a database from a website of an unpopular hobby (small ones generally have low downtimes, i.e. software and OS is rarely patched), rip out the username, email addresses and encrypted passwords. feed the whole database into a wordlist generator. Feed the encoded passwords into a bruteforce/rainbowtable algorithm, that will start to kick out passwords immediately and leave it running for as long as is required. It is a exponentially decaying return on time invested. So it could be in the first 3 hours 60% of the plaintext passwords are returned, 9 hours later an additional 24%, 27 hours later 9.6% 81 hours later an additional 3.84% of the passwords are revealed…… It is not going to be exactly like that but that is the general pattern of diminishing returns over time.

      A large number of people use the same passwords everywhere, so the next step it to try and escalate the access to email, from there other passwords can generally be reset.

      The unpopular hobby sites are scanned for vulnerabilities en-mass, ultimately it is a numbers game (The phrase “nothing personal” comes to mind), and security if not improving over time is getting weaker.

    2. Looking at the logs from a sampling of the services I maintain for myself (a blog, a project management system, a web forum platform), I’d say the answer to your question is “Yes!” But don’t make the mistake of assuming one needs a lot of computing power to attack accounts on web-services. A dictionary of common passwords and an Internet connection is all you need. Basically any web-connected device can be used as a tool to gain access to accounts.

      Crackers also seem to traverse the search space a little differently, trying a certain common password on each account that they know exists, then moving on to the next most common password. On my services, where I am pretty much the only user, that won’t get them much, but that approach has worked successfully on GMail. My guess is botnets are used to spread the attack over many IP addresses, making it hard for the web services to rate-limit.

      When I managed a Google Apps domain with 3000 users we would get users reporting accounts being cracked every couple of months. In every case, the password they were using was very simple. What worried me was the accounts that were cracked, but the user never noticed.

    3. Sometimes you only need one. Many users use the same password or the cracker is going to use the info to generate a Trojan attack higher up.

      One of the famous ones never started with a computer – would just random call into a company, tell them he was from HR or IT and ask their user name and password – just to confirm they had it correct in the company record so their boss could access their work if they got sick or went on vacation, or for testing purposes, et al. Once he had a valid employee login, he worked his way into the system.

  9. I have seen this photo in many places, and it seems like it would work. The issues comes though when you have to remember what password goes with which site. As everyone (or most everyone) knows you should use a different password for every site. Yes, you can make a memorable password, but when it comes time to use it you have to remember which password goes with which site.

    1. The method I use makes this easy. Have a base password – say cat321butt – and add a two letter CAPS abbreviation of the website to it. For example, ebay might be cat123buttEB or gmailcould be catG123Mbutt, however you want to split it up.

  10. Something I have not seen mentioned in the comments so far is the not so subtle difference between someone brute forcing their way into your account from the outside versus someone having gotten access to a stolen or leaked password file (or worse).

    I am under the impression that the former is rarely an issue, unless you on the other side of the login for example would happen to have a large amount of money, information or control (for example to a sysadmin account on a site with the former two). Besides, as mentioned by for example tekkieneet and Truth above, trying to brute force into a single account is largely meaningless.

    What seem to be the issue for regular users is when a site have messed up and a password file (or worse) have been stolen and/or leaked, for example like what happened to Adobes customers a few years back. If you would happen to have a weak password (and this is not about how easy it is to guess, rather about statistics and algorithms) you can expect to have it broken within days or even hours. Would you happen to have for example credit card information available from the login…

    What I am (slowly) getting to is that the risk is not a random hacker pecking at random accounts, but rather the big holes from when a site have fouled up.

    There is two really great articles on password security on ArsTechnica:

    A really great Computerphile video discussing how to (and not to) store passwords is this one:

    Unfortunately, in the end you are in the mercy of the sites you have accounts on and can only do so much if they mess up completely.

      1. Yes, really. I once reviewed a peer’s work on our product. The peer had made their own authentication module and stored the passwords in plain text. I promptly replaced the authentication module with an industry-standard module, complete with hashes and salts. (In retrospect, I don’t recall checking the hash algorithm. It would have been just my luck if the module used SHA-1.)

  11. This is as always a very stupid idea as pass-phrase type authentication assumes that an attacker does not also know this (you never assume this) so that a supposed 60bit password is reduced back to 44bit if you know that it is a four word pass-phrase from a 2048 word dictionary.

    This is why the password as a means of authentication MUST DIE and be replaced with a much more secure first factor in a client based pseudonymous cryptographic zero knowledge proof. Then, whatever you use to authenticate yourself to the client with is not vulnerable to password brute forcing because it never leaves your control. see:-


    And perhaps at a later date


    1. After having looked at both those sites, I think I prefer the SQRL method over the FIDO method. Mainly because it means I don’t have to buy a new phone/device with a biometric scanner, or a secondary dongle. I can just use my current phone with a camera with SQRL.

  12. I have often think if instead of using password, we should look into asking the user to draw unfamiliarized foreign characters (or even cartoon animals) e.g. Chinese, Korean Hieroglif etc. Using the stroke sequence, vector (direction & length) instead of the final likeness for authentication.

      1. Add something not English (transcripts from languages that do not use a latin aplhabet are a nice start) and you’re golden ;-)

        btw whenever you are in a multi-lingual environment (with different keyboards), passwords with special characters become a problem :D

    1. If you aren’t using any spaces or uppercase, then it’s just a long string of letters, and with zero foreknowledge of anything about the password, the longer the better. Like the XKCD comic, correcthorsebatterystaple is far easier to remember and a stronger password than a shorter, totally random string that’s much harder to remember.

      If the password entry field is broken into four and the user can enter any string of any length into each block, that ought to be even harder to crack.

  13. My employee login requires me to have my cellphone by my side. I go online, enter password, and a random code is texted to my phone. I have about 30 seconds to enter that code. Is this type of ‘security’ getting to be more popular?

    1. Yes, It’s been available for facebook and online gaming for a while. You can even get a crypto-dongle from Blizzard to keep your WoW account save. Google has 2 factor verification available for their services as well.

  14. Hewlett Packard, on one of their tech support forums, has a password length requirement of 6 to 8 characters and IIRC requires at least 1 number. Thus I have to keep a note somewhere just for *that* password. One would think that a company whose major business involves secure network systems for major corporations would apply the same consideration for security to their own stuff…

    Yahoo apparently keeps some record of every password every user has ever used, so I have to have a unique one for my yahoo mail, but it’s one I can remember.

    I use a unique password for PayPal, ’cause $$$$$ and should someone crack the one I use for most forums they won’t be able to get my money.

    One of the worst and most annoying things many websites do is automatically move the typing cursor to the username field when the login page finishes loading. That is EXTREMELY insecure. Even on a fast connection I can often have my username entered and be typing my password in when *yoink* the cursor has been jerked to the username field and there I am, entering my password in the username field. That would be very bad in any place where shoulder surfing can be done.

    IMHO, Firefox and Chrome need a setting to completely block all ways of a site jerking the typing cursor around. It’s even worse when the web “master” who does a form thinks so highly of the page that it not only yanks the cursor to a default start position, it also clears any input that was made before the page finished loading. Ever been filling out a form, while some slow bit you don’t even see is taking a while to load, you’re almost done when *pow* it’s all wiped away?

    The first online password I used, back in 1996 (which I don’t use on anything now) was the first word that popped into my head at the time. dwarfs Not the Discworld use of dwarfs, the adjective, hadn’t read, let alone heard of the Discworld books back then.

  15. People who use the same password in lots of places have a habit that is several years out of date. Stop doing it. Once you wise up and use different passwords different places, you are no longer going to be able to use stapler horses or clever poetry because you won’t be able to remember more than a few. So, you will be using a password safe sooner or later. Once you make that leap, you might as well start using randomly generated passwords.

    I used to be like you. I got better.

  16. What really is annoying as all get out is password rules for sites I use once in a blue moon with inane policies like required password changes every (n) days or weeks ! Then the undecipherable captcha codes, some sites on bad captcha entry go the extra distance of stupidity by clearing the ENTIRE FORM, inconvenient and time consuming at best, pushing my blood pressure into the stratosphere when encountered on a site I am trying to access via a cell phone browser!
    The solution that I think to be secure, user friendly, portable and unaffected by time or frequency of logins would be as follows: go to the log in page of desired secure site enter your email, username, mailing address or some other memorable, public and generally considered unsecure identification. The site then sends you a 1 time code as a text or automated voice “robo call” to your cell or landline telephone number PREARRANGED at the time of registration. the code provided would be time sensitive, good for one use, and as a extra level of security a record of log in attempts whether successful or not would be sent to my email at some interval preferably determined by log in frequency, a special alert could be triggered by excessive attempted login tries.
    The login process would be:
    1.) USER ID’s with basic information and requests login authorization.
    2.) Website generates a one time use code alphabetic symbolic and numeric with enough characters to give reasonable security (could be longer than what most users now are willing to use as no memorization is needed)
    3.) on a second level login screen on site access is desired from the user enters the one time use time sensitive code.
    4. The site grants access, records the time date and where the request originated and based on usage rules or site policy sends the user a audit record of the recent logins / attempted logins.
    This system does away with post it notes with “secure” passwords stuck all over, lost or forgotten passwords, captcha codes and as it is basically a “call back” to a known number system it becomes a whole order of magnitude more secure method of accessing critical websites.

  17. I usually find diceware-generated passwords to be memorable enough, if I remember to practice writing them a few times. Though I still sue the password generator script I mentioned further up saved to cut down on the sheer number of them I need to keep track of for websites. With six words I can usually think of a way to interptet it that seems memorable. If I need a one much longer, I suppose I could try a recitation method used for vedic chants.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.