Recently, I forgot my password at a financial site. I tried to remember it, and kept entering it into the fields over and over again until I was locked out. I wanted to pay my bill, so I called the 800-number they had posted online to give them money. 

A nice lady answered the phone and asked me a bunch of questions about things I didn't know. Sure, I was traveling and not near copies of my bill, but at the same time, if I can't answer those same questions to use the automated password recovery system – then most likely, asking me those same questions on the phone won't mean that God's light will shine on my head and I will suddenly have an answer to the questions I couldn't answer 5 seconds ago online.

And this company isn't alone. I've noticed some sophisticated financial sites doing similar things. It's astonishing. Financial sites in general can be intimidating because they are dealing with something highly complex – money – so experiencing additional conflict over the phone just makes the experience with that financial institution worse. The most discouraging part of the call I was on was the person on the phone telling me that all systems are like this. I just let it go and hung up (after paying) to avoid a confrontation, but what I wanted to say was:

1. That's not true – some financial institutions think about their customers more than others. Don't generalize.
2. Most customers don't memorize their account numbers. Sure, there are cards that have this information – but what if someone doesn't have the card on hand and stores it in a safe place at home? People don't always think in numbers.
3. I have to wonder if financial institutions like being paid money. Given how some places act, you have to wonder if they indeed like being paid – but more on that later.

With all this in my head, I had to wonder how the nice lady couldn't understand why I paid off my account that day – amazing! 

That experience got me to think more about password recovery systems and the pitfalls that occur with user security – mainly, a focus on company manufactured information about a user rather than information about the user him or herself. 

I'm not proposing users giving up additional personal information about themselves. In some ways, that's even WORSE security. I mean, does a company really need to know who your favorite teacher was? I'm suggesting that there could be ways to use someone's information in random patterns to confirm an identity and keep that person's data secure. I'm suggesting divorcing account numbers from user data, making it harder to link the two types of content together. These types of approaches may reduce identity theft and allow people to prove their identity in simple ways (rather than to make it harder – which is the trend today).

I know that a lot of this is theoretical and I need to spend time trying this out, but if you think about user requirements to have security that "feels good and easy:" 

• Leverage information that a user will readily know and doesn't need to find paperwork to access
• Stop asking for additional information from a user that could be leaked to supposedly "increase security" 
• Balance security and personal knowledge without the "big brother" feel
• Replace leveraging a data key particular to the company with user data – actually, this may break that connection and make it harder to hack an account – but more on this later.

 

So if a user forgets his password? How would this system work?

• Leverage a randomizer to present different questions about a user to the user – middle name, zip code, home address vs mailing address – Presenting this information at random could be considered a security measure. This would stop 'bots from being successful to break into an account because there would be no pattern to data presentation. It would also deter a hacker from entering data manually – knowing that this is happening would be a lot of work to enter the correct data. And what if a field was missing? There could always be a default key to enter that the user would know. It needs to be thought through more, but it is definitely one approach. 
• Use historic activity to validate identity – What if a system asked if you made a purchase yesterday? Or which swimsuit you bought in the past month? The questions don't have to be about an exact time, and it doesn't necessarily need to be presented as if it were "big brother" (I invite you to share your ideas on that below) – it could be presented as information only you and the company would know. It's personal knowledge. And it is more user friendly – the user would most likely know if he purchased something in the past month MORE than he would know his account number.
• Did you live at this past address? I experienced getting questions like this before. Using a past address you may have for a user is a great form of security (asking which of these addresses did you live at or which one did you not live at – very effective). The chances of a hacker or identity thief knowing that is slim. However, it does border on being "big brother." I'd only suggest that a company uses this if they have the information (rather than discarding past addresses for an account – save them for later use). I mean, you could use past shipping addresses for security as well. And it is something a user would know or be aware.

There are some current trends in security that isn't personal – it is based on the PERSON. I think these trends are intrusive and provide a company or device with too much personal information that could be used against you:

