|
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
|
|
|
|
|
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.
|
|
|
|
|
|
Richard MacCutchan wrote: and did not like being challenged.
Funny, same thing here ... 
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
|
|
Really? Rickrolling? You are going to stoop that low?
A*******.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
 You did not really believe there was a hash comparator, did you ?
|
|
|
|
|
Just a thought: what constitutes a similar password?
Okay, we can look at things that are close in terms of characters but there are thousands of sequences that aren't detectable that way.
Let's say a user has the following chain of passwords:
HunkyD0ry71
Ziggy5tardust72
A1add1nSan373
It's a pretty safe bet that the next one would either be P1nUp573 or D1am0ndD0g574 (depending on whether our user regards Pin Ups as a "proper" Bowie album.
There's no way that you're ever going to trap that with software but it's very easy for a human to work out.
I guess I'm like most people in my home use in that I use Keepass and never even look at my generated passwords, let alone memorise them (idiot password policies that demand less secure passwords are a complete annoyance here but I'll save that rant for another day).
In work-places though, especially if people are working on fixed images or locked-down machines, we're forced into that altogether less secure world where users need a self-made memorable password. This is where highly human-predictable patterns like the Bowie sequence above come into play and also where published restrictions (x-y chars which must include blah, blah and blah) can make it even easier to derive current passwords from old ones. And, let's face it, however many times you tell people to never write their passwords down, you know full well that a search through any office will turn up a fair few scribbled on notebooks and post-its.
|
|
|
|
|
Who says it's hashed? There are more than 0 IT departments on this world who have no friggin' idea what they're doing.
|
|
|
|
|
It could perform such from the other way round. E.g. take the new password, generate a set of permutations by changing one or two characters in it, compute the hashes for each and check if such hash equals the original password.
Of course, this can become a lot more complicated - especially if starting to compare more than just one character being optional. Thus such calc could take a lot of time. Not to mention, it "should" be done client-side else you're sending a plaintext / encrypted password to the server - which then does these calcs. The whole idea of a one-way hash is so you never have the actual password outside your own client machine.
Alternatively, another idea which may be even better ... Pre-calculate hashes for all the "bad-list" passwords (i.e. those stuff where passwords are leaked and compared to just how many people use them). Then whenever a user enters a new password, compare its hash to the table of pre calculated hashes. Again, it may become a bit more computationally intense once you have to throw salting into the mix, unless a salt can be applied to a hash at a later stage instead of to the password before calculating the hash (again algorithm dependent). But I think this way should avoid most of the major issues, while using much less computations than the permutation idea.
|
|
|
|
|
Thats an old technology, the Soundex code. Its a type of hashing to see if two words sound alike when spoken. It was a common way to look up names that may have been misspelled when first entered into a database.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
