Putting passwords in a properties file?

[Mike Schilling]

Which is absolutely not a good defence. "pa55w0rd" and "password1",
which are the kind of thing this rule usually engenders, are not a
lot more difficult to guess than "password" - it's a small
constant-factor increase in the amount of work a password cracker has
to do.
What would really make a difference is expanding password boxes to 200
characters (FSVO '200'), and telling people to use whole phrases. "I
used to use weensy passwords but now use humongous ones" is going to
take a very long time to guess.

At which point people, will, in self-defense, put their plaintext passwords
into disk files, so that they can cut and paste them.

 

[Lothar Kimmeringer]

For web based apps I don't know why using personal certificates never
caught on. If a browser vendor made it easy to generate the
certificates, then we wouldn't need all this password stuff.

In a One Man One PC world this is practicable but as soon as you
work with more than one PC - let alone smartphones - you try
that once and never again if the service in question is of
minor importance.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lothar Kimmeringer]

it is a good idea and standard solution to write in config file
not a password self , but his controll summ, hash number etc etc.

It's much more convinient to use.

Problem is that databases etc. don't accept hashes of passwords
but only the real stuff.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Dave Searles]

Basically because there isn't any standarised system to manage and back
up such certificates nor any way to transparently take them with you
when you move to another computer.

A system based on some kind of USB token / USB stick would be suitable,
I think, but suffers the catch-22 that they wouldn't be very useful
until they were widely adopted by the industry and that they wouldn't
be likely to be widely adopted until they were very useful.

There's also the problem that certificate signing authorities charge
money, and not just a small amount of it, and not just a one-time fee
either.

If self-signed certs were allowed, that problem would go away and so
would the how-to-start-over and how-to-isolate problems. Self-signed
certs would be pseudonymous identities, and it would be feasible to use
different ones at different sites if you decided it was none of site A's
beeswax that you also used site B or whatever.

 

[Lothar Kimmeringer]

What about Base 64 encoding of the hash?

That wouldn't change anything. We're not talking about
password a server-application expect from others while
they authenticate themselfs to the server but the server
needs to authenticate itself to some other process (e.g.
the database working in the backend). So you need the
real password to be able to do so.

A hash is a one way function, i.e. after hashing a password
(or any other value) you have no way to calculate the
original passwort out of a hash, so if you only have a
hash-value it doesn't matter if you send it to the peer
as raw data, base-64-encoded or with caramel-flavor, the
authentication will fail.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Arne Vajhøj]

Problem is that databases etc. don't accept hashes of passwords
but only the real stuff.

That is not a problem - it is the entire point in using hashes - if
the client send the hash to the server, then it is storing the
password unhashed in the database.

Arne

 

[Arne Vajhøj]

Which is absolutely not a good defence. "pa55w0rd" and "password1",
which are the kind of thing this rule usually engenders, are not a lot
more difficult to guess than "password" - it's a small constant-factor
increase in the amount of work a password cracker has to do.

The effect is still exponential related to length.

Arne

 

[Arne Vajhøj]

As Tom explained, the salt does not make any single password harder to
crack, but it does slow down an attack aimed at getting all (or the
first) dictionary-vulnerable password.

I was thinking in terms of protecting a particular targeted account
(yours, say, or the superuser account), while you two were apparently
thinking more of protecting all of the accounts in some statistical sense.

No no no.

The use of salt makes all dictionary attacks more difficult, because
it invalidates pre-calculated dictionaries.

Use of different salts per user makes it more difficult to find
one among many passwords.

Arne

 

[Arne Vajhøj]

The point is that without a salt, you can make one pass through the
dictionary and recover *all* the passwords in the file:

for word in dictionary:
hashedWord = hash(word)
for username, hashedPassword in passwordFile:
if (hashedPassword == hashedWord):
print username, hashedWord # pwned!

Whereas with a salt, you need to do a different computation for each user:

for word in dictionary:
for username, salt, hashedPassword in passwordFile:
hashedWord = hash(word, salt)
if (hashedPassword == hashedWord):
print username, hashedWord # pwned!

Note that in the former case, the hashing operation is inside the word
loop; in the latter, it is inside the loop over the passwords. If you
have w words and u users, then the former is O(w) to crack all users,
whereas the latter is O(w*u) to crack them all. Correspondingly, the
time taken to crack any one user is something very vaguely like O(w/u)
in the former case, and O(w) in the latter.

