Cobol - Re: Passwords

Author

Re: Passwords

Robert Wagner

2005-03-19, 3:55 am

On Fri, 18 Mar 2005 16:23:43 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>The problem with passwords is a serious problem. We can't use passwords that
>are easy to remember, and we can't write them down and post them next to our
>computer. What happens is often people go to a site that wants a password, and
>they try a dozen variations of their user-id until they get one that hasn't been
>used at that site before, log on, get a password, forget it, and repeat next
>time they need to go there. Or if they can, they use the same password
>everywhere. (I wonder how many sites have been created that are designed to
>harvest such passwords).

Software that's serious about security can't harvest your password
because it doesn't know your password. All it knows is a one-way
encrypted version. Unix is like that. Everyone can read the passwd
file but it's practically impossible to determine the cleartext
password. Java offers similar encryption using MD5 and SHA-x.

Homegrown security written by applications programmers is always a
joke. I wish I had a dollar for every time I've seen a User table or
VSAM file that had userids and passwords in the clear.

If a Web site can email your password when you click on Forgot
Password, it's not serious about security. Your cleartext password is
sitting in a database somewhere. A secure site will reset your
password to a random number, send that in a link and invalidate it
after the first use, which required you to choose a new one.

Biometrics (DNA, retina, fingerprint) and implanted chips can be
forged easily if they're sent across an unencrypted network.

Howard Brazee

2005-03-22, 3:55 am

On 21-Mar-2005, l.willms@jpberlin.de (Lueko Willms) wrote:

> I had written a database application (not in COBOL) for a site with
> 4 to five users, also installed the Windows network, and configured
> the passwords to be changed at least every 90 days.
>
> One of the people there used to toggle between 2 different
> passwords, and she kept them on a little index card in the top drawer
> of her desk ...
>
> What can you do ...

I don't know. But the industry needs to recognize that the system doesn't
work. MicroSoft has the power to do something about it, maybe by coming out
with a keyboard that has a thumb-print reader and including some standard ways
of producing verifications using this that can be easily incorporated by web
sites. The hard part would be allowing it to work from various computers, but
that isn't a necessary condition.

docdwarf@panix.com

2005-03-22, 3:55 am

In article <9TJmUmnPflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:

[snip]

> I had written a database application (not in COBOL) for a site with
>4 to five users, also installed the Windows network, and configured
>the passwords to be changed at least every 90 days.
>
> One of the people there used to toggle between 2 different
>passwords, and she kept them on a little index card in the top drawer
>of her desk ...
>
> What can you do ...

One of the sayings I was taught was 'You can make something foolproof...
but not damned-fool proof' and another was 'When you think you have made
it foolproof someone will build a better fool.'

DD

Howard Brazee

2005-03-22, 3:55 pm

On 21-Mar-2005, docdwarf@panix.com wrote:

> One of the sayings I was taught was 'You can make something foolproof...
> but not damned-fool proof' and another was 'When you think you have made
> it foolproof someone will build a better fool.'

Unfortunately, damn-fools do exist and need to be accounted for when security is
an issue.

Michael Wojcik

2005-03-22, 3:55 pm

In article <1111460663.843330.300120@z14g2000cwz.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
> Microsoft is the _problem_ not the solution. Unix had expiring
> passwords and other mechanisms decades ago.

Expiring passwords are part of the problem, not a solution. Expiring
passwords make authentication more cumbersome for users, which is a
bad thing (because it discourages secure practices) unless there's
significant security benefit; they make it much easier for users to
forget passwords, or to try to use memorable (and thus often guess-
able) ones; and in practice they've been shown to greatly increase the
opportunities for various social-engineering attacks. For example,
IT help desks in organizations with password-expiration mechanisms
are often swamped with password-reset requests (particularly if all
passwords across the organization expire simultaneously), and so do
little or nothing to verify them.

> MS barely requires passwords

True. Microsoft's reluctance to implement any sort of security in
the "home" editions of its OS has done no one any favors.

> and implements them badly.

While I rarely defend Microsoft on security matters, the current MS
password-based authentication mechanisms are better than the ones
used in many extant Unix systems. Windows has a standard mechanism
for network authentication which doesn't require flowing the secret,
for example.

