password policy
-
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
-
V. wrote:
how is it comparing the old (encrypted) password to the new (encrypted) one?
It decrypts it first, encryption is two-way. So it takes "&#HDSW" from the database as your old password and decrypts it to "god_123". It then compares that to the new password you've entered.
LDAP stores password in history using HASH, no two way encryption there... The only password may be stored as cleartext is the current one...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
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
-
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)? :confused:
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 -
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
Most of the 'challenged' people get angry when challenged...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
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)? :confused:
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 timeIf 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.
-
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
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.
-
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... :sigh:
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 -
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)? :confused:
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 timeTo 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
-
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... :doh:
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 -
LDAP stores password in history using HASH, no two way encryption there... The only password may be stored as cleartext is the current one...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
All of my passwords at work are stored as plain text. ... In a text file named "passwords.txt" on my desktop.
I wanna be a eunuchs developer! Pass me a bread knife!
-
LDAP stores password in history using HASH, no two way encryption there... The only password may be stored as cleartext is the current one...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
He hasn't said what password system this is though.
-
He hasn't said what password system this is though.
-
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.
:wtf: And this is secure ... how? :confused: I thought the current "safest" thing to do is to have salted hashes, right?
V.
(MQOTD rules and previous solutions)
-
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.
-
All of my passwords at work are stored as plain text. ... In a text file named "passwords.txt" on my desktop.
I wanna be a eunuchs developer! Pass me a bread knife!
Same with me - I have 9 pre-created passwords (we have 8 stored in history) stored as plain text...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Jochen Arndt wrote:
RFC4519 specifies that passwords are not stored in encrypted (or hashed) form.
:wtf: And this is secure ... how? :confused: I thought the current "safest" thing to do is to have salted hashes, right?
V.
(MQOTD rules and previous solutions)
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.
-
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
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
Goldman Sachs employs this type of password policy. Most major corporations do. I'm sure other companies large and small do something similar. The idea is that a lot of people keep the same portions of their password the same and just change out incremental sections whenever they have to change the password (usually every 2-3 months). In theory, this can be hacked very easily.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
V. wrote:
you cannot change it into something that is too similar to the previous one.
Have you tested it? Maybe it's just a vapor-policy. ;)
V. wrote:
How is that determined since the hashing value should change significantly if you change just one letter ?
If they are truly hashing, then they can't. If the policy actually works, then they are encrypting, not hashing. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
