Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passwordle

rsk0315.github.io

Post reply on HN
Print view View original

111–120 of 263 posts

Re: Passwordle

#111

Post by bspammer »

AdamTReineke wrote: post #72
aerovistae wrote: post #22

Earlier quoted context omitted.

Massively useful! I also recently learned you can right click a line of code in the chrome debugger to add a logpoint - i.e. "log the value of this expression when you reach this point in the code" - so I don't have to manually add console.log statements. Basically the reverse of discovering the debugger statement!

One more trick: Add a conditional breakpoint with the condition: `value = "someOverrideValue", false` to make the breakpoint change the value when it is reached without actually stopping execution. Great for when you need state changed but the app is always trying to override it. Here's a video from a talk I gave five years ago that demonstrates that: https://youtu.be/uixXOTCNbhs?t=1182

Woah. Now that is incredibly useful.

Re: Passwordle

#113

Post by mlyle »

jerf wrote: post #76
faeyanpiraat wrote: post #46

Earlier quoted context omitted.

Is any of the information (yellow/green for characters) presented getting you closer to the real answer in any meaningful way though?

According to the best current knowledge of humanity, it provides no information whatsoever. However, proving that is difficult. It is possible that there exists an algorithm that could narrow in on the answer from hashes. Such an algorithm could run quickly, but it could also potentially take quite significant computation. We don't know what the true, optimal answer to this question is.

> According to the best current knowledge of humanity, it provides no information whatsoever.

??? My first guess has two green letters, or 8 bits of the hash are known. This excludes 255/256 of possible passwords-- so if there's a dictionary, it's way cut down. I also know for the other 30 digits a value that they are not-- this is about .1 bits apiece, for 3 more bits. And I get a few more bits from knowing the population count for each digit.

One guess has reduced the search space by a factor of 10000+. If I say, know the word is in /usr/share/dict/words, the number of possibilities has dwindled from 230,000 to something around 20.

Now, in this case, with a 14 character randomized password-- the amount of benefit is limited. The search space is still significantly shrunk by each guess, but in a way that is difficult to iterate.

Re: Passwordle

#115

Post by phire »

tetha wrote: post #104
burke wrote: post #66

This would be kind of fun to write a solver for. You'd burn the first few guesses to get some positional constraints, then filter a rainbow table down to viable guesses. I'm not sure you'd be able to get a very good success rate in just 10 possible guesses though.

If you can casually write an algorithm to break a modern cryptographic hash in 10 guesses... I would like to know. Because then I have to decide if I want to be a very good friend of you, once you get rich, or if I want to stay as far away from you as possible once the state intelligence agencies come after you.

It's not a cryptographic break.

It's simply a regular password cracking algorithm, but with instead of knowing the full hash, you only know a partial hash.

It should be viable, even without rainbow tables. That's why plain, unsalted sha256 is very unsafe for password storage.

Re: Passwordle

#116

Post by FabHK »

runnerup wrote: post #105
FabHK wrote: post #88

Earlier quoted context omitted.

It could work theoretically (the password contains around 90 bits, and from each row you can glean, dunno, some 64 bits of info (64 characters that can be yellow, gray or green, so 101 bits, but there are constraints on that - very unlikely that all characters are gray, for example)). In practice, I don't think it's computationally feasible. You can't keep all 2^90 = 10^27 possible solutions around in memory. Bitcoin…

To me it seems like the password is 14 bytes, because they're 14 characters (112 bits). How do you get 90 bits? It also uses 96 possible characters for each digit. Just storing the 96^14 different passwords without even adding their corresponding SHA hashes would require 5646 yottabytes. Which is more than 4 orders of magnitude larger than all the world's digital storage capacity combined together.

As you say, each of the characters is not a full 8 bits (namely a character out of an alphabet of 256), but chosen from a smaller alphabet of 96 characters, and log(96)/log(2) = log_2(96) ≈ 6.58, so 6.58 * 14 = 92 bits. Then I deducted a bit or two ad-hoc for the way they're drawn, with letters overrepresented. This could be computed more precisely. But it's not more than 93 bits, and not less than 83 bits, I'd say.

Re: Passwordle

#117

Post by residualmind »

mlyle wrote: post #107
moritonal wrote: post #7

There is like... four people I know I could send this to who'd laugh, it's so niche. Yet I also laughed out loud when I got how conventionally impossible it is.

Is it? 6 guesses and I have 14 hex digits (56 bits) of the hash, along with knowing the population counts for all the numbers. This is enough to run a password cracker and determine the plaintext if it's a readily guessed password. Sure, it breaks conventional use of rainbow tables, etc, but... edit: Eh, 14 characters. OK, that's pretty resistant to anything other than debugging.

How does that help you when any of your inputs' digest is not related to any other's, not even knowing the target length of the original message? what am i missing?

Re: Passwordle

#118

Post by residualmind »

residualmind wrote: post #117
mlyle wrote: post #107

Earlier quoted context omitted.

Is it? 6 guesses and I have 14 hex digits (56 bits) of the hash, along with knowing the population counts for all the numbers. This is enough to run a password cracker and determine the plaintext if it's a readily guessed password. Sure, it breaks conventional use of rainbow tables, etc, but... edit: Eh, 14 characters. OK, that's pretty resistant to anything other than debugging.

How does that help you when any of your inputs' digest is not related to any other's, not even knowing the target length of the original message? what am i missing?

[ @some-sober-math-guy insert probabilities ]

Re: Passwordle

#120

Post by residualmind »

mlyle wrote: post #113
jerf wrote: post #76

Earlier quoted context omitted.

According to the best current knowledge of humanity, it provides no information whatsoever. However, proving that is difficult. It is possible that there exists an algorithm that could narrow in on the answer from hashes. Such an algorithm could run quickly, but it could also potentially take quite significant computation. We don't know what the true, optimal answer to this question is.

> According to the best current knowledge of humanity, it provides no information whatsoever. ??? My first guess has two green letters, or 8 bits of the hash are known. This excludes 255/256 of possible passwords-- so if there's a dictionary, it's way cut down. I also know for the other 30 digits a value that they are not -- this is about .1 bits apiece, for 3 more bits. And I get a few more bits from knowing the pop…

Are you sure thats how evenly distributed hash algorithms work? change one letter of your string, or just make it longer or shorter - none of your green fields will stay.
Post reply on HN