• Fingerprints. There are other body parts/noises that could be used that are particular to a person and more accurate. If you are going to scan a body part, retinal scans are far more accurate. However, why do you need to use a fingerprint to get into your phone? Why is a body part scan required for confirming identity? Does the data really need to be that  secure? What about voice recognition technology or patterns? That's far more accurate too. But to go beyond that argument – using a body part for security is giving additional information over to a company and that data could be stolen and used against you. Sure, it's a paranoid view, but hackers don't think like we do – they think about how to use data to get money. They will find a way to use this against you.
• Linking an account number with a person. This is direct and effective, has history with labelling humans for tracking (won't go to a direct analogy with that), and is easy for a company to manage. However, what do hackers always go for? The list of accounts numbers and names and passwords. If the account number data for a user were disassociated from him and his security information (basically, identity information) and his password – that makes things harder for a hacker. Something to think about.
• Asking a user for additional "security" information. Questions like: what is your favorite color? Where did you go to elementary school? This is to make things easier for the system and a developer, but at the same time, this is additional data to protect. Yes – more security is needed, so what was gained here?

The challenge with these systems is that:

1. A user is giving you more information than you need to keep their data secure
2. You need to enter the information EXACTLY as you entered it in the first place to be "approved." That's NOT user friendly. Users don't remember what they had for lunch yesterday – how would they remember how they entered their first grade teacher's name weeks ago? Mrs. Smith, Smith, Elaine. Or again, an account number for something they use once every few months?

Creating secure environments isn't about just about keeping information safe – it's about creating a balanced, usable environment. Some of the ideas outlined here haven't been tested – I'm presenting these ideas for your consideration to create safe, usable environments. In today's data-filled environment where we have a gazillion passwords, account numbers, and other data points – users need this process simplified. Security is becoming complicated with a lot of risks like identity theft. And the current standards aren't really working if identity theft is continuing to thrive.

What is better for the user and their concerns? I invite you to leave comments and contribute to the conversation.

Limits. I love talking about limits — it is such a controversial subject with no concrete answers. People can always achieve what they put their mind to, so in some ways, limits don't exist; but at the same time, there are some finite limits in our lives – 24 hours in a day, our need to get nutrients, the need for rest and sleep. There are also some personal limits with skill sets and abilities, and these limits are most curious because yes, we are all capable of most anything over time with study and practice, but there is always the lingering question – what can we really do today? Today we all can't do everything well – unless we are beyond gifts. We typically do what we regularly practice well (the 10,000 hour law from Malcolm Gladwell in Outliers) or have natural abilities to do (either innate talents, which I do believe in, or from a past life, a la Shirley MacLaine), but I digress. 

 

Knowing Your Role

It would be more than a surprise if a belly dancer performing with a live band suddenly stopped performing, walked over to the keyboard (or drum or whatever instrument) and took the musician's place while he started to dance. It would be a pleasant surprise if the switch was successful and entertaining; most times, I think the switch would be just make a bad show.

It's the same for an Agile team. If the database guy suddenly stopped his work and started doing UX work, it would be the same experience – a bad one. Everyone does something really well – and that should be respected (see my blog entry on "The Do's and Don'ts of Collaboration"). Sometimes, this doesn't happen and team members get into each other's business, which causes solution quality issues for a project – but that's a whole separate issue and there is a blog entry about that.

Knowing your role on a team is partly about knowing your personal limits, your personal strengths (your knowledge), and how you can contribute best to a group. Not everyone can be the belly dancer in the same way not everyone can be the UX person – and that's what makes a successful project. Everyone's talents are leveraged to achieve a goal.

 

Time and Daily Energy is Truly limited & Limits help you figure out how to make it happen

A dancer can only perform for so long physically for a show – it just can't go on and on for days or hours. And there is the audience attention span to consider (it can't really be more than 20-30 minutes per dancer – people zone out). You can't stop in the middle of a performance – you have to finish it to the end. And the musicians and the dancer both want the best performance possible. The musicians may determine the best song to play that showcases their strengths and the strengths of the dancer. 

Agile is also about knowing your limits. What is an estimation meeting but finding what can be done in a finite amount of time with a team of a defined skillset? You determine the size of a task and its level of difficulty. You openly discuss with your team what is easy and what is hard based on the strengths and weaknesses of the team. You talk about your area of expertise and how you can contribute best. The team works to achieve a weekly velocity (a limit), sometimes trying to surpass it, sometimes just trying to achieve it. The stories are prioritized and scheduled to that velocity/limit. And the business prioritizes tasks, knowing which is most important to get done first. Agile is all about getting as much done as possible within limits. 

Limits help produce the best product/performance in a given timeframe. There is always time to do more later, but you have a set amount of time for delivering something today.

 

Limits Optimize Preparation 

Improv and Agile are about people being prepared rather than following a plan (See Improv and Agile – Part 1). It's about having the self-confidence to know that the goal will be achieved in the timeframe rather than living under the stress of a deadline to achieve a goal that everyone knows is close to impossible to get done. Successful performers rehearse and practice, know there is a performance date, but if they see the performance date as a deadline for the "big performance"- they stress out. This is what new performers do. Seasoned performers see a performance date as a snapshot in time – this is what I am able to share with an audience today. That same performer may go on stage to do the same piece again – or not – it's about what they do at that time based on how prepared they are that day.

The same is true for an Agile project. The team does the best they can in the timeframe based on how prepared they are. They can only do so much research, only do so much per task. It's not about perfection – it's about how good can it be based on what is known in the timeframe to get it to work. An Agile Sprint is truly about a performance by the team to see what can be created for the demo, and shared with the larger group in the company.

 

Without limits, I don't think anything would ever get done. There has to be a day where what people are working gets presented, or shared, with society. Everyone on a team has a role due to personal limits. A team figures out what they are going to do based on their strengths (limits). Sure, we all have infinite potential over a lifetime, but we have a lot of limits so to what will make us successful today.