Home page logo
/

basics logo 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.html

I 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
------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]