Security Basics mailing list archives
Re: Password alternatives
From: John Morrison <john.morrison101 () googlemail com>
Date: Thu, 1 Apr 2010 15:06:50 +0100
Ansgar, Thank you for your comprehensive contribution to this discussion.
Unlike passwords, biometrics do have the problem of False Accept Rate (FAR) and False Reject Rate (FRR). As for tokens, AFAIK they rely on their algorithm remaining secret, which in terms of cryptography is bad design as it violates Kerckhoff's Principle. As long as the algorithm remains secret they'll probably be reasonably secure, though. They also have the advantage that the user has a piece of hardware, whose loss (hopefully) won't go unnoticed.
I'm not an expert on tokens. As you point out security algorithms (encryption) are best based on known and well tested algorithms. RSA is a well tested algorithm and known to be affective. I don't know if RSA (Rivest, Shamir and Adleman) is a published algorithm (like DES) that anyone can implement and can be tested more thoroughly than "black box" tests allow. IMHO it has proven itself. Poor algorithms are often proprietary and poorly tested. For example, MiFare. However, even strong algorithms can be poorly and weakly implemented. For example, MS using the same key for every installation of Windows NT to encrypt passwords which allowed the development of Rainbow tables. Also, "WEP is an implementation of the RC4 algorithm. The RC4 encryption technique is strong enough, but a weak implementation in 802.11 meant it was only strong enough to protect against casual eavesdropping." (http://reactos.ccp14.ac.uk/MDC_Evolving_Standards.pdf) On 31 March 2010 08:32, Ansgar Wiechers <bugtraq () planetcobalt net> wrote:
On 2010-03-30 John Morrison wrote:Biometrics and tokens are useful. They are more like a physical key and it is easier to explain about why you should not share.Unlike passwords, biometrics do have the problem of False Accept Rate (FAR) and False Reject Rate (FRR). As for tokens, AFAIK they rely on their algorithm remaining secret, which in terms of cryptography is bad design as it violates Kerckhoff's Principle. As long as the algorithm remains secret they'll probably be reasonably secure, though. They also have the advantage that the user has a piece of hardware, whose loss (hopefully) won't go unnoticed. However, in either case I'd suggest to not ditch passwords/-phrases entirely, but to use mixed authentication of password and biometrics and/or token.Passphrases are much better than complex passwords. They are difficult to guess and crack, and they are easier to remember.Although passphrases are easier to remember, the "harder to guess and crack" is something I'm not entirely convinced of. Usually I see this claim being based on the assumption that an attacker will treat passphrases as a string of characters, just like passwords. But what if we consider both passwords and passphrases as strings of tokens? Passwords are constructed of character tokens, whereas passphrases are constructed of word (and perhaps interpunction) tokens. Basically the number of tokens available (n) and the number of tokens used (k) define the total amount of available passwords/-phrases (n^k), and thus the strength of the password or -phrase. If we consider this, a 5-token passphrase will still be more secure than a 5-token password, because the number of characters readily available through a user's keyboard (n[password]) will usually be around 100 characters, while the number of words in a language (n[passphrase]) exceeds this by several orders of magnitude. However, a 5-token passphrase with a total length of 20 characters will *not* have the same strength as a 20-character password, even though both of them consist of 20 characters. The strength of a passphrase will be reduced further, if we take proper grammar rules into account, as that will restrict which tokens can be used at any given position. I don't have any numbers how much this effectively would affect the strength of the passphrase, so if anyone knows of a paper or study on this matter, I'd be very much interested. People sure will argue that one can always "salt" a passphrase with some whitespace or special characters. However, keep in mind that an attacker usually doesn't need to attack a particular account, but can go for the weakest link. All of this said, passphrases most likely still are preferrable over passwords. They just may not be as secure as people think they are.If someone can't remember something they WILL write it down. Once written down no technical skill or hacking time is required to break in. A bit like leaving your safe combination taped to the front of the safe.I disagree, as this entirely depends on how that written-down password is handled. http://www.schneier.com/blog/archives/2005/06/write_down_your.htmlI would suggest that you talk to the senior staff and find out what they want (share what with whom) and what specific issues they have with the current system. Then work towards meeting their and your requirments.Make clear to them that shared access can be implemented without having to share passwords. Also mention that sharing passwords does effectively thwart accountability.Education is the most effective method.I'd say education is the only effective method. Otherwise you'll end up with weak passwords (or phrases), even if you enforce a minimum length of 20 characters. Or would you really consider a password FirstnameLastname001 to be secure in any way? Regards Ansgar Wiechers -- "All vulnerabilities deserve a public fear period prior to patches becoming available." --Jason Coombs on Bugtraq ------------------------------------------------------------------------ Securing Apache Web Server with thawte Digital Certificate In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates. http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1 ------------------------------------------------------------------------
------------------------------------------------------------------------ Securing Apache Web Server with thawte Digital Certificate In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates. http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1 ------------------------------------------------------------------------
Current thread:
- Re: Re: Password alternatives ylev26 (Apr 01)
- <Possible follow-ups>
- Re: Password alternatives Ansgar Wiechers (Apr 01)
- Re: Password alternatives John Morrison (Apr 01)
- Re: Password alternatives Ansgar Wiechers (Apr 01)
- Re: Re: Password alternatives ylev26 (Apr 15)
- Re: Password alternatives Ansgar Wiechers (Apr 15)