...
Thanks Jeff! That tidbit was actually quite helpful for clearing up a separate issue I was having with a different website.
...
Thanks Jeff! That tidbit was actually quite helpful for clearing up a separate issue I was having with a different website.
It would take that long to brute-force it, but it's very low entropy, so it wouldn't take a great leap of insight or time/space complexity to add the hashes of all single-digit character runs up to some arbitrary number to a rainbow table. That'd be the only way to crack it fast.
"who would do that and for what length would they do it out to" is a psychological question and not a technological question, I guess
bitrex wrote in news:NVpUE.11393$ snipped-for-privacy@fx30.iad:
NO. The point was that it would NOT take that long.
In fact, most if not all 'brute force' ALSO use libraries of tables of keys, so the "all the same character group" is one of those first tested.
Many 'brute force' algorithms have tables they check first.
And even if staggerring through them all without tables, your 'same character throughout' combination would likely arise and be found pretty quickly.
Ok sure but you're re-defining what "brute force" means.
How would a strict brute force search come across a 50 character password of all the same character any faster than it came across any other password 50 characters in length?
If your "brute force" algorithm is not actually strict brute force but also uses table-assist or heuristic like try single-letter combinations how is it determined how many characters the cut-off is? 25? 50? 100?
it's entirely up to the particular implementation.
Password strength is essentially about Kolmogorov complexity which is uncomputable; there can be no universally-accepted metric of it that's "true" in a mathematical sense. That's why I qualified my statement at the beginning with "By some metrics"
That is to say an algorithm which could compute a universally meaningful "strength" metric for all possible passwords of non-trivial complexity would be equivalent to an algorithm that could solve the halting problem for all possible inputs which is impossible
bitrex wrote in news:aEqUE.30483$ snipped-for-privacy@fx11.iad:
I just told you. "Brute force" 'search' NOW includes lookup tables of "commonly used" passwords and searches those FIRST. That includes the table not required "all characters the same" search.
Easy peasy.
It doesn't "come across" it. It goes through the tables and if unsuccessful, THEN looks with the random, logged traditional brute force hunt.
sword, which MUST include both upper and lowercase, and at least one specia l character, with additional limits on character sequences and repetition -
-- and yet, will block the account after three unsuccessful login attempts?
d" or "1234"?
is less secure.
of engineering! :)
Relevant xkcd:
DemonicTubes wrote in news: snipped-for-privacy@googlegroups.com:
It is worse than that. The dopes (a lot of them) actually think they are some kind of illuminati.
Password hunt schemes to use a table of every word in the dictionary in a four word combo... would not take too long.
Four unknown length words, however...
Antidisestablishmentarianism
At some point, even though one remembers the password, it gets difficult to pump it in without error, especially on touch interfaces.
Maybe a stupid question:
If a hacker tries different combinations, won?t he (or the machine) be locked out after say 10 attempts when the maximum number of wrong passw ord attempts has been reached?
Cheers
Klaus
ine) be locked out after say 10 attempts when the maximum number of wrong password attempts has been reached?
With AT&T a three strike password attempt and you are talking to someone on the phone. Luckily I remembered my favorite my favorite singer.
onsdag den 10. juli 2019 kl. 23.15.55 UTC+2 skrev Klaus Kragelund:
e) be locked out after say 10 attempts when the maximum number of wrong pas sword attempts has been reached?
yes, but if you get hold of the hashed password you can try all you want of f-line
gray_wolf wrote in news:FGsVE.6320$X% snipped-for-privacy@fx32.iad:
my favorite, my favorite, wherefore art thou my favorite?
Pavarotti, right? :-)
Which would work just as well if the limit were 10 or 20.
But any such hard limit provides a denial of service attach against a person.
Rate limiting would be more than adequate for any reasonably strong password.
Sylvia.
And then you discover that your carefully constructed long strong password has been silently truncated to some unknown lesser number of characters.
Or that the characters it accepts during password creation are different from the characters it accepts during password entry*.
I've had both of those :(
Sylvia.
[*] Why would anyone program an acceptable character filter for password entry?
I've had similar problems with email addresses.
When communicating with a company, I use aname+ snipped-for-privacy@gmail.com and they all end up in anames's input folder. That provides a filtering mechanism and also a means of tracking which company has leaked/sold my email address.
The problems arise when different parts of the company's systems do/don't allow the "+" in the address.
SEE
Mozilla seems iffy - a 40 character random alphanumeric with both upper and lower case still gets only 90%. But 10 such characters with a - at the end gets 100%, when the others take a dim view of such a short password.
Sylvia.
One reason would be to prevent whitespace mistakes; another would be to limit the character set to ASCII because there's UTF-8 entry problems on a (for instance) smartphone 'keyboard'.
I've kept a bunch of notes compiled into an e-book, that I replicate from time to time for the smartphone.
One peeve: apostrophe just does NOT translate from my note-taking app through the (multiple) OS'es that lie on the file-transfer chain; it becomes a UTF-8 thing in some non-ASCII alphabet. I've fixed it twice, and it's STILL broken.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.