Putting passwords in a properties file?
Uli Kunkel
I need to put a password for something as an application parameter.
For now I'm using a properties file but the password isn't encrypted.
I suppose I could encrypt with something and hardcode that encryption
key in the application..
Are there any applications with this purpose?
I'd like to know what are practices of other people?
Thanks in advance for any suggestions.
grz01
I think this is what you're looking for:
Have only used it briefly (for just such purpose) but worked without
problems.
/ grz01
Uli Kunkel
Yes that was exactly what I was looking for.
But I see the problem is in hard-coding the password.
Are there any tricks and suggestions for storing the encryption key?
rossum
wrote:
Who are you trying to protect the password from? There are many
methods suitable for different situations.
One possible method is to store the password as two byte arrays.
Convert the password to an array of bytes. Then generate a second
byte array the same length filled with random bytes using SecureRandom
(not Random). Store the random byte array and the XOR of the two
arrays. If you are using a text only storage medium, such as the
properties file, then you may need to convert to Base64 text before
storing. Consider putting one array in the properties file and the
other array elsewhere.
To recover the password read the two byte arrays. XOR the two
together and convert the resulting byte array back into the origial
text password.
Encryption:
cyphertext <- plaintext XOR key
Decryption:
plaintext <- cyphertext XOR key
Change the second, random, byte array regularly. How regularly
depends on how secure you want things to be. It is probably easy
enough to change it every time the password is used which gives you a
One Time Pad.
Do not call the two stored byte arrays "password1" and "password2"!
For something more secure, keep the decryption key (the random array)
on a USB stick that is removed from the computer and stored in a
locked safe when the password in not needed.
rossum
Xavier Nayrac
>
> I need to put a password for something as an application parameter.
> For now I'm using a properties file but the password isn't encrypted.
>
> I suppose I could encrypt with something and hardcode that encryption
> key in the application..
>
Why use a key ? Why not use an hash (SHA*, md5) ?
--
Xavier Nayrac
Mayeul
Errrm, assuming it would be possible to do, which I doubt, you'd still
just need the hash to gain access.
Doesn't seem to change much, does it?
--
Mayeul
Uli Kunkel
The principle of what you are saying is the same as Jasypt jar...
The problem is in that second byte array because I need to hold it in
the application.
It's a server application so I cannot use a usb stick for holding it.
grz01
Well, ultimately, the application needs to be able to read something
(like the decryption-key) from a storage protected from unauthorized
access.
The simplest(?) way is to put that sensitive information in a disk-
file,
with file-access protection that allows only the owner of the file (or
the superuser) to read it.
And the owner should be the OS-identity under which the application
runs.
In unix/linux, it's something like file-permission:
-r--------
Windows, of course, has some similar (but more complex) corresponding
mechanism,
but I'm not too familiar with that one.
rossum
wrote:
The second (random) byte array is the key. If you want to encrypt the
password, then you need a decryption key somewhere. Whatever
encryption method youuse then you will need a key to decrypt. Even
ROT13 has a decryption key, the number 13.
>It's a server application so I cannot use a usb stick for holding it.
Fine. Then keep it in a file separate from the properties file. The
major point is to keep the cyphertext and key in different places in
order to make it more difficult for any attacker.
rossum
rossum
<xavier___...@gmail.com> wrote:
>Uli Kunkel a écrit :
As I understand the question, this is not a file of user passwords
that are checked when the users log on; for that purpose using a hash
would be correct. This appears to be a password to a back end
application (?database?) that the server is logging on to, and the
server needs to pass the actual password to the application, not a
hash of the password.
For this purpose the ability to decrypt to get back the original text
of the password is essential. Hence the need for a key.
rossum
Lew
What I've tried, but I cannot vouch for the non-hackability of it, is to store
the hash (e.g., MD5) of the password in the file or database. When a user
logs on, I compare the hash of their password to the stored value.
I imagine that a hacker who obtained the stored value would have trouble
reversing the hash to a valid password.
This makes the ability to decrypt to get back the original text of the
password non-essential.
--
Lew
Nigel Wade
I would think it's pretty robust. It's what UNIX does (and maybe has
always done). UNIX doesn't store passwords in the passwd database (or
whatever other database it uses e.g. LDAP). It uses the crypt hashing
function and stores the hash. Any time it needs to authenticate a
password against the hash it crypts the password using the same algorithm
and compares that to the stored hash.
--
Nigel Wade
grz01
> I would think it's pretty robust. It's what UNIX does (and maybe has
> always done). UNIX doesn't store passwords in the passwd database (or
> whatever other database it uses e.g. LDAP). It uses the crypt hashing
> function and stores the hash. Any time it needs to authenticate a
> password against the hash it crypts the password using the same algorithm
> and compares that to the stored hash.
>
> --
> Nigel Wade
No, its not quite what un*x does anymore -- piece-of-cake today to
brute-force the passwd file if you use public pw-hashes.
The pw-hashes must be stored in a protected place (unless you're fine
with "toy security").
See:
jolz
> Are there any tricks and suggestions for storing the encryption key?
I use Zelix KlassMaster with string encryption enabled that makes a
little harder to find the key. But since the key is there to decode the
password I do have class that does this, so the key isn't necessary to
decode the password - finding the right class (obviously obfuscated) may
be easier.
Leif Roar Moldskred
>
> I need to put a password for something as an application parameter.
> For now I'm using a properties file but the password isn't encrypted.
>
> I suppose I could encrypt with something and hardcode that encryption
> key in the application..
>
> Are there any applications with this purpose?
> I'd like to know what are practices of other people?
When I've had to do this, I've worked from the assumption that if an
attacker has access to the property file with the password he's already
on the system the program is running on and has access to everything
the program has access to, including the byte code.
Under that assumption, the determined attacker will always have
(potential) access to the ciphertext, the key and the decryption
algorithm. That means there is no way to make the password
cryptographically secure -- but we can obfuscate it to make it _harder_
for the attacker.
I just put the key in the same property file as the encrypted password,
scrambled with a simple, hard-coded transform to prevent it from being
immediately useable (but nothing that would stand up to a
cryptographic attack.)
If it makes sense for the deployment (i.e. "Will this be maintainable
by the line-organisation?"), I'll put a secondary encryption key into
an enviornment variable with an unassuming name and use that to
encrypt all the primary encryption keys.
This way, an attacker will need three separate pieces: the property
file, the program code (either the source code or the byte code) and
the contents of the environment variable. It's _not_ 100% secure, but
it will stump all incidental attackers and some determined ones.
(On another note, don't put the passwords in the regular configuration
file, but put them in a separate configuration file with nothing but
passwords. The regular configuration files tend to be bandied about
with abandon when someone is having a problem and can end up in all
sorts of places.)
--
Leif Roar Moldskred
Mike Schilling
> On Sep 25, 3:29 pm, Nigel Wade <n...@ion.le.ac.uk> wrote:
>> I would think it's pretty robust. It's what UNIX does (and maybe has
>> always done). UNIX doesn't store passwords in the passwd database (or
>> whatever other database it uses e.g. LDAP). It uses the crypt hashing
>> function and stores the hash. Any time it needs to authenticate a
>> password against the hash it crypts the password using the same
>> algorithm and compares that to the stored hash.
>>
>> --
>> Nigel Wade
>
>
> No, its not quite what un*x does anymore -- piece-of-cake today to
> brute-force the passwd file if you use public pw-hashes.
As illustrated in Cliff Stoll's wonderful _The Cuckoo's Egg_.
alexandre...@yahoo.fr
...
> The pw-hashes must be stored in a protected place (unless you're fine
> with "toy security").
Wait... (my post is apparently unrelated to the OP's problem btw)
I agree that storing {hash} is stupid, but long before
shadow passwords Un*x systems where already storing:
{hash(password+salt),salt}.
(a long time ago it was a lame 12-bit salt, but nothing stops me
nor anyone from using a much bigger salt, which I sure did ;)
Are you saying that storing {hash(password+64-bit salt), 64-bit salt}
without the equivalent of shadow passwords would be "toy security"?
alexandre...@yahoo.fr
wrote:
...
> > No, its not quite what un*x does anymore -- piece-of-cake today to
> > brute-force the passwd file if you use public pw-hashes.
>
> As illustrated in Cliff Stoll's wonderful _The Cuckoo's Egg_.
What the 20-years old book shows is a dictionary attack on a passwd
file that is using no salt.
Modern Un*x distro ('modern' as in "since at least 20 years") are
storing {hash(password+salt),salt} instead of {hash} as I explained
in the other post.
The attack used in the book only works on the most
naive form of password hash storage.
What about you guys all bring your dictionary
attacks/rainbow tables/ terabytes of memory/tables
supercomputers and I publish here in the clear
a cryptographic hash of a password using a 32-bit
salt (and the 32-bit salt used of course)?
Then we'll see if it's "piece-of-cake" and "toy security"
and if 20 years old romance is adapted to modern form
of password hash storage :)
Dave Searles
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.
On the other hand, if the password is something like zs1df3rh, good luck
with that.
Tom Anderson
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.
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.
tom
--
There is no latest trend.
markspace
>
> 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_%28cryptography%29>
You're right in that if the password itself is weak and could be
guessed, then all bets are off.
Roedy Green
>I need to put a password for something as an application parameter.
>For now I'm using a properties file but the password isn't encrypted.
If your program can decrypt the passwords to plaintext, so can any
hacker. Further he can snoop on your socket when the apps sends the
passwords off to some other site. Anything you do to hide the
passwords is just disguising them from casual observation.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Civilisation advances by extending the number of important operations which we can perform without thinking about them."
~ Alfred North Whitehead (born: 1861-02-15 died: 1947-12-30 at age: 86)
rossum
<see_w...@mindprod.com.invalid> wrote:
>On Fri, 25 Sep 2009 09:37:13 +0200, Uli Kunkel <geni...@yahoo.com>
>wrote, quoted or indirectly quoted someone who said :
>
>>I need to put a password for something as an application parameter.
>>For now I'm using a properties file but the password isn't encrypted.
>
>If your program can decrypt the passwords to plaintext, so can any
>hacker. Further he can snoop on your socket when the apps sends the
>passwords off to some other site. Anything you do to hide the
>passwords is just disguising them from casual observation.
The attacker can always find out what the plaintext is by one means or
another. The idea of security is to make it more costly in terms of
resources or time. Ideally the cost to determine the plaintext is
greater than the value to be gained from knowing it.
rossum
senatov
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.
--
Благословляю на добрыя дѣла
☦. Иаков
ඊස
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.
I still think the surest bet is to avoid using dictionary-attackable
passwords. :)
Mike Schilling
>
> I still think the surest bet is to avoid using dictionary-attackable
> passwords. :)
Absolutely, which is why many environments require passwords to contain both
letters and numbers.
Tom Anderson
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.
tom
--
I am the best at what i do.
Mike Schilling
At which point people, will, in self-defense, put their plaintext passwords
into disk files, so that they can cut and paste them.
Kenneth P. Turvey
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.
--
Kenneth P. Turvey <evot...@gmail.com>
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: spam...@kimmeringer.de
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.
Leif Roar Moldskred
>
> 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.
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.
--
Leif Roar Moldskred
Kenneth P. Turvey
> Kenneth P. Turvey wrote:
>
>> 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.
Passwords could be a backup system of authentication. You could even
provide ways to generate passwords when you need them, the way we do now
for password resets.
Certificates would provide everyone with single sign on if they were
widely supported.
Dave Searles
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.
jebblue
> senatov wrote:
>
>> 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.
What about Base 64 encoding of the hash?
--
// This is my opinion.
Lothar Kimmeringer
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.
Arne Vajhøj
> senatov wrote:
>> 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.
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
> On Mon, 28 Sep 2009, Mike Schilling wrote:
>> Dave Searles wrote:
>>> I still think the surest bet is to avoid using dictionary-attackable
>>> passwords. :)
>>
>> Absolutely, which is why many environments require passwords to
>> contain both letters and numbers.
>
> 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
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
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
Dave Searles
> 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_%28cryptography%29>
>>>
>>> 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.
>
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
> 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_%28cryptography%29>
>>>>
>>>> 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.
>>
>
> Whaaat? Nonsense.
It is true.
>> 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.
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
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.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Arne Vajhøj
You are correct.
My mistake.
Arne
Lew
>> [says I'm a liar]
>
Dave Searles wrote:
> 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
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.
--
Lew
Ken
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 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
> Arne Vajh�j wrote:
>> You are correct.
>>
>> My mistake.
>
Bite me.
Dave Searles
> Dave Searles wrote:
>> 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_%28cryptography%29>
>>>>>
>>>>> 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.
Hey!
>> Whaaat? Nonsense.
>
> It is true.
No, it is not; I am NOT a liar.
>>> 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.
>
> 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:
>>> 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_%28cryptography%29>
>>>>>>
>>>>>> 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.
Hey!
>>> Whaaat? Nonsense.
>> It is true.
No, I am NOT a liar.
>>>> 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.
>> 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!
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. :)
Dave Searles
> Dave Searles wrote:
>>> [says I'm a liar]
> [says I'm a liar]
No, you are.
rossum
<sea...@hoombah.nurt.bt.uk> wrote:
>Least-intrusive there is to break in
Get a job with the Office cleaning company that cleans the offices
overnight, or else pass $5,000 to someone who has such a job to do the
copying for you.
rossum
Tom Anderson
How so?
> 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.
Ah! Of course, good point. I hadn't realised that.
tom
--
Most people lose their talent at puberty. I lost mine in my early
twenties. I began to think of children not as immature adults, but of
adults as atrophied children. -- Keith Johnstone
Ken
I'm just saying if the point is to get certain data in a timely way
that does not belong to you then there are much simpler and realistic
ways than using Penny's magic computer book to teleport the password
file into your hands.
> 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.
Well of course you can do a better job at stealing the data than
leaving little metal bits of their chopped up case all over. I can
think of a few very efficient ways of taking all the data without
anyone being the wiser. The most efficient of all is simply swapping
drives. If you know the make and model of the existing drive great if
not who cares most people don't know their drive brand... Look some
crazy virus wrote the whole drive over with random data, crazy weird!
> 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. :)
Funny enough the video storage is also often stored in the same room
as the server. Anyways does anyone know how effective encrypting the
hard drive is? I've seen a bunch of users happy as can be that their
laptop's hard drive is encrypted, then they punch in five alpha keys
and they're in. To be fair I don't know if there was hardware in the
equation... that could be problematic. I know someone who worked for
a large cryptographic company. There are all kinds of interesting
problems. As someone had pointed out earlier it is all about time.
In time you can always get at the data but in time the data will be
worthless. So anyways they don't say much about what they do (their
work is about keeping secrets after all) but in this particular
project they were working on a hardware encryption problem. If you
were to look at the ideal case, that is, inputs to output... it was
fantastic at using up time which is perfect for the purpose however
the system discarded passwords quickly if they were far off. Now you
can't show that to the outside world so naturally you will make the
system take a constant time. However when it was first designed no
one though to check for power consumption! The process was very
numerically intensive and with the right equipment you could see a
correlation between power usage (and heat) and know you are close to a
correct answer. Moral, things can look good on paper but when
implemented it is hard to keep cribs from sneaking up. A good case of
where ideals went out the windows when implemented is the enigma
machine.
Dave Searles
> On Thu, 01 Oct 2009 15:23:41 -0400, Dave Searles
> <sea...@hoombah.nurt.bt.uk> wrote:
>> Least-intrusive there is to break in
Whaaaaat?
No way!
Dave Searles
> [says I'm a liar]
I am not.
> I can think of a few very efficient ways of taking all the data without
> anyone being the wiser. The most efficient of all is simply swapping
> drives.
They'll notice the replacement drive is missing all their data. You'd
have to copy the whole thing while there to avoid that, in which case
you might as well leave with the copy, not the original.
rossum
<sea...@hoombah.nurt.bt.uk> wrote:
>rossum wrote:
>> On Thu, 01 Oct 2009 15:23:41 -0400, Dave Searles
>> <sea...@hoombah.nurt.bt.uk> wrote:
>>> Least-intrusive there is to break in
>> [says I'm a liar]
I pointed out a non-intrusive way to obtain the data that you might
not have thought of. The attacker can always think of things that you
have not thought of.
>
>Whaaaaat?
>
>No way!
How is my scenario impossible?
rossum
rossum
Here I agree with you. Make a copy while leaving the original drive
in place. The data will be more valuable if the owner does not know
that it has been copied.
rossum
Ken
> On Fri, 02 Oct 2009 09:48:16 -0400, Dave Searles
>
Depends some of the most valuable data has very good long term value.
After all at these lengths there is no need to get the keys, they just
go straight for the ends. If however they are after intercepting on
going communications then you are talking about pretty sophisticated
criminals... more likely some spy agency. Then the physical counter
measures would be beyond legal, requiring sirens... not so you know
that the server is being broken into but so can flee the 3000 degree
Celsius explosion that is going to take place in the server room.
Dave Searles
> On Fri, 02 Oct 2009 09:45:19 -0400, Dave Searles
> <sea...@hoombah.nurt.bt.uk> wrote:
>
>> rossum wrote:
>>> On Thu, 01 Oct 2009 15:23:41 -0400, Dave Searles
>>> <sea...@hoombah.nurt.bt.uk> wrote:
>>>> Least-intrusive there is to break in
>>> [says I'm a liar]
> I pointed out
I don't care. I am NOT a liar, and that is the end of the subject!
>> Whaaaaat?
>>
>> No way!
> How is my scenario impossible?
It is impossible that I could be a liar. From that, it follows that your
statement implying that I am one must be false.
Dave Searles
> On Fri, 02 Oct 2009 09:48:16 -0400, Dave Searles
> <sea...@hoombah.nurt.bt.uk> wrote:
>> They'll notice the replacement drive is missing all their data. You'd
>> have to copy the whole thing while there to avoid that, in which case
>> you might as well leave with the copy, not the original.
> in place. The data will be more valuable if the owner does not know
> that it has been copied.
Now if you can get it remotely, so much the better; even if the
computers in the machine room seem intact, if there are pry-marks at the
side of the door and the lock is broken that might make some people
suspicious, *particularly* if nothing is actually missing. :)
Arne Vajhøj
> Arne Vajh�j wrote:
>> You are correct.
>>
>> My mistake.
>
> Thank you, Arne, for demonstrating how a person can take correction
> without thinking that someone accused him of lying.
I am probably in the top decile in stubbornness.
But there is not much point in trying to argue what is
polynomial and what is exponential. It would be like
trying to argue that 2+2=5.
Arne
Peter Duniho
> [...]
> But there is not much point in trying to argue what is
> polynomial and what is exponential. It would be like
> trying to argue that 2+2=5.
Um. But, it is! It's well-known that 2+2=5 for large values of 2.
Sorry to mess up your analogy. :)
Dave Searles
> Lew wrote:
>> Arne Vajh�j wrote:
>>> You are correct.
>>>
>>> My mistake.
>>
Wrong.
> I am probably in the top decile in stubbornness.
Admission duly noted for the record.
> But there is not much point in trying to argue what is
> polynomial and what is exponential. It would be like
> trying to argue that 2+2=5.
Who was arguing either? I just pointed out that adding more variation to
the password characters is the former and adding more suffix length or
similarly is the latter, which is perfectly correct.