Provident Funding: Providing you with a false sense of security

Update: 12/28/2016

I'm not sure when it happened, but I noticed that Provident Funding now supports mint.com integrations! They also seem to have changed at least a couple of the other issues I complained about here. Yay!

Original Post

As a software developer for web applications, I take a keen interest in Internet Security. One of the more interesting aspects of this field is that there are some practices intended to make a site more secure, which don't always actually improve security. At best, these practices are an unnecessary burden to the user. At middling, they'll give the user and the provider a false sense of security, and make them less likely to notice other, more important issues. And at worst, they'll actually cause a user to compromise his security more by creating workarounds to byzantine policies.

A classic example is password strength rules. For those with enough training in information technology, this simple comic is enough to explain why the password strength rules used by most websites have trained most people to come up with passwords that are hard to remember, but easy to hack.

And in fact, the whole concept of a password is fundamentally flawed: every time you log in, you have to enter your password. That means that any time you use a computer that might have had a keylogger installed, or any time you enter it while someone might have been looking at your fingers, or a video camera might have caught your fingerstrokes, your password is potentially compromised. The very act of entering a password represents a security vulnerability in and of itself. We just haven't figured out a better solution that's convenient enough to work for most people.

I think the standard minimum password length for most websites I've seen recently has been 8 characters, but they insist on you mixing numbers, symbols, and upper- and lower-case letters. The problem is that most people choose ways of adding these elements that are dead simple for a hacker and his tools to guess. So they hardly add any difficulty at all if someone is trying to guess your password. At the same time, 8 characters isn't really enough to prevent the types of attacks that these rules are trying to prevent. This topic is worth an entire blog post of its own.

But as bad as that is, there are occasionally even worse cases. For example:

1. Until a couple of years ago, American Express's website limited peoples' passwords to 8 letters. You couldn't create a longer, stronger password even if you wanted to!
2. I once asked the company handling HR for an employer to send me my username, because they'd used an auto-assigned username that I could never seem to remember. A kind lady there sent me an email with both my username and my password in it. And this was the company handling my paychecks! This was at least three strikes against that company all in one go: 
1. It implies that the company stores passwords in a way that it's possible to retrieve them. 
2. It means that the people working for this company have the ability to see these passwords (not just have them automatically sent to users, but actually see them.)
3. Email is not secure, and should never be used to send passwords (except possibly a temporary, random password that you're required to change within a time limit.)

When people managing a web application are making decisions about their security policies, they need to think very carefully about them. Even policies that seem like they'll make things more secure might encourage worse security practices. For example, if you make users change their password every few months, they're most likely going to do one of the following:

1. Stop using a decently unique password that they would have remembered through muscle memory, and switch to using an easy-to-guess pattern, so they don't have to keep trying to think up a new one every three months. Variants of spring/summer/fall/winter are very common in this case.
2. Keep using the same basic password, but change it in a predictable way. (e.g. add 1 to a number at the end every time they have to change it)
3. Put their passwords on a sticky note next to their monitor, at least for the first week or two. (Many people do this anyway, but they'll be far more tempted if they're constantly being forced to come up with new passwords.)

Any time you introduce a procedure that gives the illusion of added security, without actually causing things to be more secure, you create a false sense of security, which can be dangerous. I'd like to highlight some of these false security procedures that are practiced by Provident Funding, a loan servicer:

1. They stopped allowing users to connect their Mint.com accounts to their Provident Funding accounts. They claim that this is to improve the security of their customers because they don't have any control over what happens to that information once it enters Mint.com.
1. This might be a valid concern for their customers, but not for the company itself. After all, the company doesn't have power over what users do with their own information that they view on their website either. There's nothing stopping those users from downloading all their statements and sending them to Nigerian con artists, if that's what they choose to do with their own data. 
2. They used to have this connection to Mint.com. Are they trying to say that they were not secure before?
3. Mint.com is owned by Intuit, who also provides such products as Quicken and TurboTax. Do you really think that their security practices are going to be anything less than impeccable?
4. Most users don't actively manage their loan accounts from month to month. In other words, if they could see that they're payments are on track each month using a read-only service like Mint.com, they'd almost never have to actually log in to Provident's website. By forcing users to log in more often, Provident provides that many more opportunities for bad-guys to capture your password. If a bad-guy gets access to Mint.com credentials, they can see what a user spends their money on, but if they get access to  Provident credentials, they can do more useful things like change billing addresses and who-knows-what-else.
2. Provident forces users to change their password every six months. As mentioned earlier, the practical value of this practice is questionable. But it truly becomes a false security practice when they allow users to reset their password to the same value as before. The site acts like it's got a security procedure, but all it really does is force a user to enter their password a bunch of times. Remember what I said earlier about the very act of entering your password? Yeah.
3. When changing their password, the user is required to enter their username and password again. I understand requiring the password, but the username is prominently displayed at the top of the page, so asking people to enter it again is completely useless from a security perspective.
4. Provident's password requirements are pretty close to the same as most websites, as mentioned above, except that the symbol character must be one of the following: !@#$-_. So rather than making the password harder to guess, this actually makes the hacker's job easier: he no longer has to worry that every character might be any symbol--he can now assume that one (and for 99% of users it'll be only one) of the password's characters is one of only seven possible values. 

Now, I appreciate that in some areas, they do adhere to some real best-practices. They don't send your statements to you in an email, for example. But when it comes to false security practices like those above, I have to wonder:

1. Do they know that these practices are useless, but feel it's important to give users a sense of security just to keep up appearances? If so, that's really annoying and a little dangerous.
2. Do they actually think that these practices have some value? If so, they're inept when it comes to real security, and we have to wonder what true vulnerabilities they left open while they followed these red herrings.
3. Are some of these "security practices" signals that they have some really bad practices underlying their entire site, which they've had to work around? For example, are they failing to encode parameters, so they disallow funny characters in your password because they're afraid of little Bobby Tables? Are they blocking Mint.com because they have no confidence in their technical ability to keep an integration endpoint up and running? If so, we have to wonder whether they've got the technical competence to keep our data safe from real security threats.

I brought up many of these issues in an email directly to Provident months ago, and didn't get a very satisfactory response. Since there appears to be no sign of policy changes at this point, I'm hoping a little public shaming will get the attention of someone who cares. Feel free to share with people who are interested in this sort of thing.