[mapgrep]

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]

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]

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]

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]

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.