|
I think this could go alongside Godwin's Law - the longer an on-line debate about passwords continues, the probability of someone linking to xkcd 936 approaches certainty.
Won't somebody think of the horses (and staples)?
|
|
|
|
|
Stewart Judson wrote: the longer an on-line debate about passwords continues, the probability of someone linking to xkcd 936 approaches certainty.
It's an absolute certainty of the most high probability. 
It really is true.
|
|
|
|
|
Stewart Judson wrote: I think this could go alongside Godwin's Law
A Godwin is not a valid argument, but the comic explains an argument in simple terms. So yes, it is bound to be referenced. Now, if any popular reference is a Godwin, then we might better stop using them, starting with the academics.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I think this could go alongside Godwin's Law - the longer an on-line debate about passwords continues, the probability of someone linking to xkcd 936 approaches certainty.
...which of course increases the probability of someone linking to xkcd 261[^]
|
|
|
|
|
It should be stored as a hash, not encrypted. A hash is one way. I.e. Not able to be decrypted
|
|
|
|
|
LDAP has no password policy option for similarity, so it is probably an overlay and it may DO store the password in some comparable form...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
To compare similarity between passwords means that the comparable form must be 1:1 with the plain text form, so basically a weak character-by-character encription. Scary.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Couldn't it depend on the encryption? I haven't tested it, but if you encrypt two very similar passwords using the same algoritm, could it be possible that the two encrypted passwords also were quite similar (and perhaps even comparable)? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
If an encryption would produce the same output for the same input it would be useless...(breakable in seconds)
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Perhaps - just an idea... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
To compare similarity between passwords you need to know:
1) The characters which are present in the password;
2) The sequence of such characters.
Whcih amounts to knowing the password itself, even if a mangled version.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Well, not necessarily. If the encryption worked like this (just an example of course):
Pass1word => #¤%"AsdfY2g&Po*qQs
Pass2word => #¤%"Asdf7Xg&Po*qQs
it would still be comparable even encrypted... You only need to know how much that is changed - not WHAT EXACTLY is changed... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
The idea you are talking about would be more of an encoding instead of an encryption.
Compare Base64 encoding to AES encryption, for example.
Any modern and accepted cryptographic algorithm will operate on bits, not bytes.
But, alas, many-a-programmer has thought s/he has written an encryption algorithm and accidentally created an encoding algorithm without noticing and marked him/herself as a genius of encryption. 
|
|
|
|
|
From OpenLDAP Software 2.4 Administrator's Guide: Security Considerations[^]:
Quote: LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme.
However, it may be desirable to store a hash of password instead.
|
|
|
|
|
Jochen Arndt wrote: RFC4519 specifies that passwords are not stored in encrypted (or hashed) form.
And this is secure ... how?
I thought the current "safest" thing to do is to have salted hashes, right?
|
|
|
|
|
V. wrote: And this is secure ... how?
Secure as the access to the server which can be restricted by
- Using secure communication (SSL, TLS)
- Restricting network access (firewall)
- Restricting login (remote and physical)
- Restricting physical access
- Using a dedicated LDAP system without any other services
If it is only used for local authentication the server should also have no internet connection.
If I would have to decide between encrypted passwords and the ability to check for similar passwords I would choose the first option.
|
|
|
|
|
Not so, LDAP requires authenticated but not privileged access on client hosts. It's about as secure as tossing a passwords list into the NETLOGON folder.
If it's not configured correctly (ie proper permissions added to the password field), literally any domain machine can get those passwords, apparently in plain text.
Jochen Arndt wrote: If I would have to decide between encrypted passwords and the ability to check for similar passwords I would choose the first option.
Choose neither. Encryption is reversible by definition; go with a salted, unpadded hash.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
If they have enough hashing capacity (trivial if SHA*, needs a cluster if using a slow hash), they could mutate your new password making every possible 1 character addition/subtraction/substitution and see if any of them match the old hash.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
True.
But unlikely.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
what about comparing it before encrypting and saving? 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Keep a count of chars and hash those.
When you input the new password, count the chars and then compare the hashes.
Example: god_123 = 1g1o1_111213 . Obviously it's a terrible idea to keep it in plain text,
thus you hash it. Once you type the new password, match hash against hash. Done.
|
|
|
|
|
The passwords don't need to be stored plaintext in order to check for similar passwords. The password checker could create several variations of your proposed password, hash them and compare to your previous password hashes. For example, if the last character is a number, all digits [0-9] could be tried at that position.
|
|
|
|
|
F-ES Sitecore wrote: your password you usually need to enter your existing password
Very good explanation. That must be it. Thanks for reminding us of that. I forgot that you have to re-enter your old one.
|
|
|
|
|
Had the same system at my last employer, and I doubted then that it was as secure as they thought. But hey ho, IT department were the experts, and did not like being challenged.
|
|
|
|
|
Richard MacCutchan wrote: and did not like being challenged
Apparently they enjoyed it so much 
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
