My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
It's not nonsense. It's a rule and guide for a strong password.
It may be troublesome to use a strong password, but it makes it much more time consuming to brute force the password.
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
It's not nonsense. It's a rule and guide for a strong password.
It may be troublesome to use a strong password, but it makes it much more time consuming to brute force the password.
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
JJ <jj4public@gmail.com> wrote:
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
It's not nonsense. It's a rule and guide for a strong password.
It may be troublesome to use a strong password, but it makes it much more
time consuming to brute force the password.
There's another argument that the opposite is true because all
those requirements limit the range of possible passwords and could
therefore be used to increase the speed with which a brute force
attack could be executed by excluding checks against passwords that
wouldn't have been allowed.
Rather than a brute force attack, it's really trying to protect
against a dictionary attack using lists of words, likely starting
with lists of leaked passwords from large organisations like these
that are available online:
https://github.com/danielmiessler/SecLists/blob/master/Passwords/Leaked-Databases
The ones that really annoy me are those that make you change your
password routinely every so often, just to ensure that one day
you'll make a mistake trying to do that in a hurry and later find
you've got the old/wrong password and can't log in.
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
It's not nonsense. It's a rule and guide for a strong password.
It may be troublesome to use a strong password, but it makes it much more time consuming to brute force the password.
Indeed they seem a very common set of conditions for passwords
nowadays.
not@telling.you.invalid (Computer Nerd Kev) writes:
JJ <jj4public@gmail.com> wrote:
It may be troublesome to use a strong password, but it makes it much more >>> time consuming to brute force the password.
There's another argument that the opposite is true because all
those requirements limit the range of possible passwords and could
therefore be used to increase the speed with which a brute force
attack could be executed by excluding checks against passwords that
wouldn't have been allowed.
It's more complicated than that...
If passwords were selected uniformly from all possible ASCII strings of
a given length then yes, the requirements above limit the set of
possible passwords a bit. For 10 character passwords it would reduce
from around 2^66 to around 2^60 for 10-character passwords, if my back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
left to their own devices, some of them will pick their dog's
name, dictionary words, their birthday or just 123456 (the
world's most popular password).
Unfortunately complexity rules don't help much either. The people who
wanted to pick their dogs name will (apparently quite reliably) use
"Rover1!" instead of "rover". The real-life search space expansion due
to complexity rules is rather small.
For the OP, the solution to all this is to use a password manager to
pick a random password and remember it for them.
My criticism is not aimed at the restrictions, annoying though they are,
but at the fact that this is on the sign-in page. That is, it's being imposed on people's EXISTING passwords, and preventing them from logging
in if the rules have been changed SINCE they originally created their password.
The correct way to handle this is to make the person change their
password after allowing them to log in using their now non-compliant password. This would also avoid having to present this password stuff
every time someone logs in.
Hmm, seems I've described this in a way that makes people overlook the central point.
My criticism is not aimed at the restrictions, annoying though they are,
but at the fact that this is on the sign-in page. That is, it's being imposed on people's EXISTING passwords, and preventing them from logging
in if the rules have been changed SINCE they originally created their password.
The correct way to handle this is to make the person change their
password after allowing them to log in using their now non-compliant password. This would also avoid having to present this password stuff
every time someone logs in.
Sylvia.
I'm starting to believe that, most sites still stupidly store user passwords not as hashes. Cause I've read several past news of hacked sites where passwords were stolen, and they're in plain text.
On Tue, 8 Sep 2026 11:47:47 +0800, Sylvia Else wrote:
Hmm, seems I've described this in a way that makes people overlook
the central point.
My criticism is not aimed at the restrictions, annoying though they
are, but at the fact that this is on the sign-in page. That is,
it's being imposed on people's EXISTING passwords, and preventing
them from logging in if the rules have been changed SINCE they
originally created their password.
The correct way to handle this is to make the person change their
password after allowing them to log in using their now non-compliant
password. This would also avoid having to present this password
stuff every time someone logs in.
Sylvia.
Oh, I see now. That does not make any sense, even if they meant to
notify users to change their password. The approach is just wrong.
It also raises a concern. How did they know the users' password is
weak? It seems to suggest that, they store users' password as is,
encrypted or obfuscated. Instead of storing the hash of the
passwords.
I'm starting to believe that, most sites still stupidly store user
passwords not as hashes. Cause I've read several past news of hacked
sites where passwords were stolen, and they're in plain text.
JJ <jj4public@gmail.com> wrote:
On Tue, 8 Sep 2026 11:47:47 +0800, Sylvia Else wrote:
Hmm, seems I've described this in a way that makes people overlook
the central point.
My criticism is not aimed at the restrictions, annoying though they
are, but at the fact that this is on the sign-in page. That is,
it's being imposed on people's EXISTING passwords, and preventing
them from logging in if the rules have been changed SINCE they
originally created their password.
The correct way to handle this is to make the person change their
password after allowing them to log in using their now non-compliant
password. This would also avoid having to present this password
stuff every time someone logs in.
Sylvia.
Oh, I see now. That does not make any sense, even if they meant to
notify users to change their password. The approach is just wrong.
It also raises a concern. How did they know the users' password is
weak? It seems to suggest that, they store users' password as is,
encrypted or obfuscated. Instead of storing the hash of the
passwords.
I interpreted Sylvia's updated explanation as:
1) X number of users (perhaps Sylvia herself as well) have an existing password on this system from before this new requirement
2) When attempting to log in, using the old password, the login page is enforcing that the entered password, to use to authenticate the user
logging in, is being checked against this list -- thereby preventing
anyone with an old, and not compliant, password from logging in. And presumably, preventing anyone from changing their old password, unless
the old password just by chance happened to fit the new restrictions.
I'm starting to believe that, most sites still stupidly store user
passwords not as hashes. Cause I've read several past news of hacked
sites where passwords were stolen, and they're in plain text.
Whiie it is easy to attribute nefarious reasons to why, the actual
reason most often is simply that 99.9% of developers have zero security training, because none of the CS classes nor the "become a Java dev in
10 weeks bootcamp" that they took bother to teach any "security best practices" training of any form. So they store passwords in plain text simply because they do not know any better.
Plaintext storage is easy. Put an <input> on the web page (maybe with
the 'password' attribute so it shows ****'s). Retreive the plain text
from the http form data, do a basic SQL insert into the SQL database
"users" table. And it all seems to work just fine, until one day the
company is the subject of a breech, or until an actual security auditor
who knows what they are doing (as opposed to most 'auditors', who are
also just "checking boxes on compliance forms", but have no
understanding of why the items next to the boxes are important).
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
JJ <jj4public@gmail.com> wrote:
It may be troublesome to use a strong password, but it makes it much more >>>> time consuming to brute force the password.
There's another argument that the opposite is true because all
those requirements limit the range of possible passwords and could
therefore be used to increase the speed with which a brute force
attack could be executed by excluding checks against passwords that
wouldn't have been allowed.
It's more complicated than that...
If passwords were selected uniformly from all possible ASCII strings of
a given length then yes, the requirements above limit the set of
possible passwords a bit. For 10 character passwords it would reduce
from around 2^66 to around 2^60 for 10-character passwords, if my
back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
But if someone's able to check that many possible passwords in a real
attack then you've got problems anyway.
Sylvia Else wrote:
My criticism is not aimed at the restrictions, annoying though they are,
but at the fact that this is on the sign-in page. That is, it's being
imposed on people's EXISTING passwords, and preventing them from logging
in if the rules have been changed SINCE they originally created their
password.
The correct way to handle this is to make the person change their
password after allowing them to log in using their now non-compliant
password. This would also avoid having to present this password stuff
every time someone logs in.
Oh, I see now. That does not make any sense, even if they meant to
notify users to change their password. The approach is just wrong.
It also raises a concern. How did they know the users' password is
weak? It seems to suggest that, they store users' password as is,
encrypted or obfuscated. Instead of storing the hash of the passwords.
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
It's not nonsense. It's a rule and guide for a strong password.
It may be troublesome to use a strong password, but it makes it much more time consuming to brute force the password.
https://xkcd.com/936/?correct=horse&battery=staple
On Tue, 8 Sep 2026 15:22:14 -0000 (UTC), Jim Jackson wrote:
Indeed they seem a very common set of conditions for passwords
nowadays.
ItrCOs worth looking at the value of imposing various kinds of rules on
the makeup of passwords, to see how much effect they really have.
LetrCOs say you start by making up passwords consisting only of
lowercase letters.
If the password is 10 characters long, that gives 26 ** 10 = about 200 trillion possibilities.
LetrCOs say you add uppercase and digits to the mix. Now you have (26 +
26 + 10) ** 10 = about 800 quadrillion possibilities.
Now letrCOs add some more characters -- what were the ones from that
list on the page that Sylvia posted: rCL!@#$%^&*()-{[}]:;<,>.?rCY -- a further 22 characters. So now you have 84 ** 10 = over 17 quintillion possibilies.
Sounds like adding all these extra characters is worthwhile. Except:
If you go back to just upper- and lower-case letters and digits, and
increase the length from 10 to 11 characters, you now have over 52 quintillion possible passwords.
Adding those non-alphabetic, non-numeric characters to the mix
increased the number of passwords by a factor of about 20. Whereas
adding one extra character, without increasing the character set,
multiplied the password combinations by a factor of 62.
My local council has changed their password requirements, and this is their solution.Stirling.1 will pass(*) check and you can start count if they ask to change password.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
JJ <jj4public@gmail.com> wrote:
It may be troublesome to use a strong password, but it makes it much more >>>>> time consuming to brute force the password.
There's another argument that the opposite is true because all
those requirements limit the range of possible passwords and could
therefore be used to increase the speed with which a brute force
attack could be executed by excluding checks against passwords that
wouldn't have been allowed.
It's more complicated than that...
If passwords were selected uniformly from all possible ASCII strings of
a given length then yes, the requirements above limit the set of
possible passwords a bit. For 10 character passwords it would reduce
from around 2^66 to around 2^60 for 10-character passwords, if my
back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
AFAICT no, it does not. For example default behavior of John The Ripper
uses word lists and mutation rules, because modelling user behavior
generates results at a more realistic cost than exhaustive search.
Exhaustive search is possible but gets rather expensive for anything
beyond relatively short passwords.
But if someone's able to check that many possible passwords in a real
attack then you've got problems anyway.
The right way to think about this is to think about the economics. If extracting a password from a list of hashes will yield you $X (in
subsequent ransomware payments or whatever) then it's not worth spending
more than $X of compute time to recover it. (There's a hardware cost of course but that can be re-used for many passwords.)
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
If passwords were selected uniformly from all possible ASCII
strings of a given length then yes, the requirements above limit
the set of possible passwords a bit. For 10 character passwords it
would reduce from around 2^66 to around 2^60 for 10-character
passwords, if my back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
AFAICT no, it does not. For example default behavior of John The Ripper
uses word lists and mutation rules, because modelling user behavior
generates results at a more realistic cost than exhaustive search.
Sure but "Incremental" mode in John The Ripper still claims to "try
any character combination", just in the order of more likely
combinations first. An unlikely password (designed to be hard to
guess regardless of requirements for acceptance) will be tried sooner
if all passwords not meeting length and special-character requirements
can be excluded because they would never have been accepted.
The right way to think about this is to think about the economics. If
extracting a password from a list of hashes will yield you $X (in
subsequent ransomware payments or whatever) then it's not worth spending
more than $X of compute time to recover it. (There's a hardware cost of
course but that can be re-used for many passwords.)
Well I meant that if someone's stolen the hashes you've got
problems already.
Or alternatively if they have a botnet large enough to bypass rate
limiting for log-in requests, or found a design flaw that allows them
to bypass it.
On 2026-09-07, Kerr-Mudd, John wrote:
https://xkcd.com/936/?correct=horse&battery=staple
(Are the GET parameters supposed to be doing something on that page?
Just wondering if I need to try with a different browser.)
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
If passwords were selected uniformly from all possible ASCII
strings of a given length then yes, the requirements above limit
the set of possible passwords a bit. For 10 character passwords it
would reduce from around 2^66 to around 2^60 for 10-character
passwords, if my back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
AFAICT no, it does not. For example default behavior of John The Ripper
uses word lists and mutation rules, because modelling user behavior
generates results at a more realistic cost than exhaustive search.
Sure but "Incremental" mode in John The Ripper still claims to "try
any character combination", just in the order of more likely
combinations first. An unlikely password (designed to be hard to
guess regardless of requirements for acceptance) will be tried sooner
if all passwords not meeting length and special-character requirements
can be excluded because they would never have been accepted.
So, still assuming users pick passwords non-uniformly then.
(If password cracking software assuming that passwords were selected uniformly, as you appeared to be suggesting, then any ordering would be
as good as any other and there would be zero point wasting effort on
anything but a simple lexicographic ordering.)
The right way to think about this is to think about the economics. If
extracting a password from a list of hashes will yield you $X (in
subsequent ransomware payments or whatever) then it's not worth spending >>> more than $X of compute time to recover it. (There's a hardware cost of
course but that can be re-used for many passwords.)
Well I meant that if someone's stolen the hashes you've got
problems already.
Part of the point of hashing is defence in depth, for the situation
where the hashes have been stolen. (In the early days of Unix the
password hashes were in a world-readable file...)
Or alternatively if they have a botnet large enough to bypass rate
limiting for log-in requests, or found a design flaw that allows them
to bypass it.
The other part of the point of hashing is to build unavoidable resource
usage requirements into any password check.
On Wed, 09 Sep 2026 10:58:49 +0100
Nuno Silva <nunojsilva@invalid.invalid> wrote:
On 2026-09-07, Kerr-Mudd, John wrote:I don't know, probably not; I guess maybe I cutnPasted the xkcd ref but
https://xkcd.com/936/?correct=horse&battery=staple
(Are the GET parameters supposed to be doing something on that page?
Just wondering if I need to try with a different browser.)
left in the FWSE search parms.
But in my defence, the url I gave does
give a Clue as to what it's about.
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
If passwords were selected uniformly from all possible ASCII
strings of a given length then yes, the requirements above limit
the set of possible passwords a bit. For 10 character passwords it >>>>>> would reduce from around 2^66 to around 2^60 for 10-character
passwords, if my back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
AFAICT no, it does not. For example default behavior of John The Ripper >>>> uses word lists and mutation rules, because modelling user behavior
generates results at a more realistic cost than exhaustive search.
Sure but "Incremental" mode in John The Ripper still claims to "try
any character combination", just in the order of more likely
combinations first. An unlikely password (designed to be hard to
guess regardless of requirements for acceptance) will be tried sooner
if all passwords not meeting length and special-character requirements
can be excluded because they would never have been accepted.
So, still assuming users pick passwords non-uniformly then.
I'm not commenting on all users, I'm saying the one weird guy who
doesn't just use something like "Passw0rd!" everywhere could argue
the restrictions make it relatively easier/quicker for a brute
force attack to guess _his_ password (dictionary attacks being
irrelevent to his password anyway).
Maybe other users will be better off by being forced to use a
different password (even if they all end up "uniformly" using the
same new ones anyway). Maybe not. All I was saying is there's a
valid argument against it from that user who'll choose a strong
password anyway.
Yes for website log-ins you can argue that an attacker won't bother
with his password and just go after everyone else using
"Passw0rd!". However there could be lots of different motivations
for this general type of attack. The attacker might have hacked or
stolen a rich victim's phone and be trying to obtain their password
so with 2FA they can empty their bank account. Or the victim might
be the admin of a server where the attaker has got full read access
but now they need root access to take over control and demand a
ransom. Basically there are many cases where an attacker might
target one individual regardless of how weak the passwords of other
users on the system are.
(If password cracking software assuming that passwords were selected
uniformly, as you appeared to be suggesting, then any ordering would be
as good as any other and there would be zero point wasting effort on
anything but a simple lexicographic ordering.)
The right way to think about this is to think about the economics. If
extracting a password from a list of hashes will yield you $X (in
subsequent ransomware payments or whatever) then it's not worth spending >>>> more than $X of compute time to recover it. (There's a hardware cost of >>>> course but that can be re-used for many passwords.)
Well I meant that if someone's stolen the hashes you've got
problems already.
Part of the point of hashing is defence in depth, for the situation
where the hashes have been stolen. (In the early days of Unix the
password hashes were in a world-readable file...)
Or alternatively if they have a botnet large enough to bypass rate
limiting for log-in requests, or found a design flaw that allows them
to bypass it.
The other part of the point of hashing is to build unavoidable resource
usage requirements into any password check.
Yes and if it's done properly using a complex hash and salt it
should work, for a time until computers get much faster at least.
You're the one who brought up hashes though, and even if everyone's implementing them perfectly now (unlikely), the attacker might
have found a way to bypass the rate-limiting of the log-in system.
If you assume hashes could be read, that also should suggest _some_
form of routine password rotation would be advisable, since a
password hash used in eg. the 1990s is likely to be crackable by
brute-force at relatively little cost today.
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
If passwords were selected uniformly from all possible ASCII
strings of a given length then yes, the requirements above limit
the set of possible passwords a bit. For 10 character passwords it >>>>>> would reduce from around 2^66 to around 2^60 for 10-character
passwords, if my back-of-envelope scribbling is right.
But the user community does not pick passwords like that;
Indeed, but the software trying to guess a password by "brute
force" will work more or less like that.
AFAICT no, it does not. For example default behavior of John The Ripper >>>> uses word lists and mutation rules, because modelling user behavior
generates results at a more realistic cost than exhaustive search.
Sure but "Incremental" mode in John The Ripper still claims to "try
any character combination", just in the order of more likely
combinations first. An unlikely password (designed to be hard to
guess regardless of requirements for acceptance) will be tried sooner
if all passwords not meeting length and special-character requirements
can be excluded because they would never have been accepted.
So, still assuming users pick passwords non-uniformly then.
I'm not commenting on all users, I'm saying the one weird guy who
doesn't just use something like "Passw0rd!" everywhere could argue
the restrictions make it relatively easier/quicker for a brute
force attack to guess _his_ password (dictionary attacks being
irrelevent to his password anyway).
Maybe other users will be better off by being forced to use a
different password (even if they all end up "uniformly" using the
same new ones anyway). Maybe not. All I was saying is there's a
valid argument against it from that user who'll choose a strong
password anyway.
Yes and if it's done properly using a complex hash and salt it
should work, for a time until computers get much faster at least.
You're the one who brought up hashes though, and even if everyone's implementing them perfectly now (unlikely), the attacker might
have found a way to bypass the rate-limiting of the log-in system.
If you assume hashes could be read, that also should suggest _some_
form of routine password rotation would be advisable, since a
password hash used in eg. the 1990s is likely to be crackable by
brute-force at relatively little cost today.
I knew some guys, who happened to be members of a shadier group I was familiar with, who were promoting the use of passwords in the form:
wordawordbwordc, basically three words contiguous.
https://en.wikipedia.org/wiki/Diceware
I use this in some scenarios. I have real casino dice to use, too!
I knew some guys, who happened to be members of a shadier group I was >familiar with, who were promoting the use of passwords in the form:
wordawordbwordc, basically three words contiguous.
Do you think they had a special brute-force cracker that handled this >particular case and were promoting bad ideology?
Lane W <cactus_DAC@yahoo.com> wrote:
I knew some guys, who happened to be members of a shadier group I was
familiar with, who were promoting the use of passwords in the form:
wordawordbwordc, basically three words contiguous.
Do you think they had a special brute-force cracker that handled this
particular case and were promoting bad ideology?
The 'crack' program would find these. Also word/number combinations
like worda99wordb99. I don't know how many need to be added before it
can't find them, though. And it would take MUCH longer than finding
ones with only two words, so perhaps in the nineties CPU time limitations were higher.
--scott
On Mon, 7 Sep 2026 22:08:23 +0800, Sylvia Else wrote:
My local council has changed their password requirements, and this is
their solution.
https://www.dropbox.com/scl/fi/w6a1t9oakuq1xvfd3w1nk/StirlingCouncil.png?rlkey=2ox4eq0wsh4qtxf4zdvppbfcy&dl=0
And they validate against the requirements before letting you log in.
What kind of nonsense is this?
Sylvia.
It's not nonsense. It's a rule and guide for a strong password.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 121:08:40 |
| Calls: | 1,194 |
| Files: | 1,352 |
| Messages: | 290,208 |
