Tag Archives: Policy

My Top Three user account design Pet Peeves

Posted on by

In this internet infused world we live in today, it’s not uncommon for user to have to remember several username and password permutations (please note order of characters does matter and thus it’s a permutation not a combination). That being said there are three aspects of the user account design process that really grind my gears.

User Responsibility

This aspect of user account design doesn’t seem to be talked about very often, but it is extremely important. Individuals need to take responsibility for the protection of their usernames and passwords. In fact most web based services clearly indicate as such in their User Level Agreement. That is to say, if someone gains access to your account by means of your username and password permutation, you are responsible for any and all damages. Users need to understand that they are already being held legally responsible for their login information and should take it upon themselves to protect it as if it were any other valuable piece of information.

Secret Username

I grew up online and have watched large web based service provides change their user account design practices over time. Although, most of these changes have greatly increased the general security of user accounts online, I’ve always wondered why changes were never made to user names. In fact usernames have remained almost constant in the online landscape for years. For some reason, early adopters of this authentication model decided that the username should be shared to represent a person online. I personally believe that it is important to have an online identity and that it’s your choice weather to divulge your physical identity alongside a virtual one. This should not require me to log into a web service with such an identity or handle. My username, that I use to log in, should not be public information. In fact I’m a firm believer that it should be treated as if it were a second password. After all, two things you known might not be 2 factors of authenticate, but it is two facts. Web based service provides need to allow users to create usernames that are just as advanced as their passwords. These usernames should not be made public and another method of virtual identity handling should be used. If nothing else, please please stop using email addresses for account login. Email addresses are used everywhere online and are widely known pieces of information and one need only go to the password recovery prompt to see if an email is indeed in use.

Password Complexity

Password complexity is a double edged sword and I hope to make a far more technical and detailed posting about it in the near future. However password complexity, in my mind, has only come about as a method to force users into take more reasonability for their passwords. In a perfect world, a password of all lower case letters or all numbers would be just as difficult to decipher as a password that uses a range of characters. That is to say, if users were truly random in their character selections, the user who chose a password of 33784091 would be just as secure as the user who choose L(k&6hlY, because the available character space did not change. However users are not random and in fact are rather predictable. So our solution is to create a list of rules that a user must follow in order to use a service. This forces a user to create a password that is hopefully harder to guess and crack, but in my experience neither case really holds true. These rules restrict the user by reducing the useable character space and realm of possible passwords. These restrictions alongside the added pressure of maintain a secure posture, all but forces users to reuse old passwords and create ones from common phrases. This undo stress adds predictability to the equation and is at the root of the username and password problem. My solution is a simple one, use the same methodology that is commonplace for usernames. When a user sets or changes a password don’t let them use a password that someone else is already using. In the background, just add what every passwords your organization has deemed weak to the already in use list, just as many already do for usernames deemed inappropriate.

Do you even Policy?

Posted on by

I’m not the kind of person who normally rants, reviews, or rages, but this is an infosec blog and policies are the basis of a strong information plan. That being said there are two policies from two separate companies that have negatively affected my life lately. I figured I would explain why I think these policies need some work.

Before we get into these “failicies”, I’d like to explain what I believe makes a strong policy with four simple rules.  The first part is simple; the policy has to be well defined and accessible. Second, the policy has to be enforceable with a known consequence. Third, the policy needs to be enforced as an approved document by organization leadership. Lastly, the policy needs to be maintained to fulfill an overall all goal, in the most effective way possible.

 The first one has been rage blogged to death, so I won’t dwell on it too much. It’s a Walmart policy, with noble intentions and less than desired, or “fail”, executions. Simply put, if you try to buy alcohol and someone in your party is under the age of 21, they won’t let you complete your sale. I don’t drink and as of this posting I’m not quite 21, so needless to say my friends/family have experienced this policy up close and personal several times.

This policy is well defined and accessible within Walmart’s lengthy list of policies on their corporate website (linked below). I won’t bore you with the details or legal jargon, however it passes first muster from the well defined and accessible standpoint. The second rule however is another story; this policy, however well intentioned, is not enforceable. The simple truth is this policy is now widely known and as such people are more likely to dip out or split orders. These changes in client beehive only lead to line congestion, increased order processing, and more company time, making the bottom line the only thing that’s affected. The policy is clearly enforced by most employees, as I can personally attest, so they pass rule three (enforcement) as well. This policy has not been updated in the roughly 5 months it has been in place, but we will give them a pass here, in hopes that they are hard at work on their policies enforceability.

The second is policy is one that many credit unions have adopted because of the vast amount amounts of fraud coming from the west coast. Although I could not find any documentation on this policy or reasoning, thus knocking out rule one, I believe it stems from the several high profile data breaches in the last year. The policy is essentially to block all transactions over the amount of $100 if it is processed in any state on a flocculating list. Now this is indeed helpful to most people, in helping to prevent fraud and surely saves a lot of money. But after talking to both the credit unions I’m a member of it would seem the system and/or policy is flawed. This is because the only way to get a transaction that would have been blocked to go through is to temporarily suppress all fraud protection on your account. This was hard to hear. Even worse, in most cases you need to call ahead at least one business day before the purchase to get the suppression activated, for a minimum of one business day. This means that ones account is entirely open to attack for a whole day. I was able to talk to account managers about both CU’s and was told in both cases that there is no customization on this policy. Even worse the manager at one location told me it is their policy to activate the same suppression while someone is traveling, which in my opinion is when credit fraud is most likely to occur. The good news is these policies are full heartedly enforced by automated processing system, so we will check the rule number three box. Rule number four is up in the air on this one, some people I talked to said they’re working on making these system more robust and trying to make the policy more customizable to the customers needs. I’m still unsure if they were just trying to get me out of their hair or not. However, because there is some indication of maintaining and improving these polices we will give them a pass on rule four as well. However I feel that these policies are by no means effective at stop fraud and such cases should be handled on a company instead of state basis.

failicies: A word I probably just made up, that refers to a policy(s)

http://corporate.walmart.com/policies