back to article Ashley Madison made dumb security mistakes, researcher says

A “ten minute search” by a security bod has provided some hints about the coding errors that might lie behind the now-infamous Ashley Madison hack. While the author doesn't make the specific claim that these mistakes lie behind the Ashley Madison hack, it hints at the kind of inattention that opens sites to attack. The London …

  1. Crazy Operations Guy

    5-8 character DB passwords?

    That is amateur hour right there... DB passwords are something that gets copied/pasted and usually just sits in a config file, so why not make the thing as long as the DB will support? Maybe the DB admins for AM just really wanted to believe that 5-8 is really long and more than sufficient...

    1. LDS Silver badge

      Re: 5-8 character DB passwords?

      Today there are better authentication methods than a text password stored somewhere, easily readable. And maybe read at startup and then kept in memory unencrypted.

      Especially for users who have high privileges on data.

      Just, other methods may require a more complex setup - thereby nobody, from developers to sysadmins, will use them.

  2. jonnycando
    Devil

    Re: deja vu all over again

    This saga just gets sillier....sadder also, but sillier.

  3. Anonymous Coward
    Anonymous Coward

    5 characters eh?

    Not male appendage related?

    1. Wzrd1

      Re: 5 characters eh?

      Only if one is measuring in millimeters.

      Two numbers for developer IQ points.

  4. Anonymous Coward
    Anonymous Coward

    Could it be ...

    devops at its best ? I mean coders doing security themselves with no security policies, no quality assurance and other "unnecessary" stuff like that ? What could possibly go wrong ?

    1. Destroy All Monsters Silver badge
      Facepalm

      Re: Could it be ...

      The lack thereof has nothing to do with "devops". You seem uninformed, devops is not "coders doing everything". Please educate yourself. Unless you are PHB, then please rest content in the sewers of ignorance.

    2. SecretSonOfHG

      Re: Could it be ...

      so if developers don't write security code, who exactly does according to you? What is this new mysterious profession that allows someone other than developers to write code? If you seriously believe that the anyone calling him/herself a "security professional" does not code, you're in serious, serious, trouble.

      See, anyone with a check list can call himself a security professional and go around flaunting about your processes and your vulnerabilities, but could not fix one (or exploit one) even if his/her life would depend on it. Only those who understand code and can code can actually do more than go around the checklist. I prefer to call the latter "auditors"

      1. Anonymous Coward
        Anonymous Coward

        Re: anyone calling him/herself a "security professional" does not code

        Oh I know LOTS of people with the title Security Professional, certified even, and they don't code. Frankly, I wouldn't trust them to write a 'Hello Word' program. And yet, we have to answer to them and their list of check boxes.

  5. Anonymous Coward
    Anonymous Coward

    Psychology

    It's well known that many people having an affair do it for the frisson of danger and that most of them secretly want to get caught. I reckon Ashley Madison was coded with those principles firmly in mind.

  6. oldtaku

    They just didn't caaaaaare

    This is my go to answer.

    Wireless insulin pumps that are trivially hackable? They just didn't care. Cars you can hack crucial driving functions on through entertainment system or OnLive? They just didn't care. Target? OPM? Etc.

    They think security is too annoying so just do a cursory, laughable, intern level half-ass half-baked home grown thing. Because they figure even if they get hacked all they have to do is offer one year of credit reporting, which is a total scam and they get cheap because it's basically just a free trial for LifeLock or Experian. The AM emails have execs going 'we really should improve our crappy security' 'lol yeah we probably should' lololol.

    The only times suits ever learn are catastrophes like this or huge penalties because, being sociopaths, they don't give a single shit about their customers.

    1. Roq D. Kasba

      Re: They just didn't caaaaaare

      Rather, why care if you're making money with your questionably misrepresented business model. People keep giving you money which you spend on adverts, and round and round it goes. Security is seen as a cost, not a benefit, to a CFO.

      Everyone knows the time to shut the stable door is when there's a cloud of dust on the horizon - reactive, not proactive, because money.

    2. Anonymous Coward
      Anonymous Coward

      Re: They just didn't caaaaaare

      You think it is just amoral sociopaths that don't care, but in fact very few people care about anything like that. For example, where I work, we have one website that pulls in tens of millions of pounds in subscriptions a year - it runs on a single server, no sharding, load balancing or HA. We have one service that this website relies on, and to rebuild the data on that service from scratch would take many weeks (with the main site down in that time).

      Can we get time to fix either of them? No, new features are more important, payrises and bonuses all round for management.

      IT is like juggling cats and spinning plates all at the same time.

      1. Kane Silver badge
        Joke

        Re: They just didn't caaaaaare

        "IT is like juggling plates and spinning cats all at the same time."

        There, FTFY!

    3. Tom 13

      Re: They just didn't caaaaaare

      Yes and no.

      In my experience most people are essentially honest. So they never think about thing that are obvious security holes to a thief. For example, one place I worked at wanted an aesthetically pleasing entrance to the office. They also wanted it secure. So they got one of those nice electronic locking systems that used a flash your badge to the sensor thingie and nice thick glass doors. For the convenience of those leaving there was a motion sensor on the inside of the door. AND since you don't want the glass doors shattering from repeated impacts, a half inch gap between the doors. Nobody from the CEO on down thought anything about it. Until our reformed car thief from the IT department pulled one of them aside one night, took a yardstick and taped a piece of paper to it. After which he easily inserted the yardstick through the gap, waved the piece of paper around, and unlocked the door.

      Real security is hard and complicated. You can't break it down to a list of check boxes, even if a decent list of check boxes is better than no list of check boxes. And even if you do it right, there's still no guarantee you won't be hacked, just greatly reduced risk.

  7. Netbofia
    Holmes

    Wiener fest

    The admin where just tired of hosting a site filled with horny men and no women to be seen.

    Nothing else can explain the terrible lack of security practices.

  8. Alistair
    Windows

    application development and security

    I'm sorry DAM. I've been an SA - specifically tasked with *doing the new stuff* for 12 years - I've met in that time exactly 3 developers that gave one rats a$$ about security - Typically I'm the one jumping up and down and waving security policy documents around and screaming at idiots that try to 777 entire data stores. Given the latest flock of DEVOPS twats I'm meeting -- most of whom have less than 5 years in IT, I'm feeling like I'm drowning. I DO tend to blame it on "developers trying to do everything" - mind you I'll agree that its typically because the demands of management include "give us new $hiney $hiney for < last weeks coffee budget"

    And I've found the that the only way to get 'maintenance' done is to let the 3P pen testers red flag all the "This version might be active in your environment and might be vulnerable" items - it at least gets us outage windows to do things to fix issues. Even if we're updated past "this version" and don't even have "this application" installed.

    Its getting worse rather than better as we start rolling out "application in a box" appliances. Jesus murphy.

    1. Tridac

      Re: application development and security

      web_programming != (software_engineering || systems_engineering)

      1. Tom 13

        Re: web_programming != (software_engineering || systems_engineering)

        Actually the problem is that too many people believe that statement is true. These days if you don't treat your web programming with that level of respect, you're risking everything. Well, at least at most places.

  9. Def Silver badge

    So...

    ...where should you store passwords and SSL private keys?

    (Serious question from someone who wants to learn more about this stuff.)

    1. Tom 38 Silver badge

      Re: So...

      Where they went wrong (allegedly) is that the passwords and certs are in the source code repository! zomg!

      What they should have done is have puppet/chef/cfengine push out dotfiles so that the passwords and certs are in the role user's environment, and the config files pull it out of there.

      Of course, your puppet/chef/cfengine configuration must be versioned and change managed, so that gets checked in to a repository too! Repositories all round!

      IMO, this just replaces one source of information leakage with another. Any accidental environment leakage can lead to disclosure of secrets, so you have to scrub it. I've no problem with production config files living in a separate repository, just this "stuff everything in the environment and write complex, hard to read and debug config files that pull it out again".

      1. Def Silver badge

        Re: So...

        So if I understand you correctly, you store these things in dotfiles so it's harder to access them from the outside world, right? The data still exists in the file system, just not explicitly in the same file as the code that accesses it.

        In the site I'm currently developing, I have a code directory (among others) adjacent to my www root directory, so (I hope) none of the files are directly accessible from the outside world. (I'm assuming PHP includes don't work in quite the same way as C includes, so if the server config gets screwed up the user only sees the front facing file and not all the included files too.)

        Would I be better off having, say, a data directory alongside www and code to store these things? Because, to be honest, I'm not seeing any real benefit in doing so - if an attacker gains access to the file system there's a not a lot I can do anyway, right?

        1. Anonymous Coward
          Anonymous Coward

          Re: So...

          Would I be better off having, say, a data directory alongside www and code to store these things?

          You can store stuff in the directory underneath the webroot and access it through local paths (..\filename.txt) - it can still be got at by your local code; but the webserver will ignore it. You're still stuffed if someone gets at the filesystem (or through FTP); but if they're that far in, you have other problems.

          1. Def Silver badge

            Re: So...

            You can store stuff in the directory underneath the webroot and access it through local paths (..\filename.txt) - it can still be got at by your local code; but the webserver will ignore it. You're still stuffed if someone gets at the filesystem (or through FTP); but if they're that far in, you have other problems.

            Yeah, that's basically what I'm doing. The only files accessible by the webserver are files that need to be served directly to the user. Everything else is shoved away behind the sofa, so to speak.

            And yes, if someone gets access to the file system then I have much larger problems.

            Hence my original question. If nothing on my server that could be considered 'sensitive' can be served directly to the user, what else can (or should) I be doing to secure the site? In my mind, I don't think it matters two hoots whether my (down the back of the sofa) source code contains a DB password or not, because if the only way you can get it is through the file system (physically or through FTP, as you mentioned) which particular file stores it is irrelevant, surely?

      2. Cris E

        Re: So...

        Also, those magic config files with access to pswds and certs should only include rights to data that end users will need. C'mon in EndUser, query all the data that'll fit into a panel, but only those pre-defined panels that make for poor data mining queries. If you think about it in advance it's the sort of thing you can control with good design. (For anyone that was confused by that last sentence, you're probably part of the problem.)

      3. Androgynous Cupboard Silver badge

        Re: So...

        All this eye-rolling outrage has me a bit puzzled too. I get storing keys directly inline in the code is bad from a maintenance point of view, fine. But they've got to be stored somewhere. If they're in a config file, or they're created by a process that itself has a config file, at some point they have to be stored in a repository (because the odds of fat-fingers requiring a restore from repository are much, much higher than the odds of being hacked). So who can explain to me why two repositories is more resistant to hacking than one?

        The only way I can see around this is something like a PKCS#11 keystore - a hardware token plugged into the server, which stores the private keys required to access the AWS or whatever. Which is a lovely idea but a lot more work, and overkill for most applications I would think - including dating websites.

    2. Tridac

      Re: So...

      Store them encrypted in (for example) a parallel directory to webroot, then use compiled cgi bin slip functions to decrypt on the fly, access the resource, then clear any buffers used. The encryption doesn';t even need to be complex - bit shifts and exclusive or is probably enough and is fast at cgi bin level...

  10. tony2heads
    WTF?

    hard-coding certs and private keys

    seriously WTF here; or perhaps they were taking their examples from The daily WTF

  11. Anonymous Coward
    Anonymous Coward

    so lets see

    So we are supposed to be surprised that a site whose business model is nothing but basically fraud and extortion didn't take its customers privacy or even it's own security serious? Color me shocked.

  12. Tridac

    Noone with any sense would ever store external server ip addresses, passwords etc in plain text within readable web site code. There are various simple methods to make life difficult. For example, if you use a compiled language for sensitive code, with cgi bin executables, you can encrypt sensitive data as arrays within the binary, or store elsewhere, decrypt on the fly to access the resource, then immediately clear any buffers used. This means that an attacker has to access the binary, disassemble the contents, work out what the code is doing in terms of the on the fly decryption to get anywhere, Reverse engineering the code becomes even more difficult if you are running on non X86 hardware, such as Sparc or Power, since even fewer people are fluent in the assembler than for X86.

    Web sites seem to get more and more complex, which only inceases the attack surface area and makes it more and more difficult to show the code is provably secure...

  13. Mark Wilson

    Reminds me

    I went for an interview not so long ago with a company who shall remain nameless but which had big name clients, even before the interview, I was given an admin password to the back end of the site. Not only were the passwords for clients stored in plain text, the generated ones were clearly sequential and to make matters worse, they were actually visible through the web interface to an admin user.

    Needless to say I did not take that job.

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021