Common Security Failings

By Shamus
on Feb 17, 2015
Filed under:

I’m planning the column I’m going to write for the Escapist in a couple of weeks, and I’m looking to do a kind of public service-y kind of piece on how to judge the security of a website from the position of a user. If you play videogames then you most likely have a lot of accounts: MMO’s, gaming sites, DRM systems, etc. That’s a lot of data entrusted to a lot of idiots, and obviously it doesn’t always work out.

So I think it would be good to encourage a little more security-savvy among the masses. Normally I wouldn’t crowdsource my columns like this. I realize this probably comes off as rude and lazy. It’s my job to write stuff, not yours. But this is for a good cause and I’d rather beg for help than get it wrong on this topic. And I’m not confident enough in my knowledge to write this without some input and half-assed peer review.

I really want people to read this, so I want the list to be breezy and easy to digest. This is not a technical column. I might even make it a top N list. The whole point is to come up with things that should cause concern when a website does it. Here is what I have so far:

Security sins:

  1. Has visible data in the URL: or whatever.

    (I know Xbox had a problem with this, but I can’t remember how it worked. I’ll read up on this before I write the column, obviously.)

  2. Sites that limit password length. (Dude, do you even hash?)
  4. Sites that require uppercase, lowercase, a number, and a symbol in the password.
  5. Also: Are sites supposed to store the number that comes from the BACK of your credit card? I always thought that short number was so that it would be safe(ish) to store the CC# and Exp date on their site (so you don’t have to type it in every time) but still make it so that you need to enter SOMETHING to make a purchase happen. The security code is short so it can be entered even on a console or a phone without too much pain. But I see sites (including Steam) remember the security number along with everything else. Am I misunderstanding how this is supposed to work?

Anything you’d add to the list? Remember that I’m looking for ways that a typical user can spot bad security policies. “Has open ports on the server” might be a sign of trouble, but it’s not the kind of thing the average person can detect. (And even if you teach them, it’s not the kind of fooling around people want to do when creating an account. Also, probing for open ports is dangerous and not something I’d teach Joe and Jane Internet.) Likewise, while “Asks for too much personal information” is a sign that a breach would be more damaging, it doesn’t necessarily mean the system is inherently insecure.

So if we could just have a general discussion on horrible security policy, that would be great.

Also, this is my favorite security story. It’s not the most destructive (not even close) and it didn’t make headlines, but it is a glowing display of incompetence and stupidity. Tom Scott describes what happened at MoonPig:

Link (YouTube)

So… what are some major indicators of bad security policy?

Enjoyed this post? Please share!

A Hundred!A Hundred!12212 COMMENTS? What are you people talking about?!?

