password policy
-
Hyperbole is my favorite of all inventions and must be implemented at all times. :) The point is that when you use a mnemonic then it is based upon words. Words are patterns and patterns can be more easily cracked than non-patterns. What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized. Your password itself should be a hash which is so long you cannot memorize it. (Which is hyperbole also, since Daniel Tammet memorized 22,514 digits of pi and recited them[^]). :)
My book, Launch Your Android App, is available at Amazon.com.
raddevus wrote:
What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized.
Again, that idea is wrong. A non-memorizable password needs to be stored. Yes, words are patterns, but that knowledge isn't going to help much in determining my password. I'll give you another clue; it is based on a single line of a poem, 33 characters.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
raddevus wrote:
What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized.
Again, that idea is wrong. A non-memorizable password needs to be stored. Yes, words are patterns, but that knowledge isn't going to help much in determining my password. I'll give you another clue; it is based on a single line of a poem, 33 characters.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
Again, that idea is wrong.
Brrrr....there's a cold wind a blowin'. "Wrong" is such a cold harsh word. It makes me feel like I might not be right. :-D Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic. And, I'm guessing that your poem is Milton's Paradise Lost, right? Here's all of Shakespeare's sonnets first lines so I'm generating your password off of these now: Shakespeare's Sonnets- first lines[^] :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
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???
-
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)
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.
-
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???
:-D You did not really believe there was a hash comparator, did you ?
-
Eddy Vluggen wrote:
Again, that idea is wrong.
Brrrr....there's a cold wind a blowin'. "Wrong" is such a cold harsh word. It makes me feel like I might not be right. :-D Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic. And, I'm guessing that your poem is Milton's Paradise Lost, right? Here's all of Shakespeare's sonnets first lines so I'm generating your password off of these now: Shakespeare's Sonnets- first lines[^] :laugh:
My book, Launch Your Android App, is available at Amazon.com.
raddevus wrote:
Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic
You got a long string that you did not memorize and did not store - in that case, I will start to doubt your ability to produce the same string again. That is something that is kinda required to be used as a password.
raddevus wrote:
Here's all of Shakespeare's sonnets first lines
Not a fan of Shakespeare. So, you already know the length of the string, the pattern, and are assuming English language (yes, it is an English writer, but that does not mean the password has to be). How many possible combinations would there be? xkcd: Password Strength[^]
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
raddevus wrote:
Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic
You got a long string that you did not memorize and did not store - in that case, I will start to doubt your ability to produce the same string again. That is something that is kinda required to be used as a password.
raddevus wrote:
Here's all of Shakespeare's sonnets first lines
Not a fan of Shakespeare. So, you already know the length of the string, the pattern, and are assuming English language (yes, it is an English writer, but that does not mean the password has to be). How many possible combinations would there be? xkcd: Password Strength[^]
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
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)?
-
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!
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
-
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.
My book, Launch Your Android App, is available at Amazon.com.
-
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:
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 :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
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 timeThe 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. :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
Richard MacCutchan wrote:
and did not like being challenged.
Funny, same thing here ... :-\
V.
(MQOTD rules and previous solutions)
This is IT!!! Dilbert Comic Strip on 2007-11-16 | Dilbert by Scott Adams[^] :laugh: :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
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.
Here's an explanation... :laugh: :laugh: Dilbert Comic Strip on 2007-12-13 | Dilbert by Scott Adams[^]
My book, Launch Your Android App, is available at Amazon.com.
-
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
-
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
That's an idea: we should assemble a CP password.txt file, for general use in the MoronicKneeJerkPasswordPolicy domain. It would save us the trouble of creating our own. [edit] If you think 90 days is bad, I worked at one place that had a holiday-booking webapp where they required a new password every 30 days. How often do you book holidays, for Arbuthnot's sake! Essentially, every time you opened the app, you had to change your password. [/edit] [edit2] Holiday = vacation, to blasted colonials. [/edit2]
I wanna be a eunuchs developer! Pass me a bread knife!
-
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)
what about comparing it before encrypting and saving? :rolleyes: :rolleyes:
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.
-
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
-
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)
Who says it's hashed? There are more than 0 IT departments on this world who have no friggin' idea what they're doing.
-
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)
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.
-
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)
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.