You use of big-O is rather unconventional.

But we understand the point.

Very important: you logic assumes different salts per user. That
is good practice. But I think it should be emphasized.

Which means that Alexandre's challenge is actually rather silly. Adding
salt doesn't make any single password more secure, it makes the
population of passwords more secure. If he's giving us a single password
to work on, then the salt will make no difference.

The use of salt makes all dictionary attacks more difficult, because
it invalidates pre-calculated dictionaries.

Use of different salts per user makes it more difficult to find
one among many passwords.

Arne

 

[Dave Searles]

As Tom explained, the salt does not make any single password harder to
crack, but it does slow down an attack aimed at getting all (or the
first) dictionary-vulnerable password.

I was thinking in terms of protecting a particular targeted account
(yours, say, or the superuser account), while you two were apparently
thinking more of protecting all of the accounts in some statistical
sense.

[says I'm a liar]

Whaaat? Nonsense.

The use of salt makes all dictionary attacks more difficult, because
it invalidates pre-calculated dictionaries.

Moving the hashing of the dictionary out of the loop only occurs when
there's a loop (multiple passwords being attacked) to move it out of.
It's that move that salting makes impossible.

 

[Arne Vajhøj]

Whaaat? Nonsense.

It is true.

Moving the hashing of the dictionary out of the loop only occurs when
there's a loop (multiple passwords being attacked) to move it out of.
It's that move that salting makes impossible.

It is:

no salt =>

for username, hashedPassword in passwordFile:
word = lookup_in_internet_database(hashedPassword)
print username, word # pwned!

same salt for all users =>

for word in dictionary:
hashedWord = hash(salt, word)
for username, hashedPassword in passwordFile:
if (hashedPassword == hashedWord):
print username, word # pwned!

different salt for each user =>

for word in dictionary:
for username, salt, hashedPassword in passwordFile:
hashedWord = hash(word, salt)
if (hashedPassword == hashedWord):
print username, word # pwned!

Arne

 

[Eric Sosman]

The effect is still exponential related to length.

Don't you mean "polynomial" instead of "exponential?"
The number of possible passwords of length N from an alphabet
of size R is exponential in N, but only polynomial in R.
Increasing from R to R+r gives polynomial, not exponential,
growth. To get exponential growth, lengthen the password from
N to N+n symbols.

 

[Arne Vajhøj]

Don't you mean "polynomial" instead of "exponential?"
The number of possible passwords of length N from an alphabet
of size R is exponential in N, but only polynomial in R.
Increasing from R to R+r gives polynomial, not exponential,
growth. To get exponential growth, lengthen the password from
N to N+n symbols.

You are correct.

My mistake.

Arne

 

[Lew]

[says I'm a liar]

Whaaat? Nonsense.

What is nonsense is to claim that Arne Vajhøj said you were a liar.
That's a lie; he did not say that, "Dave Searles". I realize this is
pointless to point out, but claiming that someone made a mistake is
not claiming that they lied. Claiming that someone made an incorrect
statement is not /ipso facto/ saying that they're a liar. This is
normal English, so presumably you knew that, therefore you lied when
you claimed that Arne Vajhøj said you were a liar. What he did was
claim that you were incorrect without any attribution of malice to you
at all.

It is certainly true that a person can speak in good faith, ergo not
lying, and still speak falsehood through ignorance, misunderstanding
or even typographical error. I know I've made many statements here in
this Usenet forum that other people have corrected. I knew they did
not accuse me of lying - the beauty of that is that I was able to
learn from the correction and obtain a better understanding. You
should try that, "Dave Searles", assuming you are humble enough to
admit that you still have something left to learn.

 

[Lew]

You are correct.

My mistake.

Thank you, Arne, for demonstrating how a person can take correction
without thinking that someone accused him of lying. You learned
something, and so did everyone reading this thread.

You are a true asset to the Java programming community.

 

[Ken]

It is true.


It is:

no salt =>

for username, hashedPassword in passwordFile:
word = lookup_in_internet_database(hashedPassword)
print username, word # pwned!

same salt for all users =>

for word in dictionary:
hashedWord = hash(salt, word)
for username, hashedPassword in passwordFile:
if (hashedPassword == hashedWord):
print username, word # pwned!

different salt for each user =>

for word in dictionary:
for username, salt, hashedPassword in passwordFile:
hashedWord = hash(word, salt)
if (hashedPassword == hashedWord):
print username, word # pwned!

Arne

If the system has proper file system security in place and they still
manage to get to the hash file then we must assume that the salts will
be known too (unless they are on yet another system). It would be a
very good idea to set up some sort of tripwire to set off the fact
that someone has read your hashes.

I think simple is best. There is nothing wrong with clear text
passwords stored on a system that has good file security, few admins,
few but well known and well tested network services AND is physically
secure. The last part can't be overlooked. This will sound a little
extreme but if you want to talk about "hacked" think about how long it
would take to get into your personal system using someone else
computer and just your wits... now think about how fast it would be
with a fire axe starting at your front door. In most cases the second
is more practical.

Protecting the password file in the ways described is a good thing but
if you consider the security measures that have all ready failed to
allow this, why not just assume that the attacker has write access too!

 

[Dave Searles]

You are correct.

You are both correct.

"Leet" substitutions like "pa55w0rd" polynomially increase the search
space by increasing R. Things like "password1" appending random digits,
concatenating more than one word, etc. increase the search space
exponentially by increasing N (assuming longer suffixes may be used,
e.g. "password117", and longer chains of words).

The best defense is still random alphanumeric chars; that gives you the
fastest exponentially-growing search space for a given number of
characters. It's the "all suffix, zero dictionary words" limiting case.

 

[Dave Searles]

You are correct.

My mistake.

[gratuitous personal attack deleted]

Bite me.

 

[Dave Searles]

[misquotes me]
Hey!

Whaaat? Nonsense.

It is true.

No, it is not; I am NOT a liar.

It is:

no salt =>

for username, hashedPassword in passwordFile:
word = lookup_in_internet_database(hashedPassword)
print username, word # pwned!

same salt for all users =>

for word in dictionary:
hashedWord = hash(salt, word)
for username, hashedPassword in passwordFile:
if (hashedPassword == hashedWord):
print username, word # pwned!

different salt for each user =>

for word in dictionary:
for username, salt, hashedPassword in passwordFile:
hashedWord = hash(word, salt)
if (hashedPassword == hashedWord):
print username, word # pwned!

Arne

I don't consider "no salt" and "same salt for all users" to be
meaningfully distinct. "Same salt for all users" is really just "no
salt" with a slightly different hashing algorithm.

 

[Dave Searles]

Arne Vajh�j wrote:
Dave Searles wrote:
markspace wrote:
Dave Searles wrote:
It seems to me that if you have the hash and the salt, and know the
algorithm for convolving the password with the salt, then you can
still carry out a dictionary attack.

A dictionary attack pre-computes the hash, and then just scans the
password file for a simple string match. The salt defeats this,
because each bit in the salt doubles the storage needed for the
dictionary.

<http://en.wikipedia.org/wiki/Salt_(cryptography)>

You're right in that if the password itself is weak and could be
guessed, then all bets are off.
As Tom explained, the salt does not make any single password harder
to crack, but it does slow down an attack aimed at getting all (or
the first) dictionary-vulnerable password.

I was thinking in terms of protecting a particular targeted account
(yours, say, or the superuser account), while you two were apparently
thinking more of protecting all of the accounts in some statistical
sense.

[misquotes me]

Hey!

It is true.

No, I am NOT a liar.

I don't consider "no salt" and "same salt for all users" to be
meaningfully distinct; it amounts to a mere difference in the hashing
algorithm, and not one that makes one of them noticeable slower to apply
than the other (one extra add or xor operation).

I think simple is best. There is nothing wrong with clear text
passwords stored on a system that has good file security, few admins,
few but well known and well tested network services AND is physically
secure. The last part can't be overlooked. This will sound a little
extreme but if you want to talk about "hacked" think about how long it
would take to get into your personal system using someone else
computer and just your wits... now think about how fast it would be
with a fire axe starting at your front door. In most cases the second
is more practical.

Leaves more evidence and is a greater crime though; now you're on the
hook for B&E and larceny (assuming you took just the hard drive out of
the case, to mount on your own system) or even grand larceny (if you
took the whole b0x, and it was worth over a grand).

Least-intrusive there is to break in with a Knoppix CD, reboot the
targeted machine from that disc, mount the hard drive, and read stuff as
the Knoppix superuser. Still involves B&E and trespassing as well as the
one constant in all of this, cyber-intrusion.

Upshot: if the machine is not physically secure, relative to how
ruthless and willing to physically show their faces you think your
enemies might be, encrypt the fucking hard drive.