6 ms·

Plenty of financial institutions have also made the studied choice to limit the length and types of characters I can use in my password.

tptacek 15y ago
No. I recognize this as snark, but it's inaccurate snark. Banks limit password lengths because the programmers who implement their apps are dumb. But programmers don't choose the SSL configurations for their app servers and load balancers; people who are paid to think about security do. Your attempt at snark here relies on an apples-oranges comparison.
- mapgrep 15y ago
  If the institution chooses an insecure password policy, it heightens the likelihood it will fail to ensure good SSL settings. This tendency is independent of the fact that these functionalities are implemented by different teams, and that one team might happen to be competent enough to do the right thing despite the lack of institutional imperative. So the consumer might get lucky. So what? Your initial comment was that "plenty of financial institutions" do SSL a certain way, and the respondent correctly pointed out that this fact adds no information to the discussion about SSL techniques, because plenty of financial institutions do dumb things. It's "apples and oranges" only insofar as he's saying the orchard manager is a poison spreading dummy so you can't trust the apples or the oranges. Maybe you can elaborate on the "studied" part of your comment with specifics. That part was interesting.
  - tptacek 15y ago
    You use this word "the institution" as if companies were hive minds. Read the other comments on this thread. Again: the people who make decisions about password complexity are almost never the security people.
    - mapgrep 15y ago
      Exactly. You shouldn't trust a particular technique just because a financial institution uses it. They have very little institutional culture around security, as you yourself point out. So I'm not sure why you brought up the fact that financial institutions use a particular SSL technique - that tells us nothing.
      - tptacek 15y ago
        Your argument is exasperating, because I already addressed this notion that password complexity requirements in banking apps have anything to do with what financial security people think are best practices for SSL/TLS.
        mapgrep 15y ago
        I still have no idea why you keep bringing up the finance industry - it brings no credibility to this discussion or your points, which seem reasonable enough. Even the "security people" taken collectively have no keen track record so why are we talking about them collectively, again? No big deal, I just don't get it. Shrug.
- thirsteh 15y ago
  Of course, in a perfect world, developers would be paid to think about security.
- chc 15y ago
  I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.
  - tptacek 15y ago
    The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build badly. Can you guess how much it costs to revise password storage and UX for tens or hundreds of applications?
    - khafra 15y ago
      Interesting. If financial institutions routinely succeed at operational security but catastrophically fail at having a secure development life-cycle, is that a startup opportunity?
      - m0nastic 15y ago
        I don't know about "startup opportunity" specifically, but it's pretty much the raison d'être for most application security consultancies. Usually when first engaged, you deal with operational issues (making sure all the applications they know about are assessed), but as you build on that, you try and instill secure development practices (so that every new application they build doesn't have the same issues as the ones you've just spent months uncovering). The number of large clients I work with who don't have any SDLC process is staggering (I'd say it's the overwhelming majority of them). For the most part, the small group of security people are tasked with trying to secure the multitudes of applications which in many cases are 20-30 year old codebases. Their developer groups may be completely separate (usually from the result of all the mergers of financial institutions) and it's basically all fiefdoms. As you start to work up the pyramid of enterprise security "hierarcy of needs" you get to things like a secure development life-cycle, but not all organizations are "ready" yet for that type of work. Some are just trying to figuratively stop the percieved bleeding.

tptacek 15y ago

No. I recognize this as snark, but it's inaccurate snark. Banks limit password lengths because the programmers who implement their apps are dumb. But programmers don't choose the SSL configurations for their app servers and load balancers; people who are paid to think about security do. Your attempt at snark here relies on an apples-oranges comparison.

mapgrep 15y ago
If the institution chooses an insecure password policy, it heightens the likelihood it will fail to ensure good SSL settings. This tendency is independent of the fact that these functionalities are implemented by different teams, and that one team might happen to be competent enough to do the right thing despite the lack of institutional imperative. So the consumer might get lucky. So what? Your initial comment was that "plenty of financial institutions" do SSL a certain way, and the respondent correctly pointed out that this fact adds no information to the discussion about SSL techniques, because plenty of financial institutions do dumb things. It's "apples and oranges" only insofar as he's saying the orchard manager is a poison spreading dummy so you can't trust the apples or the oranges. Maybe you can elaborate on the "studied" part of your comment with specifics. That part was interesting.
- tptacek 15y ago
  You use this word "the institution" as if companies were hive minds. Read the other comments on this thread. Again: the people who make decisions about password complexity are almost never the security people.
  - mapgrep 15y ago
    Exactly. You shouldn't trust a particular technique just because a financial institution uses it. They have very little institutional culture around security, as you yourself point out. So I'm not sure why you brought up the fact that financial institutions use a particular SSL technique - that tells us nothing.
    - tptacek 15y ago
      Your argument is exasperating, because I already addressed this notion that password complexity requirements in banking apps have anything to do with what financial security people think are best practices for SSL/TLS.
      - mapgrep 15y ago
        I still have no idea why you keep bringing up the finance industry - it brings no credibility to this discussion or your points, which seem reasonable enough. Even the "security people" taken collectively have no keen track record so why are we talking about them collectively, again? No big deal, I just don't get it. Shrug.
thirsteh 15y ago
Of course, in a perfect world, developers would be paid to think about security.
chc 15y ago
I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.
- tptacek 15y ago
  The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build badly. Can you guess how much it costs to revise password storage and UX for tens or hundreds of applications?
  - khafra 15y ago
    Interesting. If financial institutions routinely succeed at operational security but catastrophically fail at having a secure development life-cycle, is that a startup opportunity?
    - m0nastic 15y ago
      I don't know about "startup opportunity" specifically, but it's pretty much the raison d'être for most application security consultancies. Usually when first engaged, you deal with operational issues (making sure all the applications they know about are assessed), but as you build on that, you try and instill secure development practices (so that every new application they build doesn't have the same issues as the ones you've just spent months uncovering). The number of large clients I work with who don't have any SDLC process is staggering (I'd say it's the overwhelming majority of them). For the most part, the small group of security people are tasked with trying to secure the multitudes of applications which in many cases are 20-30 year old codebases. Their developer groups may be completely separate (usually from the result of all the mergers of financial institutions) and it's basically all fiefdoms. As you start to work up the pyramid of enterprise security "hierarcy of needs" you get to things like a secure development life-cycle, but not all organizations are "ready" yet for that type of work. Some are just trying to figuratively stop the percieved bleeding.