From the Archives:

  1. Jabrwock says:

    Credit card security code: is Steam storing it, or Chrome/Firefox?

    Even though it saves my login and card info, I’ve ALWAYS had to enter the card’s security code on any purchase on Steam.

    But yeah, I know a lot of other sites that do so. And while I can see why it would be convenient (“1-click purchase!”) it is still VERY open to abuse/hacking.

    And yes, it defeats the POINT of the number, which is to prove the purchaser has the card physically in hand and isn’t just skimming the card data from somewhere else. So storing it kind of breaks the whole security setup.

    Honestly, I’m disappointed at how little 2-factor there is for online purchases. There was a “verified by visa” setup that was supposed to stop skimmed data, requiring you to verify your purchase through Visa so they knew you were making the purchase and it wasn’t just a site accepting any old data through a form. But I haven’t seen that used in years. Maybe it was too complicated to integrate with shopping carts?

    • MartianAlien says:

      From what I remember (having done some work on software that interfaced with card reader hardware), the CVV code isn’t included on the magnetic stripe on the card, so the intent is to show that you have the card and not just have the data skimmed from it.

      I think the Verified by Visa step incurred extra fees for the merchant, so not all of them used it. (I don’t use a Visa card online, so I haven’t seen that step in a long time anyway.)

    • Mechaninja says:

      I liked the idea of the “verified by visa” thing, but the implementation was pure giraffe excrement.

      I think I’ve had to enter my security code for some Steam purchases but not for all. I am not certain of this, and about 2/3 of my Steam games in the last couple years are Humble purchases. I always purchase Steam games in the client, not in my browser.

      • Tizzy says:

        I remember verified by visa as a major inconvenience. Also, in my experience, if your browser’s settings and add-ons are on the paranoid side of things, which you tend to have when security is a concern, you can outright break some of these authentication schemes, because of redirects and the likes, so that even manual override does not allow you to go through.

        • Jonathan says:

          Yep. I actually dropped my Visa card because they wouldn’t disable “Verified by Visa” for me. That was about 8 years ago, and Visa hasn’t gotten any business since then from me.

      • For Steam, I only use their browser thing to buy games and I think it asks if the sale’s above a certain amount. Since I only tend to get games during the big sales, they don’t ask much.
        It also seems to vary depending on the card I use. My debit account card gets checked every time (which I applaud, btw), my credit card not as often.

        That reminds me, I need to call my credit union and have a conversation with them about allowing me to buy yarn at my local yarn store. I’m hoping if I give them advance notice, it won’t be rejected (slightly overzealous fraud prevention).

        • Kand says:

          From my personal experience, buying games directly in the Steam client, it asks for the CVV when:
          1. My last purchase was quite a while ago.
          2. The purchase costs “large” amount. I have no fixed numbers here but for example,he wont ask for a 10€ title but maybe for a 50€ one, though this will be balanced with point 1, so if I did buy a 10€ title and he asked me for the CVV then, if I get a 50€ title directly afterwards Steam wont ask again.
          3. I accessed the account from a different machine/ISP since the last purchase. Here Steam doesn’t care about 1. or 2. and will ask every time, even if the machine in question is “approved” in Steam Guard and I’ve only recently purchased another game on a differnt machine (even if the other machine is connecting via the same internet connection).

      • Isn’t that system kind of fudge-able by using a Visa gift card? I seem to recall seeing someone claim that the gift card numbers are treated like CC numbers. The upside (for you) being that if the number is ever compromised, it’s not your actual CC number being stolen.

      • Zak McKracken says:

        I like the thing itself, and there’s a lot of useful stuff in it but…


        As a result I could not use something I can remember (and compensate for that by making it much longer) but had to shorten somehow, then I forgot it, then the account was blocked, and then I realized that the restoring function was broken…

    • neothoron says:

      I work at a bank’s information systems (in France), but it is pretty clear: the PCI-DSS (Payment Card Industry Data Security Standard) standard mandates that the CVV must be discarded, it can only be entered by the client. So it is a pretty egregious violation.

      However, the line is murkier if it is the browser that is doing the retention and auto-completing the fields (however, I think there is a HTML attribute that prevents that)

      • Zak McKracken says:

        For my understanding: What’s the CVV good for?
        I always assumed it’s a kind of checksum for the rest of the data on the card. So if you have the bank’s key, you could compute it, and thus verify if someone who claims to have a credit card just gave you valid data or not.

        • Peter H. Coffin says:

          Isn’t, at least on American Express accounts, where the CVV is printed on the base plastic cardstock just like the issuer’s logos. I find it not credible that AMEX would keep around 10,000 different blank cards to accommodate whatever the checksumming comes up. As far as I know, it’s just a number that the card issuer knows, that is on the physical card, and isn’t contained in the machine-readable data.

      • Peter H. Coffin says:

        I wonder how discarding the CVV works with recurring payments, such as service subscriptions.

    • Kriellya says:

      So, here is my understanding about how the online credit card ‘saving’ with CVV’s *might* work. I’m not saying this is how they do work, I’ve never worked with or seen any of the code implemented, but this is one way it can be ‘safe’.

      The basic idea is that you don’t store the CVV. In fact, you don’t even store the full credit card number! This might sound very weird, but it’s because the credit card number isn’t what is relevant to the vendor after the first transaction. The ‘token’ is.

      So, what’s the token? The token is a number the banks generate for a vendor. The first time a vendor goes to do a transaction with a particular credit card, they ‘contact’ the bank with the number, expire date, and CVV. The bank checks the card, approves it, and sends back a token based on the card and the vendor. This token can then be stored by the vendor for repeat transactions. It doesn’t ‘contain’ the credit card number or the CVV, and it can only be used by *that* vendor to make a transaction. In the future, instead of asking the customer for the full info, the company simply sends the stored token. The bank then verifies that the token is valid and approves the transaction.

      Usually, for the purposes of verification by the customer of which card is used, the vendor will save the last 4 digits and the expire date as well. If the vendor can tell the customer any more information than this about the saved card, it’s probably a bad sign, if not outright disallowed.

    • ztdgz says:

      PCI DSS requires that the CVV not be stored after the first transaction.

      If you’re giving a website your credit card details, check that they claim they are PCI DSS compliant. The most you can do is look for their claim, as PCI DSS is self audited in almost all cases.

      The claim of compliance implies several strong security standards are applied.

      Any website which displays forms on a page that is not HTTPS secured poses a security risk – EVEN IF the form posts to an SSL secured destination.
      Why? Because:
      1. A form that is delivered over clear text HTTP protocol is subject to man-in-the-middle attacks. The form could be modified to include javascript that posts the form data to a malicious server before the form posts to the desired HTTPS secure server.
      2. Any details included in the form delivered from the server are subject to clear text abuse; eg, the email address is helpfully pre-filled by the host, etc.

      If the SSL certificate validation by the browser results in anything less than “a green lock” it implies the SSL implementation is potentially flawed and subject to abuse.
      Not necessarily a sign to run for the hills, but it’s worth being cautious.

    • Sord says:

      I do not think steam is storing your CCV, and unless it is auto-populating, neither is chrome/firefox. I’ve written code that interacts with payment processors and a CCV is not strictly required to process a credit card charge.

      The CCV is provided for the merchant’s benefit, as a way to reduce fraud. If someone steals your credit card info and buys something on steam, you can report it to your credit card company and the result will be that steam won’t get any money from the transaction. So steam asks for a CCV when they want you to prove you are you, but might skip it if they are 100% sure or the amount is trivial.

  2. Khizan says:

    http:// as opposed to https://

    They should be using https for personal information, and looking for the ‘s’ is easy enough for anybody to do, even if they don’t know what it means.

    • shiroax says:

      What does it mean?

      • Mechaninja says:

        http: hypertext transfer protocol
        https: hypertext transfer protocol secure

        HTTPS means that the connection between your computer and their server is encrypted, whereas HTTP is sent in plain text that anyone with a sniffer could read.

      • Tizzy says:

        Browsers usually represent this with some form of lock icon by the address bar.

        • nm says:

          This, plus looking for the little lock icon in your browser. Chrome is phasing out support for some older SSL related stuff, and the fact that a site uses https does not guarantee much without short lifetime certs and a whole bunch of other stuff you don’t want users to deal with. Thus the little lock icon.

        • Primogenitor says:

          But in-game browser-like interfaces (e.g. store) may not.

    • Also, even non-tech savvy folks should be able to throw a link into an SSL testing site. The detailed output doesn’t matter.

      If the test has a too low score*, chances are they know that they SHOULD encrypt, but don’t really know HOW or WHY.

      *On smaller sites, they often have self-signed certificates because of money reasons. The checker I linked above is taking that into account, offering two scores.

      I’d rather trust someone with a self-signed, if everything else is OK than one with a LOLMONEY certificate that still employs SSL2/3. Best to not trust either unless you know who they are, though.

      • DrMcCoy says:

        The whole certificate situation is rather broken at the moment, though. Something that Let’s Encrypt will hopefully fix in the near future.

        • nm says:

          I’m so looking forward to that project getting usable in production environments. I’ve had a tab open to their page since I found out about them, just waiting for the right time to pull the trigger for my own site.

        • Oh yeah, the web of trust/ssl thing is completely broken by virtue of being monetized. But a little security is better than no security, as long as you keep in mind that nothing will guarantee absolue security and as long as you know that there are drawbacks, like always in the security vs. freedom debate.

          As for how ridiculous SSL has become, I refer to this bugreport over at mozilla. Hilarious read if youn know at least the fundamentals of the SSL web of trust infrastructure.

          Short addendum and disclaimer for anyone who clicks over to my site from the link in my commenters name and tries https: I have self-signed certificates for a numebr of reasons, including but not limited to the belief that a 25-second procerude that my computer does all on it’s own and is beneficial to the internet as a whole (creating a certificate) shouldn’t cost more than a few bucks.

          See the link in the comment from DrMcCoy below me.

      • Short addendum and disclaimer for anyone who clicks over to my site and tries https: I have self-signed certificates for a numebr of reasons, including but not limited to the belief that a 25-second procerude that my computer does all on it’s own and is beneficial to the internet as a whole (creating a certificate) shouldn’t cost more than a few bucks.

        See the link in the comment from DrMcCoy below me.

    • Felblood says:

      This one is absolutely easy to understand.

      When trying to explain to elderly, computer illiterate customers why entering their card data into the company website is considered safer than just reading their card number into their cell phone, this is the first example I turn to.

    • The Schwarz says:

      Here’s an easy rule that can save a lot of grief.
      Whenever you enter personal information (most importantly passwords or credit card info), look at the browser’s address bar and make sure that:
      1. It says https.
      2. The URL is actually what you think it should be. (Phishing is still a thing!)
      3. There’s a lock icon and/or the company name next to the URL. All sensible modern browsers have this in some form or another for valid SSL connections.

      • Felblood says:

        It is not safe to assume my customers are capable of spelling my URL or are using a sensible, modern browser.

        Windows 95 is still a thing.

        • The Schwarz says:

          What do you mean, “your customers”? We’re talking about security tips for people reading Shamus’ column.

          • Felblood says:

            Basically, I am just demonstrating the methodology used to acquire my data

            While demographically speaking, my customers tend to be older ladies, they encompass a broad swath of the computer-illiterate laypeople.

            It’s not a huge sample, but they are statistically significant.

            My customers and the escapists customers are unlikely to overlap directly, but I’m banking on similar levels of ignorance.

  3. Strange confirmation emails and having to set a password on account creation:
    If you don’t get an email with a timed, one-time activation link (T.O.T.A.L. from now on. Nice acronym. And yes, you may coopt this in the column if you so choose :D ) to confirm your account creation and to set your password, the site’s iffy.

    If you recover your password and don’t get a T.O.T.A.L., but instead get a generated password or, even worse, your password sent in plain text, the site’s more than iffy.

    Data sparsity:
    Try to think about which data you would need to save to offer the service in question. Now add maybe 25% more data to account for stuff that you as a layperson don’t know about. Does the site registration need more than that? Get out ASAP. People who grab everything they can, and not only the stuff they must are not to be trusted.

    Do you have to unmark a lot of “Want to receive $additional_offer?” checkboxes instead of marking them? Chances are they bank on people overlooking those boxes and they want to push something you don’t want onto the customers.

    Forgot something:
    Double-checking passwords:
    You don’t get a “Enter password to confirm” box, they’re likely either thinking that
    a) they can recover your password easily should they need to (no hashes or somesuch) or
    b) you’ll never log in anyways apart from that first time, so it doesn’t matter if you mistype, in which case you should ask yourself “why am I being force to make an account in the first place?”

    Same password two times:
    They know the hash/salt combo for your last password when you reset it. They can check against that trivially. If they don’t, it’s because they don’t want to, in which case the question should be “why”, and whenever I have to ask myself that, I get a bad feeling.

    While not all of these are indicative of the ACTUAL security of a site/service, they are highly indicative of the mindset behind it.

    Also, seconding https here. SSL certs are cheap for companies. Like 500 Bucks for 2 years at GeoTrust. They don’t have one for all their sites, they don’t know what they’re doing.

    • Mechaninja says:

      I like these.

      The comment about mindset is on point. Some of the stuff other people have posted dovetails into it nicely as well.

    • Tizzy says:

      So often, the creepy feeling is not as much “these guys are evil” but “these guys have no idea what they’re doing”. The latter is probably even more dangerous to your data’s safety.

      I love all of your suggestions. They really allow to test well that particular risk.

    • Joe Informatico says:

      Data sparsity:

      Would this include sites requiring you to set up an account, that ask you for an email address, but also want you to submit a username to log in with?

      I sort of understand why a storefront like Steam, that also has user forums you might want to exercise anonymity on would have usernames. But why does my goddamned gas company’s website, where I only want to be able to check my account status now and then, require me to come up with a username, put all kinds of stupid restrictions on what that name can be (so I can’t just use one of my normal online handles), and then remember what that name is every time I want to look at my account?

      This is probably more of a customer usability/frustration issue than a security one, but it still annoys me.

      Great additions, btw.

      • Tizzy says:

        Maybe they want to allow you to change your email address eventually and still keep track of who you are? Not a great way to do it, but it could be that.

        • Peter H. Coffin says:

          Give the poster a bubblegum cigar.

          They’re setting up the primary customer key, and exposing it to you so that you can have a remote chance of being able to parrot it back to them in the case that something goes horribly wrong. It’s questionable whether that’s better or worse than a meaningless INTEGER in the vast scheme of things, but it DOES mean it’s easier to make sure that the URL you’re looking at doesn’t have your key in it, as Shamus talked about.

      • Khizan says:

        The email address as a login can be problematic if their database isn’t set up to allow easy changing of usernames, and not all databases are.

        This is because you can’t depend on people keeping the same email address forever, and you want to ensure that they can always update their contact information.

        This is not necessarily bad practice.

    • “Same password two times” or “Changing a password to the same password”

      Sometimes I forget the password I used on somesite (since I rarely visit it), the Reset password link may be there, I may still wish to use the same password there (I just forgot it was a particular one).
      It should not prevent me from doing so, notifying me about it would be fine though.

      Also it may not be possible to compare old (current) password against a new and see if they are the same, if the hashing method has changed (been upgraded) then the hashes can not be compared.
      They could re-hash the password using both new and old method and compare but then again, ideally a site should never need your plaintext password, a HMAC passed from the browser to the server would be ideal, and in that case the server can’t compare the old/new password for similarity (due to the random salt).

      • Decius says:

        If the site stores the hash of all of your previous passwords, it opens a wider window against people who reuse passwords across sites that have stupid password policies, like requiring that passwords change.

      • Getting home slightly tipsy, so excuse me if this may sound incoherent:

        If the site tests your new pass against the old one and notifies you along the lines of “same password”, you can always just wait the 24 hours or whathaveyou before using th eold one again. Better than allowing you to consciently (if that’s a word) using the same pass twice by virtue of setting a new one.

        […]If the site stores the hash of all of your previous passwords[…]
        Not needed. The last few passwords would be more than enough, and even storing the hash of the last (single) pass would be enough in my book, since that at least demonstrates that they put a bit of thought into the procedure. Paranoid password policies are as bad as lenient ones, since both teach bad behaviour to the user.

    • Timelady says:

      So many government/state/employment things that I’ve applied for in the past few years hit so many of these and the OP guidelines that it’s fucking terrifying.

  4. Alan says:

    Hey, a thing I know about! I had to take the Payment Card Industry Data Security Standards training because I manage a conference that takes credit card payments. My view is limited (my institution avoids certain challenges by flat out rejecting some options), my training old, and I’m far too lazy to re-read the documentation, but from memory:

    The PCI DSS is the new(ish) standard created after it became clear that mass credit card number theft was A Big Deal. Lots of once valid behavior was banned, and a lots of mandatory training and testing was put into place. If you violate the DSS the penalties are monstrous. Quick grabbing the notes, it looks like simply breaking the rules, even if no data is lost, will run you a bare minimum of $50,000 and could easily run much, much more. My institution (a major university) has decided that if there is an actual breach that it will be more cost effective to stop taking credit cards for a few years.

    Saving the full credit card number is Not Good, but allowed for exactly the reason you mention. If you fuck it up things are going to go very badly for you very fast.

    The number on the back of your card (front for AmEx) is variously the CVV, CVC, or CV2. I don’t believe you are ever allowed to store it. But, you don’t actually need it to run a charge. But, if it’s not present resulting transactions aren’t quite as well trusted. Chargebacks will be easier. As Jabrwock mentions, perhaps your web browser is saving the number?

    • Richard says:

      Storing the CVV is absolutely, positively and definitely not permitted.

      It is to be used for the one transaction and then it must be deleted.

      Any merchant that stores it is breaching the terms of their payment processor and definitely not safe!

    • HeroOfHyla says:

      “But, if it’s not present resulting transactions aren’t quite as well trusted. Chargebacks will be easier. ”

      So that’s how it works? I used to work for a Comcast call center, creating accounts for new customers, and we never even asked for the number on the back of the card. A lot of customers seemed to find that suspicious.

      • “I used to work for a Comcast call center”
        You have my condolences.

      • Mechaninja says:

        Well, that’s a perfect example, right? No one should trust Comcast any further than they can throw one of their trucks.

      • Alan says:

        I’m less confident in the “chargebacks are easier.” At my institution we always get the CVV and never store the credit card number with the specific goal to simplify things. It may not be that chargebacks are easier, but that they become more expected and the merchant provider demands a higher cut to deal with it. (Then they just pass all of the chargebacks on to you anyway. Wheee!)

      • HiEv says:

        Well, Comcast is a big company, so they’re not likely to perpetrate credit card fraud, unlike some little fly-by-night company. Second of all, if you’re setting up auto-pay and you’re not allowed to store the CVV, then there’s no need to ask for it since it isn’t doing anything with the card immediately.

        I have no idea if they had/have to go through any extra measures or anything to skip asking for the CVV on payments, but I know that (for businesses) paying with an agent on the phone is an additional $5.99, or through the automated voice system it’s an additional $2.99. There’s no charge if you pay online, though I don’t know if the online system asks for the CVV or not.

        (Yes, I work for Comcast Business tech support.)

        • Mephane says:

          Well, Comcast is a big company, so they’re not likely to perpetrate credit card fraud, unlike some little fly-by-night company.

          I don’t think anyone here would expect a big, well-established company to use the data for fraud. Malice is rarely even the cause for security risks, but incompetence and/or laziness.

          No, the problem is if they get hacked and someone else gets their hands on the database, how much use it is for them. THEN it does matter whether the hacker has that number, whether they just got your password in clear text etc.

  5. boz says:

    For low security (forums etc.), Login pages without captcha/timeout protection
    For high security (banks), Lack of two factor authentication.

    • Tektotherriggen says:

      Timeouts can be tremendously annoying. How do they help security?

      • Soylent Dave says:

        Timeouts are a security thing for public computers (internet cafés (are they still a thing?), university etc.).

        I can’t actually imagine logging into anything important at a public computer, but the timeout is there so that if someone does, then forgets to log out, the next user to come along doesn’t e.g. have access to their bank account.

        • guy says:

          Yeah, the main reason is for shared computers, and it’s worth noting many people don’t have private computers with internet access, and quite a few have family computers and teenagers.

          It also means that your browser will not keep adding more and more tiny files to your temporary storage forever.

          • Decius says:

            I know at least one website ( that has forums and other low-risk stuff integrated with watermarked .pdf downloads (piracy of which is taken seriously), saved payment details, address changes, and other high-risk stuff.

            You stay logged in to the low-risk stuff indefinitely, but if you try to access your account or buy something, you have to reauthenticate.

  6. Mechaninja says:


    My brother used the same password for his gmail, his WoW account, his bank website, his … I forget where else.

    This was during Wrath of the Lich King, so a couple of years ago. He quit WoW, but gave me his account. I was playing one of his characters, and got a whisper from a gold seller, something like “can I offer you any services today” and I told them to expurgate off, because I am happy to cheat by using his characters, but purchasing unsanctioned gold is a bridge too far, sir! A bridge too far!

    Oh, right. The other place he used that same password? THE GOLD SELLERS WEBSITE.

    Apparently me expurgating at them irritated someone, because the next day while I was playing on my own account, someone logged into his account, one character after the other. I went to his gmail and reset his password and … it got reset again. I reset his gmail password, then reset his WoW password again, then logged into his WoW account and then called Blizzard’s customer support line, and then called my brother.

    A cheap lesson in the end. I was able to save everything, and he went through and changed all of his passwords. I guess it is good that the gold seller didn’t know what bank he was with …

    EDIT: I guess this is really more about own best practices, not the website of the services in question, sorry. I got carried away.

    • Thomas says:

      I tier my passwords. I’ve got a cheap one that I reuse on everything I don’t actually care about, but important things (and things that give people access to even more things like Hotmail or Facebook) get unique hard passwords.

      • I do that too, and use keywords to help me remember. So my lotro password is based (in my own little private dictionary-proof search way) on a particular word that I associate with lotro that isn’t obvious to anyone else (I asked all my friends to guess what word, no one got it). Same thing for any other online games, steam, amazon, ect. And then I have a physical hint book where I’ll write reminders that I do my best to make cryptic to anyone but me (and if I’ve lost physical security of my book, I’ve lost my computer’s physical security too and then I’m just screwed).
        My mother has a book she keeps all her accounts and passwords in, sadly, but at least she never lets it leave the house (and we’re the only two in the house), and given that she’s in her late 70s there’s only so much I can do. (Plus, it will make it easier on that hopefully very far off day when I need to access those accounts)

        • parkenf says:

          I think it was xkcd that pointed out we are actually very good at keeping little bits of paper (or secret books) secure, yet no good at keeping stored data secure. I’m with your mother on this one, up to a point.

          • Felblood says:

            I’m with you up to a point.

            Innocuous book of passwords in a drawer in your desk at home = probably fine.

            Critical password taped to your monitor in a publicly accessible office space = very bad.

    • DrMcCoy says:

      If people argue that they can’t remember hundreds of unique passwords, tell them about password managers.

      • nm says:

        This. You’re better off keeping all your passwords in a text file on your computer (yes, really) than using the same password for everything. I know the column is supposed to be on how to judge the security of X web site, but you know what? Nobody cares how secure the web site is. I’ve got accounts on sites that have been breached. I’ve even got accounts on sites that haven’t been (publicly) breached but I’m pretty sure they store all my information in an unencrypted excel spreadsheet. Why do I keep these accounts? Because I want to use their services.

        Telling people that the web sites they use are insecure might make them feel a little bad when they log in. The only thing that keeps me from feeling bad when I use sites I know to be insecure is the fact that each one has its own dedicated password. Well, that and I never let sites remember my credit card information.

        The solution to the problem of bad security awareness is not “don’t shop there” or “don’t post on that forum.” It’s “use unique passwords.” If writing down all your passwords on a piece of paper is too difficult, at least use one password for all the sites that don’t have any financial information about you and a different one for each one that does (and your email…primary email accounts need to have strong unique passwords.)

        If your goal is to point and laugh at sites with terrible security, on the other hand, point people to

      • *nod nod nod*

        I’ve taken a liking to KeePass I’ve tried a few managers and I liked this one the best.

        I pondered online ones but I found that just another thing that can go wrong, and if that online password manager site is down I can’t login anywhere.

        Also, if you don’t want/need a password manager but use just a .txt file then consider using a Zip or other archiving program that allows you to use a password to encrypt the archive.
        This is basically a poor mans password manager, then again KeePass is free (and open source) so cost isn’t an issue there either.
        7-zip lets you encrypt a zip archive etc. and it’s free.

        • Something like SympleID is a good point between keepass and fully cloud solutions. Basically, the passwords are all stored on your phone, but there is a browser plugin that let’s them communicate. When you go to a sitr you have credentials stored for, you have an NFC tag that you tap your phone to that unlocks it.

      • Zak McKracken says:

        For some passwords of lesser importance and low usage frequency, I have them written down on paper, which is way safer than having them on your computer or worse online. The problem I have with password managers is that they allow me to completely forget my passwords and never see them again. Then if my hard drive fails or the thing breaks in another way, they’re gone for good…

        • Jexter says:

          The solution is to backup the password database file, just like any other important file. Assuming you’re using a password manager with a properly long master password it is encrypted to the point that someone getting a hold of it doesn’t matter. So storing it in something like Dropbox works.

          This way, you only have to remember two passwords: the master password for the database and the password for the online backup. Of course, you want to be really sure you never forget those two passwords. For this, I personally recommend storing them in a secret vault, or tattooing them in memorized symbolic code on your person. (Any resemblance to the methods of the Illuminati are purely coincidental.)

  7. David says:

    I went on a kick of changing my passwords everywhere to 40+ character line noise monstrosities a year or two ago, which got me lots of exposure to sites that have a length limit on passwords.

    Shockingly, Steam is one. It caps somewhere around 30 characters as I recall.

    • Mechaninja says:

      I’m not actually offended by a 30 character cap. It isn’t ideal, but at least it isn’t short.

      Something I was helping someone with recently had like a 12 character cap, and the person I was helping couldn’t figure out why I started frothing at the mouth.

      • Joe Informatico says:

        One of my credit cards’ website still only accepts 8 characters. Insanity. Another one seems to allow at least 16, but you better not have one longer than 8 if you want to use their Android app, because the password field won’t accept more than 8 characters. I actually informed them of this limitation and they seemed grateful, but two updates later it was still an issue. I decided mobile banking was probably not a good thing to be doing anyway, and just removed the app.

        • nm says:

          I’ve written long math-filled emails to at least 3 financial institutions about their password limits. The thing that really bothers me is when they limit the character set to 36. 36^8 is 2,821,109,907,456. That sounds like a big number (2.8 trillion is actually a pretty big number) but consider that GPU-assisted crackers can get into the hundreds of billions (!) of hashes per second and suddenly your totally random password has been cracked before the coffee’s done brewing.

          Anyway, I’m no longer the customer of one of those. The other two have (shockingly) improved their practices.

          • Rymdsmurfen says:

            They can only make “billions” of attempts per second if they have direct access to the system, in which case the security has already been breached.

            • guy says:

              The main reason to hash them in the first place is that someone might steal the database of stored passwords.

              However, how do you get 36^8? That’s fewer than just upper+lower case letters! If they are case-insensitive, there are bigger problems at hand than the length limit.

              • Rymdsmurfen says:

                I know. But since they have access to the system they already have all sensitive information from that site. So cracking your password will give them nothing more, unless you used that password on another site. But if you do something careless like that, it makes little sense to complain about the password’s available character set.

                • guy says:

                  Well, firstly no they don’t have access to all the sensitive information from that site. There are lots of ways to break security and many of them will only get them access to some data, so actually pretty often people snag password tables but not stored credit card information. Secondly, people do reuse passwords. The quality of the hash and size of the input space is what determines whether using the hashed passwords from one site to break into other sites is trivial or virtually impossible. For instance, if the limit were 30 and both upper and lower case letters and numbers were permitted, there would be 62^30 = 5.9122213e+53 possible passwords.

                  • Rymdsmurfen says:

                    I guess it would be possible that the attacker could get their hands on the user name/hash/salt without having access to the entire database. If that is “often” the case I’m not so sure of though. And I don’t think that’s the scenario the “op” imagined.

                    (Actually it would be over 6e+53, since you could also have 29, 28, etc long passwords.) However, 36^30 is also a ridiculously huge number. So the idea that a 36-character set alone would compromise security is not true.

                    • Zak McKracken says:

                      From what I gather, most sensible set-ups have the password hashes stored on the login server but credit card data etc. in a different database that is harder to get to. Attacking the gateway will be easier to do than the back-end (well, as long as you’re not working at the company…)

                      Also, if they’re smart, they’ll encrypt the private data with something that is way harder to crack than guessing an average user’s password.

                    • guy says:

                      Certainly, I have heard people announcing that the password database was compromised but credit card data was not with reasonable frequency and have never heard of it happening the other way around.

            • nm says:

              Password databases are for stealing. Just assume that yours will be stolen at some point and you’ll have a happier life. If companies like LinkedIn and Gawker and Sony can’t keep them secret forever, you probably can’t either. (I’m pretending you’re a sysadmin here). Anyway, if we could guarantee that nobody would ever be able to get at our password databases, we could just store them in the clear. Of course, it only matters to users who reuse passwords (read: most of them).

          • ET says:

            You got it backwards, and mixed up bits with base 10 numbers: it’s 8 bits (one character) to the power of 36. Although even then, that’s assuming that the user can somehow enter all the whitespace characters, and stuff like the beep-/bell-code, which was never meant as a character for the human to use, just as something for the computers to use for output. Really more like 6 bits of keyboard-typeable characters to the power of 36…equals 1.05 * 10^65.

            • nm says:

              I’m pretty sure I didn’t get anything backwards or mix up my bases. I was assuming (this is from experience with a bank I fired) lowercase and numbers only (36) as the available character set and 8-character passwords. That’s 36^8 possible combinations. The reason long passwords are great is that the length of the password goes in the exponent. Of course, this matters way less if they’re using something sensible like bcrypt that’s hard to implement on GPUs instead of md5 which was never suited to password hashing but some people just have no clue.

      • Soylent Dave says:

        The worst one I’ve seen is the bank owned by the Chancellor of the Exchequer (i.e. the British Government).

        6-8 character limit. At least one number, one upper case, one lower case. At least one symbol from a list of eight symbols!

        It’s like they’re asking to be brute-forced.

      • krellen says:

        You should be offended by ANY character limit on a password, because if they cap the characters on your password, it means THEY DON’T HASH YOUR PASSWORD. The hash would be a fixed length, regardless of input.

        • Trix2000 says:

          Not to mention that the best passwords you can make are LONG. If you make a clever password that no-one could guess, then you just need to defend against automated systems… and the best way to do that is to make it take entirely too long for them to brute-force their way through.

          Most of my passwords are just very long made-up words… so I can easily remember them (I made them up a while back) but no one else would know them. And maybe stick some numbers at the end or something.

          • Bryan says:

            Correct Horse Battery Staple (…But don’t use that one in particular.)

            /usr/share/dict/words is about 100k entries long. Pick five items at random (the randomness is extremely important here!) out of that list for a password and you get a 1 in 10**25 chance of hitting it brute-force if the attacker knows the generation method. (Four words at random is a little too close for comfort for me.) The “billions per second” of attempts on a GPU still requires 10**13 seconds or so; that’s about 300K years.

            You can cut that down a bit if you assume the attacker has some way of replacing hardware in the middle of the brute force (which isn’t hard: grab GPU state, shut down, replace hardware, and restart in the middle), because the hardware is likely just going to keep getting faster. But I’m pretty sure it’s still linear, at least, so maybe cut the 300K years in half or so.

            • Thomas Adamson says:

              No no no!

              You have to use 1 capital, 1 lower-case, 1 numeric, and 1 special character. Oh and you only get 8 characters…..

              Because letting every idiot know that 2 characters of your passwords are from only ten of the ascii codes, and another two must be from 24 is such an awesome way of ensuring password diversity, not to mention memorisability.


            • nm says:

              Funny story: I did that: random password generator

              Of course, it’s http not https and you don’t know if I store all the passwords it generates on my web server so don’t use it.

    • Which isn’t TOO bad. 30 chars is 14 more than most sites and forums permit.
      But yeah, there’s no reason to limit password input, since it SHOULD get hashed, salted, peppered and slightly seasoned with nutmeg anyways and not stored in the backend database at all.

      But the problem with white noise passwords is always this: How do you remember them? I’m good at remembering stuff like that (comes with training. Sysadmins are used to stuff like that), but between my job and my personal life I have about 150 passwords I needed to remember. So into a keysafe it goes. And that one has a master password which can be cracked…

      Screw passwords, people, go for pubkey authentication wherever possible :)

      Of course, that would be silly for website authentication without https, and given the reinstall rate of the average windows system (or rather the belief that one should reinstall rather than fix, which has been ingrained by bad windows techies), one is likely to lose the corresponding private key, and that leads to major hassles down the line… But I digress…

      • David says:

        I feel that impractical-to-guess line noise passwords stored in a local password manager make a lot of sense in terms of the likely risks to one’s security.

        The likely security breach is that some site out there with poor practices will get hacked and then someone will know your username/email/password. They’ll then run around blindly trying that on other sites. Line noise immunizes you against that.

        Vastly less likely is someone hacking my local computer / phone to hunt for encrypted 1Password stores which they then take off and break into at their leisure.

        Between the two is using a standard password format, e.g. having your steam password be “nobody will ever guess my steam password”, and your amazon password be “nobody will ever guess my amazon password”. You’re similarly immune to automated password retries, but you’re trivially broken at the smallest amount of personal attention paid.

      • Felblood says:

        Unique, long line noise passwords are great in theory, but in the real world, they are not the best fit for mom and pop signing up for a mail order service.

        It’s better to encourage them to do things they can actually handle.

        Have them build longish pass phrases using at least one non-dictionary word, and maybe a symbol.

        RandAlThoris#TehSux isn’t the Fort Knox of passwords, but it will withstand several levels of scrutiny that SsapDrow1! will not. Even that is somehow missing from some of the dictionary attack lists I’ve read.

        • Rymdsmurfen says:

          Assuming that we’re talking about web sites/services authentication and not file encryption, brute force and dictionary attacks are not really useful tools for a hacker. A web service should not allow an arbitrary number of login attempt for single user or from a single ip. And even if it did, the web server would not be able to serve these requests fast enough to get to “SsapDrow1!” within our lifetime. Not reusing passwords on multiple sites is much more important than having silly long passwords with all the special characters.

          • Trix2000 says:

            You could easily use this method to generate a lot of passwords – if you mix and match them, you’ll have a lot of unpredictable variety (since they’re long) without having to reuse the same one twice.

            – thisisapasswordofmanycharacters
            – manycharactersmakeupthispassword
            – howmanycharactersareinthispassword

            Maybe stick some numbers on the end if they’re required or to add another variable.

            It’s not perfect (in theory, someone could figure out the method provided they get a password or two and experiment) but it’d be very difficult to crack and shouldn’t be too difficult for most people to remember if they set it up properly.

          • Zak McKracken says:

            The assumption is that someone gets hold of the seasoned passwords, isn’t it?

            Using the standard login screen, there is (afaik) always a dead time after entering a false one (even if it’s just the time the web server needs to tell you you were wrong), and most will lock up after three failed attempts or somesuch, so brute-forcing that way would be rather silly.

            • Felblood says:

              The assumption is that an authentication process that is a pain to use will be actively subverted by the very people it is intended to protect.

              e.g. If you set a standard issue clueless grandma up with a 32 character gibberish password, she will save it in her browser, where her outdated Explorer version, disabled virus scanner and general lack of windows updates will expose it to anyone who happens to come poking around looking for stray passwords. It doesn’t make the news when a private person’s computer is hacked, but it’s still a major way for data to leak onto the web.

              If I set her up with a passphrase that means something to her, like being related to her favorite book or TV series, she’ll remember it herself. I can safely select “No, Don’t ask me again” when I first log her in, and have no fear that she’ll proactively go looking for the option.

              Now this is a pretty extreme example, but the general principle still holds.

              EDIT: Another way of saying this is that we should try to make social engineering work for the good guys.

      • nm says:

        Or web site owners could stop being utter morons and use OAuth. But then they’d have to care, and we know from the number of sites that don’t allow apostrophes in their password fields that that’s a rarity.

        Fun story about apostrophes: Back when I used to work in IT, this one company switched to offsite administration for their Windows boxen and network. We onsite techs (2 of us) were there for cup holder and foot pedal type issues and the outsourced people handled all the upgrades and real administration work. Anyway, they had a web site for us to log into so we could request things and control some stuff. I had to come up with a password for this site, so I used some dice and ended up with a decent one with an apostrophe in it. Short version: they were storing it directly in the clear to an SQL database and I was unwittingly injecting SQL every time I tried to log in. Eventually I figured out that I could just enter the part up to the ‘, since that’s what was stored in their database.

      • Zak McKracken says:

        I always advise people to store their hashed, salted and seasoned-to-taste passwords in a cool, dry place, away from children and sunlight.

    • 30 characters is pretty bad as that limits you to a 15 byte (30 Hex) key or a 120 bit key.

      There is no reason why they can’t allow up to 1024 characters, my own systems allow this which means hex keys representing up to 512 bytes could be used, which is equivalent to 4096 bit key.

      I guess you could use Base64 but you might run into character limitations one some sites (A to Z, a to z, 0 to 9 and a few chars like ! and – only for example would choke on Base64).

      A password length limit is also silly in and of it self as nobody should be storing the password itself. Sites should only store a hash (preferably a HMAC of some sort).

      So the length is irrelevant. And if CPU/resource use is a worry then simply hash it in the browser/client instead, which is even more secure.

      • guy says:

        The point of the password length limit is to make users select a password they can actually remember instead of one that they write on a sticky note and post for everyone to see.

        • You are missing the point of password managers or browser password storage, thee usually have a master password and provide a easy or even semi-automated way to autofill the password field.
          This means you can have really complex/high entropy passwords.
          Very limited password fields prevent some of this benefit which is a shame.

          • Trix2000 says:

            The problem being that anyone who has the master password has the keys to the kingdom, so to speak.

            Which, granted, can be mostly prevented by making the master password as incredibly strong as possible. But all it might take is one keylogger and being really unlucky.

            It’s still a heck of a lot better system for managing passwords than most people have, though… and honestly I bet the number of times something like that gets broken into and utilized well is insignificant… if not non-existent. Soooooo, maybe there’s no problem here after all.

            • If there is a keylogger running on the user’s machine then they got bigger problems :)

            • Peter H. Coffin says:

              Very strong master password, with two factor authentication, is about as good as you’re going go get these days, that is at least USABLE.

              The problem is that there is a VERY DIFFERENT security model for people targeting the systems that you use (wholesale security in my brain) versus people targeting YOU and only incidentally the systems that you use (point security). And it’s pretty important to not mix those things up. Because if someone’s after you, and wants your passwords specifically, then there’s not a lot that you can do to protect you by yourself. You need other people to protect you. At minimum you need an entity other than you to pay your bills for you, so that none of that kind password management ever gets back to you and your stuff.

        • Zak McKracken says:

          …works exactly the other way round for me:

          If I need to make an 8-character password that is hard to crack, it will have to be mostly random characters: hard to remember. If it’s allowed to be longer, I can make something slightly more coherent (weird connections of syllables or somesuch — I try to avoid real words), thus with less entropy per character, but much longer and easier to remember because mostly pronounceable.

    • Vorpal Smilodon says:

      How do you remember dozens of 40 character random noise passwords?

  8. RTBones says:

    Bad grammar or spelling. If the website in question or the confirmation email you get on creating an account has bad grammar or spelling, you have something to watch. Even non-professional sites know what a spell-check is, and professional ones generally have copy editors.

    • BenD says:

      I would say, GOOD professional ones have copyeditors. BAD professional ones have copyeditors, or proofreaders, or friends who tell them their usage is wrong – but the site’s owner or manager refuses to change anything that they themselves “wrote.” The “I can do no wrong, and I am master in my domain” attitude is a mindset that is a red flag for many things, including identity and financial security.

  9. Rick says:

    Most payment gateways that integrate far enough to actually gave the user data entered on their site prohibit (by policy) you storing the data, but many still do. I’m not sure on the official way to do recurring payments or “remember my card”, I I haven’t needed it and smarter people than me have already commented on the subject.

    You’ve got some very good points above.

    I’m very passionate about security, but I’m caught coming up blank here. There’s not a lot that is laymen facing that I can think of.

    I’d also look for HTTPS when entering payment details.

    Avoid any sites that want your social media (or any account) credentials instead of wanting to be authorised via the APIs.

    Bonus points for account recovery options that aren’t just standard easy security questions or all for the last four digits of your card.

    I’m annoyed at how little I can help, sorry.

    • Tizzy says:

      “Avoid any sites that want your social media (or any account) credentials instead of wanting to be authorised via the APIs.”

      Do you mean sites that say “or log in using your ABC account.”? Why is that bad?

    • Nixitur says:

      Oh, that’s actually a good point.
      Avoid sites that only have security questions to recover your password. Avoid them even more if setting up a security question is mandatory and there’s no way to turn it off.

  10. z says:

    While your intentions are nice, I can’t help but feel this is a fool’s errand. What benefits do you anticipate users getting from having basic skills to audit a site? Even advice like ‘check for https’ isn’t sufficient nowadays (refer to recent attacks that use outdated protocols or weak encryption keys), and that’s about as low a bar as you can set. What does ‘visible data in the URL’ mean? Sure, maybe they can figure out ‘?password=password’, but is ‘?p=5f4dcc3b5aa765d61d8327deb882cf99’ “visible”?

    Even if a user does go through all that and determines that there’s a possible security issue, what should they do? Most sites don’t have an email for a security contact, and if the user needs to use that service, then s/he’s pretty much stuck.

    I think a better approach would be to list some simple steps a user could take so that when (not if) a site gets compromised, they can best mitigate the damage. Companies currently have no incentive to help their users, so for now, the safest approach is to assume any information you submit will be compromised at some point.

    To that end:

    1) Use a password manager. Generate a unique password for every site. Mitigates against companies that don’t hash or weakly hash the passwords by not allowing your credentials to be reused elsewhere.
    2) Disable and uninstall software you don’t need. Especially Java and Flash. If you still need them, restrict them only to sites they’re required, and make sure they’re up to date. Use browser extensions to help with this. Don’t rely on your anti-virus — it’s one countermeasure, but hardly foolproof.
    3) Don’t click on links on unsolicited email.
    4) Make backups. Store them someplace not on your network, if possible.

    • Mechaninja says:

      “Don’t rely on your anti-virus — it’s one countermeasure, but hardly foolproof.”

      Yeah, this.

      I am hiring, and recently received a supposed resume from a supposed applicant. The word doc was 7zipped, and opening it infected my computer. I’m fine now, thanks, I know how to ComboFix and other things.

      A couple days later, I thought about submitting it to Virus Total, and my AV was caught up by then and ate it for me, so I didn’t bother. But the point is, my AV didn’t do the job until it was updated.

      • The Rocketeer says:

        Well, don’t leave us hanging. Did he get the job?

      • Trix2000 says:

        I’ve stopped bothering with antivirus (just keep a simple firewall up because it’s better than nothing), but that’s mostly because I so rarely get infections and I’m pretty good at identifying and removing them in the rare occasions when they do come up.

        I won’t say antivirus is useless… but I also don’t have a lot of faith in its capability. Better to understand and practice safe(-ish) browsing.

        • NoneCallMeTim says:

          Shamus’s article is going out to people who aren’t so good at browsing carefully. I would also be interested in your ‘careful browsing’ for a few months, then running an antivirus to see what it picks up that you missed.

          • Trix2000 says:

            I know that – it’s just how I handle it. I usually get infections at most every couple years, so it just seems more convenient for me to spend a single afternoon cleaning it when it DOES get infected rather than bother with paying for antivirus and/or keeping it updated.

            You’re right, though – it’s not a solution for everyone. But I would still advise people to not expect their antivirus to block/detect everything and be careful with what they click on. Granted, that’s easy for me to say…

      • Zak McKracken says:


        maybe not as much a security advice (though it is that, too):

        Do not send around Microsoft office files if you really just want people to read something.
        Save them as PDF and send that.

        MS office files may contain:
        Macros which may contain viruses
        Formatting that won’t work on someone else’s computer (missing fonts, different version…)
        The assumption that everyone either paid Microsoft a lot of money for the privilege of using MS Office, or just pirated it. I refuse to do either.
        A version history and private data that you didn’t even know MS Office knew about you. (PDFs can contain such things, too, but there’ll be less of it)

    • Alan says:

      For what it’s worth, if you’re running Windows 7 or Vista, get Microsoft Security Essentials. It’s free, good virus/malware scanning software, and it will never nag you to upgrade or renew a subscription. It won’t stop everything, z’s comment above stands, but for the price of free and a minute or two of work it’s another layer of defense.

    • Tizzy says:

      I disagree: the problem is that you and Shamus are clearly talking about a different user population, with a different level of tech sophistication.

      Your recommendations are good, but before users put that in place, they need to start at a most basic level. In particular, you mention what if they are stuck having to use a system. It does happen, true, and weeding out the unsafe but necessary systems will not happen overnight.

      But I think things would go a lot better if users started NOT signing up for stupid stuff to begin with, and start being a lot more critical about what qualifies as necessary. And, in order to do this, users need to be educated about best security practices and the dangers that they’re exposing themselves to when using sites that disregard them.

      As far as I’m concerned, there is no such thing as too much efforts to educate the public about security issues. There are already too many parties who have vested interest in keeping people in the dark simply because it makes commerce much easier and allows you to design cool and convenient toys, but screw the unintended consequences.

      • Joe Informatico says:

        I work in a downtown public library, and we get all kinds. Once, I helped this woman, who was most likely mentally ill. She was absolutely paranoid the two teens sitting next to her on the public computers were trying to “hack” her Facebook account and get her password. I look at her Facebook page–and she’s signed up for at least 40 different Facebook games. I thought about telling her if she’s worried about her personal information being leaked, maybe she shouldn’t sign up with all these third parties of unknown quantity and dubious motives, but I was convinced I’d just get lunatic ravings in response. (sigh)

      • z says:

        All valid points, though I believe our disagreement comes down to:

        1) What is your target audience?
        2) What do you wish to accomplish in addressing them?

        The ideas in Shamus’ original post are valid to some extent for totally uneducated users, but leave the second question unanswered. What are these users supposed to do with that information? Potentially worse is the situation where they have an illusion of greater security and don’t take appropriate preventative steps as a result. “Don’t sign up for stupid stuff” is all well and good, but there are still cases where even useful (for some arbitrary definition thereof) stuff is not designed securely, and the user has absolutely no way of verifying that.

        The recommendations I made above were intended to be low-hanging fruit that most users don’t have to give up much and have large benefits. (Alan’s suggestion of MSE is another excellent one that falls into that category.) My beliefe is these are Good Things and educating users as to why they should do them is more productive than trying to audit someone’s site, which doesn’t really fix anything and addresses a relatively small problem space.

        You indirectly touch on another important point, which is that security is — to most people — purely a cost. Mostly of convenience/time, more rarely of money, but generally with no tangible benefit. (Companies share this same view, but primarily with the monetary considerations.) To get a user to change *any* behavior, you need to establish what the benefits are, else there’s no incentive.

    • Zak McKracken says:

      How much knowledge about internet security is “enough”? I can tell a lot of people a lot about online security but I still have much to learn, and there are certainly people who’ve designed very secure systems who will say the same. There is no upper limit, there is no “enough”.

      So, every bit helps. And every time the majority of the population gains a level in “understanding internet security”, they are in a position to demand something from the companies who want to deal with them. It also means that maybe a decision-maker or two are affected by the increased level of understanding. That doesn’t always work but where there is a choice to make, it is really good if more people were able to make that choice better.

      That said: I think we really need an “etiquette” for the web, not just in terms of “don’t post when angry” and such but also in terms of “forcing people to create an account for one-off transactions is impolite” and “asking for more personal information than you need is intrusion into somebody’s privacy” and so on. Sort of what a handshake (or handwave) used to be: I’m showing you my open, empty hand, therefore I’m not carrying a weapon; and I’ll even let you grab it if you let me grab yours. That sort of thing needs to develop, and it needs top become offensive to regular people not to do it, and then it needs to become so commonplace that noone has to think about it twice.

      Now, in order for people to be offended, they need to know what to be offended by, and the type of list Shamus is compiling here might help (as far as the contents are unknown to the audience that the column will be able to attract…)

  11. Tizzy says:

    How about sites that ask you for security questions? From a small list of choices, if you do have any choice at all… Because we all have a lot of mother’s maiden names and first pet’s name to choose from.

    My workaround is to make shit up, but it’s damned inconvenient. Just not that used to having to keep track of my lies, I guess.

    And I really worry about guileless users who will enter some data that could then be used to impersonate them convincingly somewhere else.

    • Here’s an easy workaround: When you’re setting up your account, type in “I don’t know.” You’ll never forget, if you honestly answer every question asked of you. :)

    • I LOATHE the mother’s maiden name thing. Guess what, my mom doesn’t have a “maiden” name. Even better when you can’t choose the questions and that one is mandatory. There’s more than one website where they think my mother’s maiden name is “Fracking Sexists”.
      (OK, just in case I stuck my foot in my mouth here)
      I have no problem with women choosing to take their spouse’s name upon marriage, or for men making the same choice. I have an issue with any site that makes that a mandatory question (because I firmly believe that taking your husband’s name upon marriage should be a choice you make with no social pressure one way or the other).
      The question also suggests that matrimony is the only acceptable way to have kids, since your mom wouldn’t have a maiden name if she’d never been married.
      Just feel it’s an outdated question that we should be phasing out, and that it should never, ever be mandatory. Perhaps a better question might be “What’s a last name you always really liked?”

      • HeroOfHyla says:

        I thought “maiden name” just meant last name a woman was born with. If a woman doesn’t change her last name upon marriage, isn’t that name still her maiden name?

      • Zak McKracken says:

        I just realize that this question is especially meaningless in the entire Spanish world (large parts of South America, and Spain itself), where usually nobody changes their name ever but everyone has two last names, and the kids get the first from each their father and mother.

  12. Maybe it’s just me, but I really dislike sites that want to use Facebook or Twitter for their login system, since that’s just one more place that’s using the same name/pass setup or having access to it.

    What’s worse are when that’s the ONLY credentials they’ll allow.

    What’s even worse are the sites that require permission to post on your social media accounts as you.

    • Erik says:

      “What’s even worse are the sites that require permission to post on your social media accounts as you.”

      This is an insta-fail for me – I refuse to give any sites (or even apps) permission to masquerade as me for any reason.

    • Blake says:

      From a security standpoint I prefer having a website OAuth via Google/Facebook/Twitter/etc, it means I don’t have to worry so much about that website being hacked because that website doesn’t have any of my information.
      It also means I’m not making new random accounts for sites I don’t care about.

    • Zak McKracken says:

      I actually do have an openID and am happy to use it, except many sites don’t accept every source of openID.
      That and disqus (which I had been using it for for a while) actually kept a (public!) record of everything I had posted via any Disqus-powered comment section, and never told me about it …

      => Linking different things that you do on different sites without excplicit agreement from the user is evil.

    • Purple Library Guy says:

      Well, yes, especially since I refuse to use Facebook or Twitter so that kind of leaves me out of such sites entirely. Similarly, although this isn’t a security issue as such, websites that have articles and stuff to comment on and the commenting is via Facebook. It annoys me that these sites are locking me out of commenting. Not that anyone here has any columns called “The Escapist” on sites where that happens, or anything.

  13. Paul Spooner says:

    In addition to the above, sites which require you to change your password periodically. One of them (that my job requires) that I use infrequently has me change my password nearly every time I log in, in addition to having rediculous length and content requirements. This means that I send myself an e-mail with the password every time I log in to their site, which is probably not as secure as they were hoping.

    In general, any site that goes out of its way to make you FEEL like you are secure, is probably not secure.

    • Tizzy says:

      That’s a common problem as well. Good security measures have to be designed so that they can be reasonably followed, or, as you mentioned, they may force people towards even unsafe behaviors.

      The worst example I know of is place that required employees to change password weekly, with a list of the last 60 (I think) passwords disallowed.

      But at some point, I think this reasonableness mandate requires the security professionals and the end users to meet each other halfway.

      • Oh yeah, sites that remember your last few passwords and disallow you re-using them is also creepy.
        It’s no wonder so many ads or changes the last character or passwords, and crackers knows this and test for this.
        Not helpful at all. Also, if the site remembers it then the site are storing your passwords somewhere or hashes or your old passwords, both are things that really should not be done, getting the database of such a site could be a gold mine for crackers.

        • Zukhramm says:

          Not allowing passwords that I’ve used before has caused me to create a new password every time I log in to my old Microsoft accounts (and I have multiple because FFFFFFFFF). Every time I have to make a new password I’m picking one that’s harder for me to remember, leading to me having to create a new password next time I try logging in, leading to even harder to remember passwords.

    • My webhost does this but that’s for the FTP login password, and it’s only once a year though so not that annoying luckily.

    • Zak McKracken says:

      I know a workplace (fortunately not my own) where user passwords expire after three weeks. So all it takes is a slightly longer holiday (possibly joined to the year-end break), and you need to go and reactivate your password!

      Also, for security reasons, nothing is updated ever. Because the versions of software being used have gone through a loooong approvel process and updating would mean the updates would need to get approved again, which would be a pain so they’re sticking with the old buggy versions. Outch.

    • Peter H. Coffin says:

      Finance sites seem to do that to me a lot. I need information on my 8-shares-of-previous-employer stock portfolio and my 401k precisely once a year–to fetch the tax info about the accounts. Both of them require me to change the password EVERY x months, which means they get a new password every time I log in. I understand it, from the standpoint of a day trader or someone that’s actively “managing” such things it might even be reasonable, but for the people like me that (probably) make up the vast majority of actual users (as opposed to use), it’s an annoyance and no more secure than sending me a paper statement once a year instead.

  14. tmtvl says:

    Yay, Tom Scott! I love Citation Needed.

  15. Gah, reading that gave me the creeps Shamus.

    You are missing a few.
    When you register on a site and it asks you to pick a security question answer from a predefined list.
    You might know the kind… “The name of you pet”
    Too many do this, even banks, I complained to a bank (which I no longer use) that at the very least they should let me create my own security question.

    For those not aware what these security questions are used for…they are used for password recovery, so when you click “Forgot my password” you are asked the security question instead.
    And the questions you can choose are so typical/common.

    Sure you do not need to use your pets name and could write “bagels” instead if that is your favorite food, but in that case why not just simply let you choose your own question. Some users aren’t clever enough to “lie” on these security questions (or they do not like to lie at all).

    I feel uneasy when a site does not hash your password in the browser when logging in.
    If something like HMAC is used in the browser (either native or using javascript) then the website/server itself never sees/know your password, why forums and blog systems don’t do this I have no idea, they should considering it as almost no forums and blog sites uses HTTPS so passwords are instead sent as plaintext *shudder*, if you are on a public network you are instantly screwed if someone are sniffing network packets.
    Even if a site does use HTTPS for logins the use of browser HMAC or similar is a security benefit, the server/website should never need to know your plaintext password anyway.

    When a site does not declares how they store passwords and other info it makes me a little uneasy, a few sites does this though and states if the passwords are stored hashed with a salt etc. if they do this then that is a very good sign.

    Sites that uses a payment system that doers not support Verified by Visa or similar (for other cards), what this system does is that a verification server (for the big 3 cards) is used during card verification and that server pokes your bank, your bank then asks “you” for a password (that you set yourself at your own bank) and it also show a comment (that you set yourself at your bank, to prevent phishing), only you and your bank know this password and the secret comment you set, so your card can’t be phished. Sadly only the stores/payment systems that take part in this uses it, the rest don’t, I guess one could avoid stores that do not use this though. (I do when possible)

    As to your current list….

    On securecode on creditcards/debitcards, I’m not sure but myself I’d assume that storing that is a big no-no. Paypal let you store your CC but I can’t recall them storing the securecode. Amazon does allow storing the CC (it’s optional) but I can’t recall if they store the securecode. The point of securecode was to verify you actually are holding/have the physical card.

    I agree, clicking “Forgot my password” and then getting a email with your actual password really creeps me out, this really should be number one.
    (For those unaware what this means, that means the password is stored in plaintext somewhere, maybe your lucky and it’s encrypted but that is still almost as bad IMO)

    And you might be able to put password length, case etc under one bullet point as “Password restrictions”. The ideal is for a site to accept any UTF8 character as valid characters these days.
    Password restrictions also prevent the use of password tools/generators, a very long generated password presented as hex for example should be useble.
    But if the site limits a password to 8-12 characters and upper, lower, number then that can’t be done.

    • PS! Login systems I myself are working on/or using going forward all uses HMAC or similar in the browser and sends that to the server instead of a plaintext password, and consequent logins then uses a “challenge & response” method and never sends the HMAC hash at all.
      The only way someone can snap up the hash is if they either are spying the network during registration/password changes or if they steal the server database somehow; and in either case there is no way for them to figure out the plain text password besides guesswork or brute force.
      Combine this form of login with HTTPS and it’s pretty safe. (Note. StartSSL give out free basic server certificates for use with HTTPS, and a lot of hosting companies may also provide HTTPS as part of their package these days, so shop around.)

    • Justin says:

      The simplistic “security questions” are a pretty bad idea, yes. But they don’t bother me personally, since my favorite pet’s name was j~3JHXz$.+sn7NFwO^2I.

      • Heh more secure than the password then? :)

        Also, one issue with security questions are that the answer you type is stored as plaintext in the database.

        There was a leak some time ago (Adobe?) where a bunch of these security answers was revealed and this gave crackers (and hackers) some insight into what the password hashes could be. Creepy.

  16. The Schwarz says:

    Even shadier than sites that require special characters in the password: sites that don’t allow special characters in the password. If you can’t sanitize inputs in the password field, why would I trust you to do it properly in any other place?

    Also, this is maybe a bit counter-intuitive, but be wary of sites that don’t ask for your email address when signing up. If you can reset your password without accessing your email, that means anyone else can do it.

    • Special characters. That makes me kind of wish you could do that old trick on Apple II computers where (if I remember correctly) any CTRL-character would be an invisible character for a filename. So a file called “helloworld” would look the same as “hello[CTRL-L]world.”

      It’d make it a bear for password retrieval, though. “Your old password is helloworld. Good luck!”

    • Neko says:

      Oh gods, yes. My university’s convoluted “centralised” password system disallows <, &, and ; in the password amongst others. Very telling.

  17. Dev Null says:

    A word or two about trusted certificate chains, and how to tell that the site is using a trusted cert (which pretty easy) seems like a good beginner-level thing to point out. Because they do hace a cert, right? Because they are using https, right?

    Any site that lets you re-set the password using an easily-guessed security question is essentially bypassing any security provided by the password in the first place. (It’s less bad if the security question causes a new password to be sent to your email account…)

  18. This is not as much a security issue as it is a usability issue.

    Sites that ask you to enter the password twice.
    Stupid if you ask me, recent IE versions does something kind of cool with password fields.
    If you click on a little symbol to the right in a password field it toggles the ***** so you can see what you are typing, you can click the symbol again to hide your password. (see, IE can do cool things too :P )

    This only works if IE is able to understand that a form field is a password field, so sites that fail to do that does not get this feature.

    Sadly I haven’t noticed this in other browsers (I’m mostly a Firefox and Chrome guy).

    • Tizzy says:

      I’m not sure… I fail that particular test so many times these days, I’m glad when the websites catches the error. Though, most of the time, the password gets stored, so I guess I wouldn’t really care what it is. And otherwise, I’m fine so long as they have a good password reset system.

      • I have even failed entering my password twice despite typing it correctly.
        In those situations it was due to the site registering my enter press in the second password field or my Tab press when moving from first to second password field.

        Entering your password then clicking a little show/hide toggle to quickly see if you typed it right is way better than having to type it twice.
        If you type it wrong in one of two password fields then you need to retype it, somebody looking at you but not seeing your screen would now see you type the same password FOUR times instead of just once (if single password field with a hide/show toggle).

  19. Ooh ooh! I forgot one.
    If a site has no info about the site/company/people that run it then that is a huge red flag.

    You should find a company name, address, phone number and a organization number in countries that requires that for companies (usually this is the same as the VAT number for a company).

    (The lack of a VAT number is not automatically bad though, but if a company or individual has one then they should list it.)

    If there is no info on who runs/own the site then you have no clue who you are handing your cash or private info over to.

  20. Tometzky says:

    I’m sorry Shamus but I think you have it backwards.

    Almost all sites are terribly bad at security. Banks, international corporations, even military. You too. You have to assume that every site you use will be compromised. And act accordingly.

    1. Use different password for every single site. Use password generator to generate them. And use password manager in your browser, protected with master password, so you don’t have to remember all these passwords. Browsers can synchronize this encrypted password database between your devices.

    2. Preferably register with all sites with different e-mail address. You can use so called plussed addresses for that, for example if you have “” then also “” will work. For example use “” for this site. Sadly some sites will not allow “+” in e-mail – stupid.

    3. Don’t provide your credit/debit card data to any site. Pay with Paypal, Amazon Payments or another reputable payment processor. When they’re compromised at least it will be in the news, so you’ll know that you have to replace your card. Use wire transfer if possible.

    4. Install security updates on your computer, for God’s sake:
    – use “Check for updates” function in your browser, at least once a week;
    – use Windows Update with “For Windows and other products from Microsoft Update” on your Windows devices;
    – use Plugin Check Page at least once a week to check your browser plugins, especially Flash, Java and Adobe Reader.

    • Rick says:

      My bank (BNZ in New Zealand) allows a MAX of 8 characters and NO special characters. For personal AND BUSINESS banking.

      I’ve complained several times and they just repeat the same crap about how secure their stuff is and that it requires their two-factor auth in the form of code-card (for personal) or a digital token (for business). That’s fine, but I’d still like to choose a proper damned password.

    • Nixitur says:

      No, I think Shamus’ approach is very valid. Completely ignoring whether a site is at least reasonably safe is a Really Bad Idea.
      You’re both approaching the problem of web security from two completely different angles. He’s talking about what a user can do to spot bad security and you’re talking about how to deal with bad security.

      If a site fails even simple security tests, then you should maybe use an alternative or at least be way more cautious (don’t provide any information, don’t use your main e-mail addresses, don’t reuse your nickname, maybe even use TOR).
      But if the site passes the simple security tests that you can do by just looking at your browser, then you can be a bit more open with your information. Yes, the website still isn’t perfectly safe and you should still employ the steps that you mentioned, but it’s at least going to be a bit harder and going to take a bit longer to compromise it.

  21. I’ve changed my view on security questions from “predefined questions suck” to “avoid at all costs”.

    Think about it. A Security Question provides the same access as the password do.
    In fact a password is nothing more than a answer to the question “What is your password?”

    So a Security Question and Answer is plainly a second password.
    Which begs the answer, does the site hash you security answer? If they don’t then any database leak will reveal your security answers.

    If a site uses security questions and answers then the questions should be enterable by the user, and the question and answer should be hashed the same way as the password is.

    One might wonder what the point of a Security Q&A is.
    Well, a Security Q&A (or secondary password if you will) could be made so it’s complex, in that you need to go to your password manager or safe or some secure note to see what the question and answers are.
    That would be a good way to make use of a Security Q&A.

    Mobilephone SIM cards has a PIN and a PUK, if you forget your PIN and the phone locks up you can use the PUK to unlock it again.
    A two factor password solution in a way.

    A benefit of a Secondary password is that a parent may have that info, that way if the kid forgets the password then the parent can reset it using the secondary password/Secret Q&A.

    But only if the Security Q&A is treated as if it was a password.
    I suspect the majority of sites out there store them as plaintext.

    • nm says:

      Sorry, I have to jump in here on that two factor assertion. Two factor authentication is when you’re required to use two orthogonal methods to authenticate yourself. The standard example is “know something” and “have something.” If you know your PIN and have your ATM card, you can withdraw money from an ATM. A PIN unlock key is just another thing to know. So that’s “know something” and “know something else,” which is just more entropy in the single factor. This is why I don’t like the “security” questions. They’re just more bits of stuff you can know, and it’s an OR instead of an AND, so if you know this one thing (first elementary school, for example) then you don’t have to know any of the other things (password) in order to get into the account.

      • Well, most people know the PIN but hardly anyone know their PUK, which is usually on a papernote in a drawer someplace.

        Upon failure to use the correct PIN you need to us the PUK, I said “two factor password solution in a way” maybe “two layer password solution in a way” would be more correct, I did not however mean “two factor authentication” which is as you state it in regards to PIN + ATM (I assume you mean the smart card chip rather than the embossed number or magnetic strip on the card?)

  22. Lazlo says:

    Lots of very good points here, here’s another (relatively minor) one that I’d add:

    If a site asks you for your e-mail address (and they probably will), make sure that 1) you get a verification e-mail, preferably that you have to interact with before you can do much with your account, and 2) that the verification e-mail is reasonably recognizable (like, it comes from: the site in question, and contains a link that goes to

    Now, there are times that you can ignore this requirement, but if your e-mail address is going to be used for password resets, it should really be verified. I know this because I have a very common name, and an e-mail address similar to, and about once a week I get a new person putting that e-mail into somewhere thinking that it’s theirs (I very frequently wonder how this happens so often. I haven’t figured it out yet). Most of the time this is relatively harmless, if annoying. Other times, I *could* if I were the sort of person who would do such a thing, initiate a password reset on their account and take it over. Sure, the risk here is small, and you can avoid it by making sure that *you* always put in your e-mail address correctly, but as with so many of these, it speaks to the security-aware mindset of the site’s coders. Point 2 is just about making phishing a little more difficult.

  23. Rick says:

    Oh, you may want to amend your visible data in URL point to mean sensitive data… the audience might be savvy enough to realise that a username in the URL is ok even though an email address is not… or they might not be.

  24. Chris says:

    Not sure if it counts as a security problem, but it’s definitely irritating:

    Sites with a maximum password length (which you’ve already listed) that let you overrun it when choosing a password and silently cut the extra characters off – but do not do the same thing when you are trying to log in.
    They usually don’t even tell you your entered password is too long, they just go “lol no”.


    • guy says:

      There is no conceivable reason to ever do that. If they can cut the extra off when registering they can very well do it when logging in prior to generating the hash.

  25. Lupis42 says:

    Predefined security questions. (What was your mother’s maiden name?)
    This is a dead giveaway that your account is essentially unprotected from people with a few hours to spend trawling things like public records.

  26. Sean Hagen says:

    My first thing isn’t really a sin, but it’s something I’m hoping disappears from the internet in the next five years or so: making me create an account for your site. Yeah, I use LastPass so I can easily craete a unique password for your site — but I shouldn’t have to. Use OAuth or some form of SSO ( single sign-on ) so that I can sign in with Google/Twitter/Facebook/GitHub/Yahoo/WHATEVER. I don’t need yet another account floating out there in the void. Plus, if I can log in with my Google account, I don’t have to worry about you not understanding security and storing passwords properly because you don’t have to care about passwords in the first place.

    Second thing: TWO FACTOR AUTHENTICATION. You’ve probably run into a stupid version of this: those ‘security questions’ that you see on tons of sites. The idea behind two factor authentication is that in order to be authenticated you need two pieces of information:

    * something you know ( password, question answer )
    * something you have ( security token, app on your phone )
    * something you are ( fingerprint, retinal scan )

    The idea behind this is that if someone can compromise “something you know”, they still won’t have access to your account because they won’t have the second thing. A hacker somewhere on the other side of the planet can’t get into your bank if they don’t have your phone or security fob.

    • Sean Hagen says:

      Oh, also: if you’re going to require special symbols, let me use spaces. That way I can make a passphrase.

      Relevant XKCD:

    • Peter H. Coffin says:

      “Things you are” is one I see a lot of problems with. There is no revoking your fingerprint. It should only be used as IDENTITY (like a username), not AUTHENTICATION (like a password). It should only be used in a place where a trusted party can verify that an actual finger was presented, attached to a living human being, and no shenanigans involving rubber cement etc are involved. And fingerprints can be (in the US) legally compelled. Passwords cannot.

    • Nixitur says:

      The problem with security questions is that they are not two-factor authentication.
      You just have something you know and something else you know. It makes it far less safe.

      And it’s even worse than that: With two-factor authentication, you need something you know AND something you have to even use the service.
      With security questions, you need something you know OR something else you know to log in.
      ’cause in most cases, you can reset your password if you know the answer to the security question which is hilariously unsafe.

  27. Chamomile says:

    My guess is that the credit card security code is there so that a guy whose smartphone camera has a decent zoom setting can’t hijack the bank account of every single person who pays with plastic at a certain store.

  28. I mentioned HMAC for logins earlier, so here is a quick example of how to use HMAC in a way that never sends the password in plaintext to the server.

    Example schematic I put on tinypic: HMAC Login example.

    Do note that at account creation/password change the server do not need to generate a random salt, this task could be done by the browser too, especially recent browsers can now generate cryptographically secure random numbers/data.

    As to the HMAC being done in the browser, there are several Javascripts out there that implement HMAC for both MD5, SHA, and so on.

    And before anyone scoff at the mention of MD5, HMAC using MD5 is still not broken, this has to do with the way HMAC works.

    But if you have a SHA-256 or similar javascript library then using that is obviously advised.

    More info on HMAC on wikipedia.

    And here are implementations of HMAC.
    MD5, SHA1
    SHA-1, SHA-224, SHA-256, SHA-384, SHA-512

    And if you really want to go crazy there is PBKDF2, but if you need that much security for your login you are already using HTTPS…. right? :)

    Anyway, the point of this comment is that plaintext passwords never need to be sent to the server even when crating and account or changing the password, this is known as Zero-knowledge.

    And the login example in the image is perhaps known by some as the Challenge response method.

    • Damnit, I pasted the wrong url for the image. *facepalm*
      Here is the correct HMAC example chart

    • Shlainn says:

      I am sorry, but this is an anti-pattern for website security. It makes you think that your login system is safe, but in fact it is not.
      Let us imagine an attack scenario where a clear-text password sent to the server can be intercepted by an attacker. Say, an open WiFi in your favorite bar. The same attacker can with ease inject modified javascript files into the stream which before encrypting the password send it to the attackers server.
      The only way to avoid this is to have the whole site served from a secure server via HTTPS. And then it does not matter if the password is sent in clear-text or encrypted by the browser.

      • There is a difference between sniffing packets and altering the traffic.
        If the traffic can be altered then you are screwed regardless.

        Also my example image is also valid with the use of HTTPS.
        Please re-read the comment, the point was that there is no need to ever give the password in plaintext to the server.

        Your browser or input dialog/system need it as plaintext but beyond that in the chain there is no need to pass it as plain text.

        Also if you look at the image, the password hash is not even sent, just a HMAC of the salt (aka “the message” in this case).

        I never said that this was better than HTTPS so please do not put words in my mouth.

        Look around the net, how many forums/gaming/blog sites etc has a login, how many of them login via HTTP?
        If those used something similar to this, then by default database leaks is less of an issue (luckily the big forum and blog software does do something similar serverside but you still send the password in plaintext to the server).

        And I’ll repeat myself by saying that “there is no need to ever give the password in plaintext to the server” ever.

        Simply use a challenge-response method and store the question and answer in the database.
        This can be made very computationally expensive even.
        Then later on login the server sends the registration challenge and a session challenge.
        The client software creates a answer, then that answer is used for the second challenge.
        The first challenge can be cached by the client, and by the server as part of the session on it’s side,
        at each re-authentication during the session only the second challenge need to be re-done (each time with a new nonce as the challenge).

        This should be used regardless of the transmission protocol use (ideally HTTPS or better), but if the site only support HTTP then this is better than nothing.

        And I’ll repeat myself once again (and the point of the image).
        “there is no need to ever give the password in plaintext to the server”
        The only thing the server need to know is that the user (client software) knows the password/key, and this can simply be done by using a challenge-response method.

        Why on earth you call the challenge-response method a “anti-pattern for website security” is beyond me, it’s a time proven layer of security.
        HTTPS (or rather Diffie-Hellman key exchange) does use the challenge-response method as part of it’s initialization IIRC (I’m sure someone will correct me if this is not correct).

        Do note that if a database is compromised/leaked then everyone still need to change their passwords, there is no solution to that problem, and there probably never will be.

        And I’ll end by repeating once more, “there is no need to ever give the password in plaintext to the server”, why sending your password in plaintext is still a thing is just silly these days, the server only need to know that “you” know the password.

        • Shlainn says:

          Sorry, I am very late to reply. Damn flu :(

          Disclaimer: I do not claim to be an expert on anything. I have been writing PHP code for the past 13 years of my life, and I have implemented SRP 6a authentication for a project I was working on, but I am not working at a major security-sensitive project or have any sort of formal computer security related education. Everything I know, I learned on the internets or by trial and bloody error. If there is a major flaw in my reasoning I shall stand corrected.

          There is one issue I have with your description – maybe you can clear that up for me. I think we are adressing two different issues.
          In a classical system (say, the client of a major MMO using SRP), challenge/response-authentication over an unencrypted data channel is an excellent way of avoiding sending the clear-text password. This is due to the fact that the client is trusted. A MITM attack against said MMO client would be much harder as it is not so easy for an attacker to modify the client (and possibly also the patcher, and whatever infrastructure there is to ensure that the client executable is not tampered with) to send the login data to some other server before actually authenticating with the game.

          A website is a whole other issue. It basically is an open system. Nothing arriving on the client side can be trusted, unless it is sent over HTTPS (and even then, as pointed out by other commenters, it may be incorrectly implemented etc.). Therefore, a MITM attack, XSS, malicious ads, or any other attack vector can install a Javascript EventHandler which on submitting the form sends the password to their server. And there is nothing you can do about it. Encrypting/hashing the password on the client makes simple sniffing attacks harder, but it does not offer any transport layer security, as it can be grabbed directly from the client with little additional effort. I seem to recall that Meebo had this particular issue at some point during their existence in ye olden days.
          Admittedly that is a more sophisticated attack than just sniffing traffic on an open WiFi. But, if suddenly *everybody* started encrypting password client-side on HTTP-served pages using common software packages (phpBB, WordPress,…), I am almost certain that such an attack would quickly appear in the toolkits of script kiddies out there.

          Basically, client-side password hashing is not the proverbial locked door keeping people out, but rather an unlocked door with a big red warning sign “DO NOT ENTER!”. It will keep the most stupid thieves out. Unless they are color-blind and cannot read. Thus I call it an anti-pattern.

          In properly implemented HTTPS (As described by Troy Hunter in that nice article you linked below) it is impossible (or at least very hard) to modify the traffic between user and server – the whole idea is that the traffic cannot be altered – therefore you are not screwed. I argue that in this case it does not matter if the password is hashed on the client or the server, as the communication channel is secure and it makes no difference if the password is sent in clear text, as HMAC, or any sort of hash.

          Now, one must also consider the other side, which was mentioned here more than just once: If a server does not have the password in clear text, it cannot store the password in clear text. Or have it in memory to be heartbled. Or anything of that sort. And for that the method you describe is very useful. But it does not add any significant security for login data entered in a form which was transmitted in the open.

  29. Dt3r says:

    I love the picture for this post, it’s the perfect metaphor.

  30. Daemian Lucifer says:

    Late to the party,so I dont have anything helpful to add.But,I have a funny comic that I always like to link when passwords are talked about:
    Casey and andy

  31. Fictrix says:

    Is it too late to add more suggestions? I found some things last year during the Heartbleed debacle to add to that list, and they’re very easy to check:

    1. The site does not let you change your email address.
    2. You cannot use special characters (such as “+”) as part of your email address.
    3. The site does not let you change your password.
    4. The site does not let you delete your account.

    An easy way to check #4 is to look it up on Just Delete Me. Fun fact: Steam is listed as “Impossible”.

  32. RCN says:

    Ugh. I don’t even know how many times I registered into a site, only to have them e-mail me back my username and my chosen password in plain text.

    “Yep… that’s a password I’m never going to use, ever again”

    What really aggravates me is that a few times it happened after doing a transaction.

    Is there anything I can do in those cases? I mean, beside just burning and canceling my card and issuing a new one?

    The character limit is also a bummer. I’ve developed a 70-character password that I only use on trusted sites that deal with my money. And yet a few of those won’t allow me to go past 12 characters. Some won’t even allow me to go past 8 (that’s EIGHT) characters. Really? You’ll only allow me a password that brute force can crack in less time than it takes me to even type it, regardless of how many different symbols I use in it?

  33. Zak McKracken says:

    Another one for the list:

    open WIFIs (with no encryption)

    Nothing against free WIFI but they should always be using WPA2 encryption (and just either tell everyone the key who asks, or just put it on a sign somewhere). That means everyone can still access the network but everything on it becomes encrypted and so not everyone can read what everyone else is sending across the WIFI.

    Even worse than unencrypted WIFIs: unencrypted WIFIs that redirect you to a login page, force you to create an account and then let you on the web. Often don’t work with many pieces of software that aren’t browsers (e-mail or instant messaging clients), and gives you the worst of both worlds: “They” get your data, and your traffic is still completely in the open.

    • Gah! I have to ask (hopefully somebody that knows something about WiFi and WPA2 can answer this) but…

      If person A is given a key and person B is given the same key then only those two can use the WiFi network, but can’t person B also decrypt person A’s datatraffic? (or was that only a weakness in older WiFi methods?)

      Only if each person (or machine rather) that connects get their own key is the WiFi “safe”. Provided you trust the router/network itself. I would still use HTTPS only regardless though on top of that.

      • Zak McKracken says:

        This explains how the protocol works, though it’s very much not in layman’s terms (and I have problems understanding it, too):
        … but what I could decipher from it: You use the WPA2 password only to authenticate yourself as someone who is authorized to connect to the network, and then your device has a “handshake” with the router, during which a set of session keys is generated. Those are unique for every user and are used to encrypt everything during the session, then (I assume) discarded after you disconnect. Next time you connect you generate a new session key.

        => No, different people cannot read each other’s traffic on a WPA2-WIFI. There’s something about weaknesses on that page, too, but as I understand that “only” gives you a way of figuring out the password. That’s a problem for private WIFIs whose owners think they’re the only ones using it, but it wouldn’t be a problem for a publicly-accessible network in a café, where the password is given to everyone anyway.

        • guy says:

          Well, I have to admit that the page is pretty much totally incomprehensible to me too. However, I do see one problem, which is that it’s a symmetric-key algorithm. That is, both sides of the exchange have the same key. Which in turn means that it must be possible to derive the key from the message traffic in some manner. Specifically, it’s based on the MAC addresses of the AP and client, which will be on every message, and on three values which are transmitted between them. So anyone who actually intercepts the handshake can theoretically derive the key, and wi-fi transmissions are omnidirectional.

          What I can’t figure out is how secure the handshake messages are. I know there exists some algorithm to establish a two-way secure exchange over an insecure channel by using numbers that have a predictable mathematical relationship to secret prime numbers on both ends, but I cannot tell if it does something similar.

          • Zak McKracken says:

            alright, so you extracted more info from that page than I could. I had naturally assumed that of course people use asymmetric keys for things like that these days…

            On the other hand, I’m reasonably sure I’d have noticed the “OMFG, WIFI isn’t safe anymore” posts on some of the sites I frequent…

  34. Zak McKracken says:

    Something I find very helpful:

    https everywhere.

    A browser plugin that will attempt to make https connections whenever possible even if you clicked on a non-https link. Only works on sites that offer https connections, but default to http for compatibility reasons or such. There are quite a few of those out there.

    On that note: Shamus, what are the chances of your website offering https? I ask that not knowing how hard it is to implement that. I know there are free certificates to get these days but I’ve no idea how well they are accepted, or how difficult it is to set your server up accordingly, possibly worry about renewals and such …

    • Zak McKracken says:

      I’d really love for https to become the standard. A world where instead of a green lock for good https browsers show a red exclamation mark for plain http (because that’s become the exception), there’s just a lot more pressure on companies who don’t care about this stuff.

    • The comments do not use a login, but Shamus’ forum does and might benefit from HTTPS.

      HTTPS on the website itself will put some extra load on the server so there is a privacy vs cost issue there to consider.

      Also note that are two things to keep in mind with ol’ HTTP, man in the middle attacks and eavesdropping.

      MITTM requires the attacker to control a point where the traffic goes through (hence man in the middle).

      Eavesdropping on the other hand is far easier and can be as simple as being on the same network as somebody else (Netcafe, LAN party, Library, some WiFi hotspots etc).

      Here is a rule of thumb to live by.
      If you do not trust the network then DO NOT USE IT.
      If you trust the network but not the other machines connected to it then USE HTTPS only.

      This is why I always make sure to put a router between my local network and the ISPs network, you do not want your PC on the ISP network directly, if the ISPs “box” just acts as a switch or similar then anybody else on the ISP network can directly poke all the ports on your sytem and potentially eavesdrop on your un-encrypted traffic (including plaintext password logins on sites that do not use HTTPS)

      • Zak McKracken says:

        As you just said, for anyone surfing via an open network where people might be eavesdropping, https is a good thing, even for regular passive websites.

        Https for the forum (at least the username/password part) is certainly a good idea (I’m not on the forum so I don’t know if it’s already in use), but for the rest of the site, it’d be an advantage, too.

        I have no idea what the additional server load of https or (as mentioned) the pain of setting it up would be, so I won’t point fingers … I still like to use https whenever possible.

  35. NoneCallMeTim says:

    Ok, I have read through the list, and here are some things I don’t think people have mentioned:

    -Particularly in E-mail but also on websites, links which proclaim to be from PayPal or similar which link through to something like: I personally don’t open things from PayPal or other finance things, I just delete the E-mail without reading it, and if the subject line looks important, I go and log directly into the site.

    -Following on from this, if you have outlook or other similar E-mail program, the preview pane can activate malicious script when you are scanning through your mail, even if you don’t fully open the E-mail.

    -Searching for a website login page, rather than going to the URL directly. It is possible to make a spoof site which redirects people into a keylogger then into the real site.

    -Consider having two E-mail addresses: one for your important things like banking etc, and one for your social activities. That way, ID theft of important things is more difficult if your E-mail / password has been taken from a scam site.

    -If you spend a lot of time on places which advertise on free games / screensavers / desktop pictures / ringtones / gif downloads / pr0n / torrents / file sharing etc, you WILL be vulnerable to malware, and must take extra caution.

    -Get an Antivirus program / firewall. If you don’t know how to choose an antivirus, go to a reputable review company eg PC World etc, and select from their recommendations. Ideally go straight from the reputable company to the antivirus company (See the above point about searching for a website login / download page, as this is apparently a popular spoof topic). I saw one user just do a random search for antivirus and downloaded something. This ended up being a worse virus than the one trying to be solved.

    That is all I can think of right now, hope it helps.

  36. z says:

    The comments here, unfortunately, are pretty representative of the state of security knowledge today. There’s a lot of misinformation and ignorance out there, even among self-professed experts.

    Couple of notes:

    1) HTTPS is not a panacea that magically guarantees you’re secure when you see a green lock. Even a quick glance through the Wikipedia article shows the level of verification a user has to do to ensure the connection is truly ‘secure’. This doesn’t include the possibility of certificates with weak encryption keys, maintaining your CRLs, the host or server already being compromised (banking trojans), or reverting to a deprecated protocol.

    2) Even if your data is encrypted in transit, you have no idea how or if it’s being stored on the other end. Pretty much every site claims they ‘care about your information’ and ‘uses security measures to secure your data’, which translates to ‘we spent as little time and money as possible because it’s an external cost to us’.

    You can’t control what the other servers do with your data if you need to use their services. Assume the host will be compromised at some point, and act accordingly.

    The best option is to control how you disseminate it. If it’s just a email and password, use disposable versions of both ( and a password manager). For financial information, don’t ever use a debit card. Credit cards are the issuer’s responsibility, so you’ll be inconvenienced but shouldn’t be out much money when it gets taken (which is more likely at a physical PoS anyway). Lie when possible about your address, phone number, and other vital signs.

    3) The vast majority of the public is not going to be targeted. Instead, they’ll be part of a mass hack or spam/phish campaign. This means that a hacker is not typically going to try and brute force your Facebook or eBay account, but instead will try to get as many username/email and password combinations from a dump and use those on other sites.

    What this means is if you use a unique password (and ideally username) to each site, you’ve limited your damage. If it’s not a randomly generated password, it’s almost guaranteed to be cracked. You’d be amazed at the sophistication of dedicated password cracking setups.

    4) There’s a lot of Windows desktop specific advice here that doesn’t even touch things like mobile apps. How much information are those sending? What sort of encryption do you think they use? How would a user find out?

    5) Having a list of ‘sins’ is all well and good, but it doesn’t help anyone activate their game they just dropped $60 on, aside from a way to name and shame.

    Ultimately, the advice you give depends on the threat you’re trying to mitigate.

    Is it a hacker gaining access to a remote host’s network that may have your personal info? A potential bad actor on the network when using Wifi at the coffee shop or library? Preventing drive-by exploits on sites you browse to? Mitigating spearphishing attempts?

    All of these are valid scenarios that various suggestions here address (or fail to) to different extents. Broad advice like ‘check for https’ is useless in most scenarios, and doesn’t help the user when their goal is to watch the funny cat video no matter what the little lock says, dammit. It’s worse when they think that’s sufficient protection and avoid taking more appropriate countermeasures.

    Of these, I’m most concerned about the drive-by scenario. My reasons are that totally legitimate sites (like yours) end up serving up exploit packs to users that simply browse to the page. This happens through the site being compromised but also through web advertisements. In either case, the user’s not going to notice anything amiss. If they have a vulnerable browser or plugin, then game over.

    In this case, https won’t help (hook and intercept encryption and network comms), your passwords are all compromised (keylogger, hooking clipboard events, screenshot virtual keyboard), and if you’re really special, your data’s all encrypted.

    6) While it’s a pipe dream, the world would be a much better place if everyone would use PGP.

    • I agree with pretty much everything you said here.
      “Even if your data is encrypted in transit, you have no idea how or if it’s being stored on the other end.”

      This is why I always cringe when I notice the password is sent in plaintext. HTTP Digest Authentication would be nice but its’ so underused and underdeveloped it’s a real shame (it would for example be resistant to MIIM attacks).

      “HTTPS is not a panacea that magically guarantees you’re secure when you see a green lock.”
      True but it’s the best we have, but yeah. Heck even HTTPS is not 100% safe from MIIM attacks.
      But advising folks to slap HTTPS on everything is still a pretty good advise though.

      “Lie when possible about your address, phone number, and other vital signs.”
      Unfortunately some politicians are trying to make that illegal to do, they want to get rid of anonymity (mostly in the name of fighting terror or for catching music/movie pirates or the always effective child porn argument).

      The problem is that criminals do not follow the law but law abiding citizens do, and if anonymity is outlawed the criminals will remain anonymous but rejoice in all the correct data that is now enforced and out there.

      As to PGP yeah, although I’s advise on using GnuPG instead.
      Also note that originally PGP was nerfed and not allowed to export higher security encryption out of the USA, the solution was the source code was compiled outside USA instead. PGP was bought by Symantec and is now defunct.
      OpenPGP is the continuation (and GnuPG / GPG is a standards compliant implementation).

      HTTPS and Certficates are nice, butt there is money involved which is bad, stuff like that really should be free. (which is why i like what StartSSL is doing and why stuff like Let’s excites me.

      OpenPGP is on the Internet Standards Track too (which is a good thing).

      As to phone apps, they just weird me out, the agreements (and the weird stuff the apps want access to) is just freaky.
      It’s one of the reasons I don’t have a Smartphone (besides being broke and not really needing a smartphone either, heh).

      One of the key issues is that computers are complex and the “Generation-LOL” rock at texting and sexting and selfies but have no clue on the underlying tech.
      I’m actually of a age where I have been exposed to theft at one point, of my wallet no less, this was actually many years ago when a wallet was still a “thing”, I even had cash in it.
      And trying to get a new ID and prove I was me (without an ID) was the most convoluted crap I’ve ever been through. And I hope nobody will ever need to go through that, it really sucks.

  37. Spartibartfast says:

    I did a co-op term at a company that did EMV card data transactions, from what I remember storing the CVV number is super illegal, instead they tokenize the data ( at least this is what they should be doing ) with the provider and send the token over, that way, only the provider has the CVV and card data, and you only store the *******1111ish string, never the whole number.

    We could store the credit card number temporarily in RAM, but it had to be erased and disposed of.

    • Zak McKracken says:

      That still sound like you very much have to trust each individual implementation of a web interface that asks you for credit card information because there seems to be nothing that would prevent them from just storing everything without telling you, would there?
      …and that’s disregarding the times when I had to tell people the CVV via phone when reserving a hotel room.

      • I’d love to know what “tokenize” means in this context. If it means “HASH(salt+CVV)” then that is pretty nice, if not then it can be reversed easily, a CVV is only 3 digits usually, so plain hash/token with no salt would make for the easiest rainbow table ever.

        Heck anything regarding passwords, CVV, or whatever else should have a salty hash these days rather than actually storing it.

      • Also, why would you need to pass the CVV over the phone, I would assume that was only for automated online systems, wouldn’t this mean they’d actually use your credit card in your place? Is that even technically allowed by the CC company rules/agreement with you?

        The best thing is to use a reputable payment system ad stay away from places that seems to accept CCs using their own system or some obscure payment system.

        Here in Norway most online shops/stores/etc. use NETS, DIBS, PayEx, PayPal or a few other big brand solutions, their routines while not always perfect they are at least experienced and pretty standardized in how they handle stuff.
        And any mistakes could potentially affects thousand or tens of thousands or more consumers so they tend to take security seriously. (if not then people will flee to the competition).

  38. Mike C says:

    * Websites that don’t allow words from their naughty list in passwords
    * Websites (mainly social ones like LinkedIn) that want your email credentials in order to mass upload your contact list.
    * Websites that ask for additional security questions (in other words, a means to bypass your password with publicly accessible information).

    I think Troy Hunt (the guy behind would be a good person to collaborate with, he’s sure to have lots of material for you.


    …and this morning he’s announced that he has some spare cycles for people to approach him with requests.

    Oh, and 2FA (via smartphone app or text message) is slowly becoming more common, and that’s a good thing.

    • Zak McKracken says:

      Wow, that’s quite informative, I didn’t know that story about Tesco…

      The problem, really is: How would someone who doesn’t follow Troy Hunt’s blog know from looking at a site that they’re doing it wrong?

      Someone needs to figure out an easily testable way of proving that your website is doing things right, or there needs to be some sort of certification going on. Which would then require trust not in individual websites but in the certification agency … not ideal but probably better than having to trust that “your safety is important to us”.

  39. Kdansky says:

    I’ve written about choosing passwords a long time ago. It’s still fully relevant, and if you want to offer advice, feel free to crib.

  40. I’m gonna make this my last comment on this (I see my ugly mug in enough places on this page already).

    Thanks to Mike C for the Troy Hunt links; due to that I found this:

    I highly suggest that Shamus and anyone else read that, it’s a tad techy sure. But if you can follow what Troy Hunter is writing about then you’ll realize of insane it is to login using plaintext password or write/read private details over a unencrypted connection.

    Eavesdropping like shown here will go fully undetected, it’s passive hacking and there is no risk of the hacker being caught/noticed.

    It also shows how session hijacking can easily be done.
    Also note that if you login via http a attacker may not need to hijack your session, if they caught your login packets they got your plaintext password.

    Think about this the next time you login to your game forums or blog sites or whatever.
    And if the HTTPS connection changes to HTTP at any point then that is a red flag you should pay attention to.

    • Mike C says:

      It gets more complicated when you’ve got a website using a less secure form of HTTPS implementing, say, a more secure payment system in an IFrame. Everything looks good on the outside, but the security of the payment system has been compromised by the host site.

      I think, though, that situations like this are more for the security experts to quibble over and the developers to take care of than for the end user to necessarily be educated about.

  41. Damit I can’t shut up.

    Thought of another.

    If a site that has HTTPS also allows you to login via HTTP then that is a red flag.
    This means a phising attack (or simply a small typo/mistake on the website itself) might send you to the HTTP login instead of the HTTPS one.

    If a website supports HTTPS then it should not show the login dialog etc. on the HTTP connection.
    PHP and other server scripting languages etc allows a fairly easy way to check if the user is connected using HTTPS or not.
    So showing a error page instead of a login page when the user tries to login via HTTP is fairly easy.

    I have yet to actually see this done by any sites out there, instead they redirect from HTTP to HTTPS which is actually advised against doing (IIRC Troy Hunt mentioned it on his site).

    My own site update I’m working on will only allow login via HTTPS, if there is no HTTPS connection then no login is shown at all (just a informative error page saying to use HTTPS instead).
    (The internet standards folks and browser devs are trying to find a way to inform the browser of this at an earlier stage, possibly via DNS records and DNSSEC, in a browser generation or two this might be supported).

  42. Well. This happened

    So now the NSA and GCHQ can compromise billions of SIM cards.
    That two factor check using a cellphone may not be much use at all.

    And doesn’t a lot of banking mobile apps rely on the SIM card as well?

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *


Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>