Ack. Biometrics are most definitely not the answer, at least not at
this time (and probably never, for many applications). They have an
abysmal track record. Attacks against them have nasty side effects
(who wants to lose a finger so that someone can impersonate them?).
They make revocation ... complicated.
[color=darkred]
>
> SSL ?

SSL itself doesn't include a verification mechanism per se, but it
does have provision for using standard verification mechanisms like
X.509 certificates in a PKI. SSL with bilateral certificate-based
authentication is a workable system, assuming decent PKI and
certificate hygiene. And X.509 certs let you use decent-length
passphrases instead of idiotically-short passwords.

--
Michael Wojcik michael.wojcik@microfocus.com

Americans have five di

vantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride

Howard Brazee

2005-03-22, 8:55 pm

On 22-Mar-2005, mwojcik@newsguy.com (Michael Wojcik) wrote:

>
> Ack. Biometrics are most definitely not the answer, at least not at
> this time (and probably never, for many applications). They have an
> abysmal track record. Attacks against them have nasty side effects
> (who wants to lose a finger so that someone can impersonate them?).
> They make revocation ... complicated.

Maybe smart card readers. At least something better than passwords. Do you
have some suggestions?

Michael Wojcik

2005-03-23, 3:55 pm

In article <d1prgk$p9o$1@peabody.colorado.edu>, "Howard Brazee" <howard@brazee.net> writes:
>
> On 22-Mar-2005, mwojcik@newsguy.com (Michael Wojcik) wrote:
>
>
> Maybe smart card readers. At least something better than passwords. Do you
> have some suggestions?

Well, passphrases are already better than passwords. That would be
suggestion number one. Passwords are well-understood; passphrases
improve on them.

If you're looking for something other than passphrases, I'm not sure
I have anything so specific as a suggestion. Tons of stuff has been
written on this topic; I've read a bunch, but certainly not a majority
of it, and my conclusion is that there is no silver bullet (which is
probably not a surprise). No approach is best for all applications;
I don't even think there's any approach which is generally better than
the alternatives for most applications.

As Bruce Schneier says, there are three sources of authentication
information:

- something you have (eg a physical key)
- something you know (eg a password)
- something you are (eg biometrics)

The third is actually a combination of the first two, in some ratio,
with some additional restrictions. For example, a thumbprint is
"something you have", but it's impractical (from the user's point of
view) to transfer or revoke. A signature is a combination of
"something you have" (the unconscious quirks and aspects of your
body that lead you to sign your name in a particular way) and
"something you know" (how you prefer to sign it), but it's possible
for a trained attacker to duplicate it without actually getting
possession of the "something you have" aspect.

That's one reason why biometrics are largely unsuccessful; they just
try to find a technology in the body that serves the roles played by
other, non-biometric authentication technologies.

So, if we drop the "something you are", we're left with "have" or
"know" or a combination of the two. Smartcards typically use both.
That's useful for defending against attacks, but it leads to more
failure modes ("I'm on vacation and don't have my smartcard with
me"). And increased failure modes almost always improve the chances
for social engineering attacks against security administrators; the
more administrators get legitimate requests to bypass security, the
more they're likely to honor illegitimate ones.

And, of course, as soon as you add a physical token you increase your
infrastructure costs, usually significantly.

While there are definitely many applications where the threat model
justifies the increased cost and fragility of adding a physical token
like a smartcard, for ordinary login purposes I'm not very keen on
them.

Also, note they do nothing to address a lot of the more probable
attacks against, say, a company's internal network. First, most
attackers are insiders, so they'll already have authentication;
they're more likely mounting privilege-escalation attacks. Second,
smartcards don't help if an authenticated user's system is compro-
mised, which is far more likely an attack against the typical
Windows user. An attacker who has remote control over a machine
that's already authenticated and connected to the network doesn't
care how that authentication was achieved. Third, as I noted above,
they don't help against social engineering attacks, which are the
most successful class of outsider attacks.

--
Michael Wojcik michael.wojcik@microfocus.com

They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James

Sponsored Links