With everything that is happening (and not happening) in Internet security today, and all its complexity, it is perhaps useful to stop our busy day and take a little time out to start a conversation and question a couple things.
The worst Internet security problem for users today is not email or even about email, however it deeply affects email security. We are talking about the security and usability of Internet user access control systems. This problem is well-known but we meekly accept it "as it is" everyday.
But the paradigm may shift in five minutes. We find that, surprisingly, to tackle this problem we just need to take five minutes to go over five frequently asked questions. And that is our invitation to read the paper and provide your comment at http://email-security.net/papers/takefive.htm
You can also Read the Compact Version
Thank you!
Ed Gerck
Welcome to Email-Security. This is a technical development forum dedicated to a fresh exploration of the Internet email security issues of today, with website at http://email-security.net. Comments and paper contributions on the theme of email security are welcome. Papers will be peer-reviewed before publication. Product and service listings are also welcome, see website.
8 comments:
I looked at the 5 question overview. I'm not sure if I fully understand it -- it seems as if you provide users with identifiers that are far more difficult to guess than name/passwords. Is that the key idea or am I missing something?
(submitted by BF)
(reply to BF)
Yes, their combination is far harder to guess (quite impossible in a lifetime) but very easy to remember:
1. The password is whatever the user chooses, so it should be easy to recall.
2. The "name" is the usercode, something like 56TYPQ. It is fully unpredictable but, because it has 6-characters, previous studies have established that such "names" are very human-usable and even mnemonic For further usability, some letter/numbers are overloaded during generation, so it does not matter for example if you type 0 (zero) or O (capital letter O).
They are also easier (due to the technology) for the often-needed operations of revocation, recovery and reset than username/passwords. And they can also provide spoof prevention (by mutual authentication), which username/passwords cannot.
The most important problem with passwords is forgetting them, or not knowing which is the one to use. Recovery and reset are easily available using the new system, but a better alternative is a self-solution by the user. In the new system, both the usercode and the password can be quickly and correctly typed, or written on paper, and read by humans. This is in contrast to X.509/PKI, PGP or Voltage digital certificates (yes, Voltage/IBE uses long digital certificates), which are very long and also not human-usable (eg, 0 vs O), so that it would be very hard to type, write and read correctly.
This allows users, without any need to use technology (that could be infected, compromised, or bulky) but also potentially using technology, to easily "back up" their usercode and password credentials. [1]
Thanks for your interest. Your feedback will be of great help.
Cheers,
Ed Gerck
[1] Disregard opinions that say users should not write down their passwords (and usercodes). There are security reasons why you should -- for example, to prevent your memory becoming a single point of failure, or the company closing because an employee was hit by the proverbial truck. What matters is that you keep your copy safe. Do NOT put it under your keyboard, Do NOT put it on your monitor, Do NOT put it near your computer, and Do NOT put it anywhere else where you cannot physically control access. This is all quite simple for users to grasp and implement; and much better for companies as copies are inexpensive and can be easily held without technological concerns (eg, outdated readers, expired media) in different physical locations.
(from BF)
The question is what threat are you concerned about. The problem with name/password is also one of management – not just writing it down but avoiding reuse for each service so I presume you’d want an indirect or escrow approach.
Ultimately, as noted in another paper you have, the issue is trust. Even if you get all the password stuff correct how do you know who to trust and avoid being spoofed. Alas, even if you have 100% trust your trusted source can simply be wrong so it is vital to support the “oops” problem.
For high security applications improving the password is important – but it’s only one part of the problem.
(from BF)
(reply to BF)
Your comments are all coherent with what I also think, but those concerns are addressed in other layers. Regarding the paper, the interest is on what can be addressed in that layer. Since username/password systems do not allow a trustworthy outcome in that layer, it is moot to look for what can happen with them in other layers. This is not the case for the ZSentry system, which resembles username/password for usability purposes but does not have their limitations.
Regarding who to trust and avoid being spoofed, this is a big hidden problem for example in US DoD systems using digital certificates with X.509/PKI. DoD-speak likes to talk as if certificates bind keys to persons (ouch!):
"Certificates identify the individual named in the certificate, and bind that person to a particular public/private key pair. " in http://iase.disa.mil/pki/index.html
The sentence above contains two of the misconceptions that I often cite. A correct sentence would be:
"Certificates are issued by a Certification Authority (CA), provide identifiers for the entity (e.g., an individual) named in the certificate, and bind those identifiers to a particular public/private key pair."
Certificates do not bind persons but their identifiers (which may be faked, incomplete, ambiguous, etc.). They can also bind a company, a web site, a role function, not just individuals.
While people may 'feel good' thinking that a certificate can actually bind to a person, the reverse is true, as it gives a false sense of security. It's likely that there are DoD operatives using the DoD PKI under false identity (most being probably authorized and desired, as agents, but likely not all).
That's why it is important to define what we trust at every step, because trust is also that which fault can break the system. In the paper, we are at the first step. What can we trust before and after that step? By asking those five simple questions, we hope to offer a "bite-size" approach and shed light on what often seems to be confusing.
Thank you!
Ed Gerck
(reply to BF)
A comment showing how effective dictionary attacks can be.
A researcher who examined 10,000 Hotmail, MSN and Live.com passwords that were recently exposed online has published an analysis of the list and found that “123456″ was the most commonly used password, appearing 64 times.
Forty-two percent of the passwords used lowercase letters from “a to z”; only 6 percent mixed alpha-numeric and other characters.
in http://www.wired.com/threatlevel/2009/10/10000-passwords/
Posted by Mick Talley
I wondering what Ed's comments would be if the access control was role based, with attributes, defining the actors, with field control, audit and time stamp and in context? What happens if the solution has multiple actors and is extended outside of the enterprise to be inclusive of business partners, trading associates, part-time employees and suppliers and to automate the process, a suite of digital credentials?
reply to Mick Talley
The answer depends on whether role-based control and other added attributes will add targets. If they do, those targets become new points for attack, which will decrease security.
Note that even digital certificates, if they disclose the attributes, can also become attack targets -- because an attacker can read these fields and gain information that may be leveraged in an attack (eg, with social-engineering to get a new cert with correct information for cover but with some false information inserted). And the problem with conventional digital certificates remain, as the decrease in usability and increase in cost, which become more important if the solution is extended outside the enterprise.
[Posted by Mick Talley]
Good thought...., as I would add that generally speaking, the access points are attacked or at the "nodes". There are other digital solutions other than "certs" which are cheaper, but in essense the strength of the digital credential should be directly related to the value or risk of the data or application which is being shared across a network or run. This would mean that the data and the application would have to be encrypted at multiple strength levels to reflect the value of the transaction as related to the strength of the credential and reflect the policy at the business level of the enterprise which has determine the risk. But aside from how authentication and authorization is implemented, the key is to focus on protecting the access points or nodes with encryption of both data and applications.
Post a Comment