Cracking passwords using ONLY response times | Secure Python

[@MathMagician93]

"Nothing on one, click on two, four is binding..." It's literally just lockpicking at this point.

[@AvenDonn]

"The decompiler Bosnian Bill and I made"

[@NottoriousGG]

this comment has me dying

[@stacklysm]

Not sure whats holding us back

[@ferociousfeind8538]

Yeah, it kinda is. Instead of playing on the server's (or locksmith's) terms, you play by your own rules. By tensioning the core, or testing the password repeatedly, you can probe one character at a time and test for timing, or the general feel of the pin in its chamber. With this method, you can turn a brute-force 26^n (n= length of password) possibility problem into a 26*n possibility problem, by finding one pin or character at a time.

[@Dr_Wrong]

Ha!

[@nadavgolden]

That password cracking at the end was so epic 😂

[@mCoding]

I made it as cinematic as I know how!

[@casperdewith]

It’s just like in the movies.

[@rogervanbommel1086]

@@mCoding side channel attacks always look amazing (if they work)

[@vojtechstrnad1]

Reminded me of the ATM hack in Terminator 2.

[@thebossthatcounts5677]

You have no taste

[@wirtos_new]

Data comparison in cpu cache is incredibly fast in comparison to any io, in real world scenario where network io would be involved you couldn't really find a correlation between password length and your guess using the timing, cool reminder to not store actual passwords and neat video anyway

[@mCoding]

Indeed! For this reason, in a real timing attack, you would have to combine with an additional attack to cause carefully curated lag on the server, you can take advantage of cache misses in a big way.

[@DevLPful]

Furthermore, passwords are usually hashed first - making timing attacks even harder

[@rogervanbommel1086]

@@DevLPful thats true, though that takes a fixed time

[@t_kon]

@@rogervanbommel1086 it's hashed and added a random salt, making the stored password have the same length. Time attack won't work that way.

[@t_kon]

@@ko-Daegu yea, there are many ways to prevent this. But then again that's the fun isn't it?

[@Sonyim414]

This was pretty interesting. You can make a part 2. Now that we're wise, and we use hashes (or even salted ones), there's a new attack to watch out for - hash collisions!

[@mCoding]

I really like this idea! I'll use an md5 hash for passwords 😀

[@Sonyim414]

@@mCoding Perfect! I would also recommend you add some new/recommended functions like PBKDF2 or even Argon2 at the end, to show how far we've come.

[@adekeyetemitope2301]

Hash collisions is highly unlikely ... and practically not feasible

[@letao12]

@@adekeyetemitope2301 Older hash algorithms like MD5 and SHA1 have been susceptible to practical collision attacks for years now. It's even been used in a successful real-world malware campaign (read up on Flame).

[@dermuschelschluerfer]

@@mCoding with bcrypt an attack like that wiuldnt be possible as easily if at all

[@john.dough.]

You're the only programming channel that I haven't gotten bored of. Thank you for your interesting videos!

[@mCoding]

Amazing! I'll do my best to stay interesting! Drop by the discord and suggest topics you'd like to see, I may just cover one!

[@lisnter]

These are fun attacks. My network cybersecurity professor had us craft an attack like this. I didn't want to write the HTTP code to call the password validator API so I used curl. I figured any overhead of fork()-ing a command would be common across all requests and so I could factor it out. Unfortunately, the overhead was much greater than the time differences and so I couldn't reliably tease those differences out of my results. I wrote up what I was doing and got almost full points (I think he subtracted one point since I didn't actually recover the password). Anyway, I learned a lot.

[@stef9019]

Never heard of this before. Very interesting concept!

[@mCoding]

This is just the tip of the iceberg!

[@davidbellamy1388]

@@mCoding would love to see more of this iceberg!

[@prince2347x]

Does this f"{variable=}" prints *variable="variable_value"* ?? I never knew about this🌝🤨

[@mCoding]

Yep! Super useful for debugging!

[@prince2347x]

@@mCoding Wow, such a cool thing and I never knew about this😂.. Your videos contains more information other than the video topic.

[@beautyofsylence]

Only from python 3.9+ I believe.

[@silverzero9524]

i think its new feature

[@sadhlife]

it was added in python3.8 so don't use it in production code just yet. but yeah it's great for debugging

[@sadhlife]

alright, I'm only writing branchless code from now on 😤

[@mCoding]

Yes, check_password(user, x): return True

[@Kenionatus]

@@mCoding I mean, MOV (x86 assembly for moving data from one ram location to another) is branchless but Turing complete*. So a branchless password server would be possible. *kzbin.info/www/bejne/iGiodqKNnJt4oc0

[@compuholic82]

I wouldn't count on that protecting you from timing attacks. I don't know much about the Python compiler but from my experience with C++ compilers, there is a huge disconnect between the code you write and what is actually executed on the CPU. CPUs are extremely good at branch prediction and speculative execution and compilers know this and take advantage of it. So it might actually be faster to introduce a branch into the code instead of evauating a complicated expression: Here is an example: You have a (useless) piece of code that either halves or doubles an input depending on whether it is even or not. The expression I wrote is branchless, yet the compiler (Clang 12) decided to introduce a branch. godbolt dot org/z/YjrcG44a5 (KZbin doesn't let me post links so replace the "dot" in the URL.) But even if there is no compiler magic and the CPU actually executes branchless code. With all the caching going on in a CPU I wouldn't be at all surprised if there are functions that take longer to execute for certain inputs than for others.

[@branthebrave]

Implying you don't store the passwords encrypted

[@AAA-de6gt]

@@compuholic82 Wouldn't count on this either, but the compiler has probably vectorised as well. I don't think an attacker will be guessing an entire 16 or 32 bytes correctly.

[@ultraman6950]

I'm new to programming and to, particularly, Python, so that means I didn't understand a thing of this. But it was fantastic to see how you implemented this and how clever you are. Keep the great job, man. Edit: English is not my first language so, in case there's any mistake, feel free to correct me. I'd appreciate it.

[@mCoding]

Thanks for the support! Keep at it and I'm sure soon you will be able to understand every line!

[@sergeboisse]

Well done! However, I think a wise thing would be, in your server, to have your check_password() routine only responds after a fixed (or even random) amount of time (spanning a timer, etc) This way, no timing attack would be possible.

[@RH-nk7eo]

Just curious, with a normal server given the uncontrolled factor (user -> server, server -> user response time) which can vary, is a random response time even required? I know nothing about timing attacks but how would they account for just the general delays across the internet?

[@XerosOfficial]

To counteract internet variations, hackers can use a dedicated machine like a vps, and use thousands of iterations. They can also use multiple machines. What matters with this attack is that it will always slowly get closer to the answer and with enough time it is highly likely to succeed. Instead of random response times as a countermeasure however, the hashes of strings are usually compared instead and they are always the same length.

[@ashy7198]

@@XerosOfficial Its a pretty far fetched scenario, The idea that in order to bypass 5+ incorrect attempt client timeouts, they will use different machines, VPNs, or simply reset cookies. If you think about the complexity of it. Each machine that makes 5 attempts will need to pass the information of the failed 5 passwords to the next one, so that it doesn't guess the same 5. Then you think about the sheer number of machines/tabs/VPS needed to crack even a 10 digit string, is over 3,628,800. Divide that by 5 attempts per tab/machine/VPS and you will need 725760 different environments all passing their previous attempts to each other just to crack a 10 digit string. Unless its nuclear launch codes during war time, im guessing your flower pot shop customer details are safe with just a client timeout at 5 tries.

[@XerosOfficial]

@@ashy7198 Client timeouts have many purposes, including acting as a countermeasure to timing attacks. No wonder it doesn't work when they're involved. That's literally one of the reasons they exist. If a company doesn't want to deal with a bunch of old people calling customer service to get their account unlocked, then they will often simply implement password hashing, which is *already highly recommended* for security.

[@multiwebinc]

Timing attacks can be used to determine valid usernames. For example, if the user doesn't exist, a fail response is returned right away, but if it does exist, then the server will also verify the password hash as well, which is slow.

[@merthyr1831]

Normally I don't care much for youtuber sponsored ads; but for once that's something super relevant to what I've been looking at developing for in my free time! I'll take a look! :)

[@mCoding]

I appreciate it! The more viewers check out my sponsors the more they will want to sponsor me again!

[@islamkaram463]

Most servers don't save the apparent passwords but it does save as a hash password, but I got to acknowledge u a brilliant

Weak passwords can still be reversed

[@Mutual_Information]

Lol using an algorithm to uncover a "subscribe" message is an idea I may borrow. clever! Cool vid too. I'm always impressed by the clever ways hackers narrow down possible passwords.

[@mCoding]

You have my approval! Can't wait for your next video too!

[@imagineabout4153]

Other than making me a better coder, you make me feel happy. In your videos I always have that "ah-ah" moment. Thanks.

[@mCoding]

Very welcome!

[@qorbanimaq]

This video was just fabulous! Literally, every time I watch your videos, a whole new world of possibilities opens to me.

[@amortalbeing]

Thanks a lot. good old memories. I remember I found about this technique when I was working as a SSG member in one of former companies which happened to be a big financial institute. (this was around 2011, so more than a decade ago). I remember reading about this in a paper, I believe this method was proposed for the first time by an Israeli security expert/researcher. and it was mind blowing at the time (still is imho) Sometimes you just have to stand up, appreciate the beautify if this and applause the brilliant minds like this. hope to see a world where there is no more hatred/war/etc among us, especially between Palestinians, and Israelis, and also everyone else in the world.

[@php1036]

everybody gangsta until the server ping is more than 100 ms. It takes an hour to get the length of the password and 46+ hours to iterate through every ASCII char in 32 character password and probably around 80 hours to crack the password. although bruteforce would be way slower.

[@trangium]

80 hours to crack a password is still too low.

[@ZacKoch]

I was trying to think of where this could be used in real life... Since most developers would be insane to not use bcrypt or something I was thinking a more common use of this concept could be used to enumerate hard coded API keys.

[@douwehuysmans5959]

If you have the hard-coded API key clientside then provided you have root access there are easier ways to do it

[@ZacKoch]

@@douwehuysmans5959 if you have root access it's over regardless, c'mon. The application itself has to function, therefore making it moot. If you're root, you already have the keys or can carry out any task the API could as the application instance.

[@maxlife459]

either bcrypt or argon2, depending on whether you're starting from scratch or not

[@deidara_8598]

Passwords aren't the only times timing-attacks are relevant. Many cryptographic algorithms can be difficult to implement such that they run in constant-time at the same time as being able to encrypt large quantities of data quickly. This can arise either though certain operations being quicker for certain pairs of bits (like XOR, which is frequently used in block ciphers), or through careless use of caching to boost performance, which could be exploited to reveal previously encrypted data/encryption keys. Timing is only one form of side-channel attack though, there are many others, including power analysis, accoustic analysis, cache attacks, etc.

[@hdswashere]

You're thinking about whether people use bcrypt when there are plenty of developers out there writing systems that house sensitive information without a clue about security. These are people who store passwords in the clear. I've seen this personally, and the worst part is they know it's frowned upon but they think they're not important enough for anyone to target their companies. Most developers are bad.

[@LordTails]

This was a cool thing to look at and try out. If you stacked this with some sort of genetic algorithm, multithread, and perhaps cythonize it, you could get it to go a lot faster, theoretically speaking.

[@-.-._]

Interesting topic but in a real scenario, the attacker would e on an other machine than the server, and the lagg between the client and server would be much higher and non stable than the cpu execution time. So it would totally break the guessing technique. But still fun to watch

[@scottmiller2591]

Now I'm ready to hang out with Acid Burn. Hold up, let me start hollywood. Now I'm ready.

[@logicweaver7152]

Please make a video on how to avoid such situations. Your videos are really informative for someone like me as I am trying to learn programming by myself. I don't think I would have come across this if not for your video. Thanks a ton.🤗

Check "constant-time comparison". Many languages provide it as a library function .

[@tomtravis858]

@ Why not just hash?

@@tomtravis858 it's better then nothing for sure. The reason why not JUST hash is the same why salt and stretch passwords: too many people choose too weak passwords and so the hashes can be easily broken. Calling a library function is easy anyway, so no good reason to not do it.

[@elstonko343]

This is easy to fix just add sleep(random) before checking

[@i000alen]

Wow, interesting concept!

[@mCoding]

Thanks!

[@woofwoof2412]

Very good video, underrated channel

[@mCoding]

Thanks for the kind words!

[@ttuurrttlle]

So is the best solution to this problem just to add a random length sleep before the server sends the response back? Or is that like write your own string compare that doesn't return early in the case where only some characters were correct?

[@redpug5042]

would it be a more resilient system if you always return at the same time? set a boolean to true initially, then if any of the conditions (lengths not equal, chars not equal) are true, set the variable to false, then return that variable at the end.

[@deemon710]

Wow. That's really neat! Thanks for showing us!

[@glorytoarstotzka330]

that is sort of scary. Once I built a program that does something really important and had to be run on my machine and I needed someone else to interact with it remotely. so I setup an http server [which didn't even have SSL, aka the https] and to login you just had to input a predetermined password. the program was done in python and I just did a simple equality check for the password, it's really scary knowing that anyone could just crack that with this attack. now I wasn't concerned of security for the program: nobody knew of it except 3 people and also that program is no longer needed so the server is not up anyways.

[@8koi139]

Wooo it's a pretty interesting concept!! Also I have been looking for something like Anvil for some weeks now!!

[@ashishamar5013]

Amazing Content! Accidentally found this channel and now I'm binging on them! Damn. Just realized there's a lot more stuff idk.

[@somnath_bagal]

For those who are facing problem to crack password due to unstable machine.. Run this script... keep this script running in background Open task manager with administrator. On Processes tab sort by CPU Your python process will be at the top of list. Right click > Go to details > Right click on python process Set Priority to realtime and affinity to only one core (De-select all and select only one core) Check console you will notice significant difference, this python process will be more stable than earlier and should get work done.

[@PestOnYT]

While your example highlights the principle of using timing for attacking, it also assumes a bad way for storing passwords. For sure there are plenty of places storing passwords as clear text, but usually passwords are combined with a seed (which was defined when setting the password) to create a hash value. Checking the valid password is then done by using the same seed and putting it into the same algorithm. Then the hashed values are compared, not the clear text of password and input. The seed itself is (usually) stored at the server along with the password. So, you'll need to guess the seed first. In good password hashing algorithms the resulted hash value is of the same length. Don't get me wrong. I like this video. Your example shows the weakness of storing a clear text password and how easy it can be to hack it. Further more this principle is applicable to many other situations where one may deduct data from the time alone. I just want to highlight that password cracking - should - these days must be more sophisticated.

[@mCoding]

Indeed, this is a what-not-to-do video, not a best-practices video :). I believe I even mention that the server should not even be storing your password in the first place, as you mention hashes should be used. Unfortunately, one might be temped to "do it oneself" and write one's own authentication system, which is usually how these things end up being a problem in the real world. There are, however, some more practical timing attacks (or at least attacks that partially use timing info) that even got fancy names and logos in recent years. Think of it as the tip of the iceberg for some people who may not have ever been exposed to the idea that timing info can be used against them in this way.

[@Lodinn]

These days, it's assumed that your password database already got stolen somehow; plaintext means all the user data is out there, accessible. Just hash means rainbow tables are viable. Hash+salt means targeted attacks against specific users with rainbow tables work, but it's infeasible to do so for the entire database. Rainbow tables also fall short for complex passwords, even though creating a collision is enough.

[@MrOsefosef]

You missed the whole point of this video

[@slava6105]

you can pass callable as stmt parameter to timeit functions: from timeit import repeat def a(x): print(x) some_var = 0 def do_a(): some_var += 1 return a(some_var) repeat(stmt=do_a, number=10)

[@mCoding]

Hmm... could I still pass arguments to the function this way?

[@taragnor]

It's kind of amazing an attack like this would be viable in the real world, given discrepancies in latency, server load, etc. I'd think there would be too much noise to reliably get any useful timing data on anything but a physical PC you were sitting at.

[@chongalden2947]

Pretty clever attack, thanks for sharing!

[@EW-mb1ih]

Nice video! Even your sponsor is great!

[@mCoding]

Thanks, glad you like it and them!

[@robertbrummayer4908]

Man, your videos are awesome!

[@mCoding]

Thanks so much!

[@NicolasChanCSY]

Great video introducing such interesting concept! I feel like you missed a good chance saying "(hacker voice) I'm in" after cracking the password though 😂 Just curious, if we salt the password and hash it (maybe repeatedly for at least a few times) to a fixed length, then this attack has very little chance to success?

[@mCoding]

You got it! Salt + hash is a best practice to prevent this kind of attack, but it is far too subtle to cover in this intro video :)

[@aspzx]

@@mCoding salt + hash + constant time string comparison. Actually bcrypt does all of those things in one library.

[@l4luchi123]

That was a really smooth demonstration. 😯

[@niconeuman]

Watching your video I had a strange urge to subscribe to mcoding. Curious. Would it be possible to make a comparison that waits random amounts of time before returning true or false? And do you know any other applications of this type of strategy not related to cracking passwords?

[@mCoding]

How curious, perhaps you should indulge in these subscribal urges just this once? Yes you could add a random waiting time to thwart this particular attack, but the industry best practice is to use secure hashes instead, which are generally not susceptible to timing attacks. Timing attacks have in recent years been used to do all kinds of things, including leaking server secret keys bit by bit and tricking cpu branch predictors into reading and divulging memory that the user does not have access to. Those were more sophisticated attacks do I wouldn't necessarily call them just timing attacks, but they included a timing component. More generally there is a whole branch of statistics that deals with getting information based off of noisy time series data.

[@niconeuman]

@@mCoding already did some time ago!

[@monochromeart7311]

@@mCoding do you have good resources for reading about the cpu tricking shenanigans? I'm really interested!

[@davidbellamy1388]

@@mCoding what branch of statistics is that? I’m reminded of information theory a bit but I only know about it in the context of entropy and machine learning. Words like Hamming codes come to mind but I can’t remember what those are really.

[@mCoding]

@@davidbellamy1388 it goes by the boring name time series analysis.

[@JEffinger]

Really good explanation of timing attacks. Well explained.

[@mCoding]

Thanks!

[@TheMadLex]

Very interesting video! Will there be more hacking approaches in the future? Also, how would you defend against such attacks? Is there more than just banning login attemts?

[@mCoding]

It depends on how well the video does I suppose! Security is a very complex topic, so don't think that this answer fixes the entire problem, but the way to twart this attack is by using a check password function that uses the same amount of time regardless of how close to correct the guess is. Ideally, the password should be hashed using a cryptographically secure, slow hash function and the password itself shouldn't even be stored on the server, combined with standard server hardening practices like banning after too many wrong attempts.

[@jowlz]

time.sleep(random.random())

[@TheMadLex]

Thanks both of you :D

[@juliankandlhofer7553]

thats a big reason why implementing your own hashing and encryption algorithms is such a bad idea! you might technically get the algorithm correct, but if it doesn't always take the same time for any input, correct or not, this can be exploited. ALWAYS use your language's standard library for anything involving cryptography, because the implementers have (hopefully) taken this into account!

[@XZYSquare]

or purposefully add a random time delay to your password checker

[@admthrawnuru]

@@XZYSquare A random delay could be averaged out, though. It might be better to choose a response time and then pad all responses to match it. Or create very clever delays to mess up attacks, but you'd have to have a very thorough knowledge of such things to do it. Still, unless you're an expert, Julian is right. Just use things made by experts (and check to be sure your built-in libraries are such)

[@XZYSquare]

​@@admthrawnuru calculate how long it takes to get the wrong and right answer wrong = 10; right = 100; async Task doCalculation(string input) { bool answer = input == secretinput; await Task.Delay(random.Next(wrong-wrong*.5, right*1.5)); return answer; } force the calculation to return after the same amount of time is another way as well async Task doCalculation(string input) { Stopwatch sw = new Stopwatch(); sw.Start(); bool answer = SecretTestingMethod(input); sw.Stop(); await Task.Delay(right -sw.ElapsedMiliseconds); return answer; } always return after the same amount of time reguardless of if it tested positive or false

[@olbluelips]

@@XZYSquare The first one is a bad idea. When you use your calculated right and wrong times as bounds, you're leaking information -by returning the random value to the user-

[@XZYSquare]

@@olbluelips it returns true or false, not random value

[@TARS..]

The dislikes are all the "hackers" who got disappointed in the first 10 seconds.

[@1Hippo]

Very cool! I have just tried out your code. Commented back in the first check function with the builtin string comparison and while the length cracking still works the password cracking does not at all. I wonder why that is. Doesn't the CPython str.__eq__ implementation compare characters one by one? Or is it just too fast to measure with regular Python code? Edit: Looking at the src it seems to rely on memcmp() for both byte and unicode strings.

[@mCoding]

CPython's str compare is implemented in C using a memcmp, which is extremely fast compared even to python's perf_counter. Memcmp compares byte by byte in most implementations (str is unicode so a single character can be multiple bytes). Your system needs to be very fast and well-tuned to accurately time something as short as a single byte comparison, especially since the cpu could theoretically be doing multiple comparisons simultaneously/reordering instructions. If you even have a desktop environment installed on your system, that may significantly affect the timing attack. If you know some more advanced statistics you can deal with higher variance using fancy math. Other than that you can try tweaking the number of iterations and running it many times, sometimes it does better than others.

[@1Hippo]

​@@mCoding Thanks for the elaborate answer! I have researched a bit more now and found this test: x41-dsec.de/lab/blog/memcmpbench/ Even with the high res timer ASM instruction it cannot be exploited under all circumstances. Though there were real attacks with memcmp() and patches to make it constant time, especially in crypto applications. It is also interesting how highly optimized this is in glibc. They are checking at runtime if the CPU supports SIMD vector instructions sets like SSE and AVX and then choose the fastest implementation. For example on every fairly modern desktop CPU this should be AVX2: elixir.bootlin.com/glibc/latest/source/sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S So it can compare up to 256 bit (32 byte) with a single instruction.

[@MrMandosss]

such a good video - very informative!

[@mCoding]

Thanks for watching, glad you liked it!

[@HaroldR]

Very interesting video as always!

[@mCoding]

Thank you thank you as always!

[@davidoffonly]

this video made me subscribe to the channel instantly

[@mCoding]

Awesome! Welcome!

[@grawa4278]

What if you code the server to answer always after 0,5 seconds? Then you can't use this info (and can't spam like that)

[@astronemir]

Anvil sounds really cool. Since they’re a sponsor, maybe you could do a python only full stack video?

[@undisclosedmusic4969]

Did you point out somewhere explicitly that people should use a constant-time comparison such as hmac.compare_digest in Python?

[@mCoding]

Well, no, but I provided a reason why I didn't point this out in the description. The solution to the problem is much more subtle than the problem itself, so I didn't want to make it seem too simple like slow_equals or just using hashes in general is the solution. These subtleties are likely topics for future videos though!

[@logananderon9693]

I know this is just an example, but is there any way this would work against hashed(salted) passwords?

[@burnin8orable]

Aren't hashes typically of uniform length though?

[@jordiyaputra8359]

This assumes the db store plain text pass. With hashes yes you can't check length but you can try pre-hashed password and check if it is correct

[@letao12]

Yeah. There are timing attacks designed for hashed passwords too, though they are much more complicated.

[@aaronm6675]

Great demo, well presented 🤠

[@mCoding]

Thank you kindly!

[@1000marcelo1000]

I don't know much but probably in python it's not the way you said it, because when you change the "check_password" function to just "return password_database[user] == guess" as it was at the beginning of the video, the code doesn't break the password

[@1000marcelo1000]

By the way, i loved the video and the chanel is amazing!

[@Pascal6274]

So what programming language actually does string comparison this way? Nice demonstration though.

[@realdragon]

Is there defense system for that? For example after comparing input and password wait some time so the response time always the same or wait random amount of time?

[@phitsf5475]

07:40 The most hollywood looking hack I've ever seen

[@AmCanTech]

james murphy with murphys law

[@aonodensetsu]

so if you check the string without immediately putting it in the return and then add a random delay it's pretty much immune to timing attacks?

[@invisibilities]

well, this can be prevented by adding a fixed delay between the request & the respond, say 1 second, and like that, that method would be rendered useless.

[@Сергей_Петров_85]

I think search user & pwd simultaneously in DB would be more vulnerable. And search time would be the same in both cases: with correct and incorrect pwd. So using timings will not help any more.

[@faizanahmed5503]

Amazing vid!

[@mCoding]

Thanks for the support! Glad you enjoyed!

[@notpivan]

What if you implement a random sleep amount between like .02 and .3 sec during the password check?

[@PHOENIX-yt8fd]

Nice, but you can just add random time before responding on fast servers needs to be changed just by few miliseconds 1-3% variation should be enough Or as said, just implement maximum amount of attempts But still very good and educative video

[@mCoding]

Great observations! Indeed, the more noise there is, the harder it is to use a timing attack. However, noise does not prevent timing attacks, it just means more data or a more sophisticated statistical analysis may be required. Additionally, in the situation presented here there is an obvious attack surface, but in real code beyond password checking it is not necessarily apparent that you could be leaking secret information via timing, which can make it hard to tell where you might want to add noise into in the first place. And finally, there is of course a tradeoff with purposefully adding noise because adding 3% to your runtime might be very costly if you have millions or billions of users. Often there are options to prevent a timing attack without introducing variance, although extra runtime is often the cost you just have to pay.

[@royz_1]

On your machine it makes sence but how would this method hold on an actual website where the code execution time is mostly the smallest factor for time taken?

[@TheMaxCacao]

In the crack_password function, why do you include % length? i = next(counter) % length Is it used for a failsafe when counter becomes > length? If so, when would this be the case?

[@mCoding]

This will loop over 0 ... length-1 over and over. The first pass may not get all characters correct, so we just keep looping over the whole string until we get it right.

[@TheMaxCacao]

@@mCoding Running the code made it much easier to understand. Thanks for the response!

[@TheMaxCacao]

I tried changing the if min(alt_time) > min(guess_time): conditional take the mean or percentiles, but no luck. The last 5 chars always elude me. I imagine similiar behavior would be seen on a server with lots of processes running

[@mCoding]

Yes, timing attacks can be very finicky even if you do everything perfectly. Play around and maybe you can get something more consistent. The best thing you can do is to turn off any unnecessary processes that might interrupt and mess with the timing.

[@ofiryaffe8223]

But to counter the attack you just make sure that response times take the same time, by just defining a constant time to send the response that is not realted to the programs runtime

[@thethiny]

Or hash

[@i123iu]

Isn't this completely useless when the password is really hashed? Even similar passwords result in a different hash and therefore the timing is completely random.

[@AppleUpdatez]

Would this mean that it would be a good practice to put a ' or a " in my password?

[@rubixtheslime]

In general, using more than just letters and numbers is a good idea. But that's probably not going to stop it from working altogether, as you could first try to do it with just lowercase letters, then alphanumeric, then full ascii, for example.

[@josephcohen734]

It'd be cool to see a whole vid that briefly talks about all the different ways hackers can attack passwords and the ways actual servers store passwords to protect them

[@mCoding]

You are gonna have a bad time when you realize how many ways there are :*)

[@Lodinn]

One [somewhat similar] example of an attack was comparing power consumption of a CPU affirming valid passwords vs checking wrong guesses. Storing though, it changes sometimes but has been hash+salt for quite a few years. In cryptography, devil's in the details - even using something tried like bcrypt for password storage, it's very easy to write an insecure application because you didn't enforce rules about transport layer security (by misconfiguring http/https), by accidentally exposing too much client-side, allowing an attacker to steal cookies or hijack the client for CSRF. Huge companies/projects, KZbin included, have fallen victims to this at various points in time.

[@ThePC007]

Actual servers shouldn't store the passwords at all. Typically they just store a salted hash of the password instead.

[@nyferox5637]

Wow, this was a really great video. Very interesting

[@mCoding]

Glad you enjoyed it!

[@Tortle6]

Could you avoid this type of attack by just doing time.sleep(random.random())?

[@ДмитроПрищепа-д3я]

Technically yes, but a way better solution is just hashing the passwords. Then the time between request and response will be entirely meaningless to the attacker.

[@Wiedzmin940]

Very interesting video. Sure thing, this is not a real-world example, but still the concept is mindblowing. By the way, this moment when you ran the code and you put soundtrack there was really satisfying trifle and I liked it :)

[@mCoding]

Thanks! Glad to have you watching!

[@jupyter5k647]

Haha the other day i was wondering how this kinda thing would go about. And voila here a thumbnail and a title of my thought popped up in youtube. Nice

[@mCoding]

You're welcome!

[@zeusek-2137]

Okay, but if server stores only salt of password is this method still useable?

[@amirdarvish9167]

why didn't you use pyhton built-in comparison operator (=) ?

[@chaoticprogramming]

Use a hashing algorithm which should make the checking almost the exact same time, limit tries to once per three seconds, how do you crack that?

[@ksrikar6668]

That's some quality content sir 🙂👏👌

[@mCoding]

Thank you very much! Glad you liked it!

[@ScorpioneOrzion]

so would like a constant time that at least is needed for all characters to compare, be better like that it responds about in 1 millisecond regardless of what your guess is?

[@mouniryahyaoui12]

Thanks it’s very interesting ! It worked well on length but for the characters it range between w and z for all of the characters in the str password. If you’ve an hint on the why I’d be very interested. Thanks a lot for your work this KZbin channel is like breathtaking ! Really nice

[@Kataroku]

He mentioned it earlier in the video - server latency / lag can lead to false positives.

[@ollie-d]

Interesting example of a timing attack, although I think this is not practical since there are so many trivial ways to guard against these attacks for password verification. Good video though!

Lol, protecting against it is definitely not trivial.

[@Dorchares]

Do you always pay attention to write this kind of eloborate codes? I mean there were no warnings on the pycharm.

[@mCoding]

I've done enough coding to know what PyCharm likes and doesn't like, type hinting things helps a lot. So it's pretty second nature to me now.

[@minuspi8372]

Couldn't this be resolved by enforcing a random minimum time and a random additional time for the check?

[@ДмитроПрищепа-д3я]

This can also be solved by rate-limiting clients. And the best way is to just not store passwords as strings, use a decent hashing algorithm, like argon2.

[@michaelmoran9020]

So to clarify this achieves nothing if they hash their passwords?

[@nanophree]

Would just putting a sleep function with random amount of ms fix this?

[@justinjiang1052]

most servers only store the hash, so after hashing the guess, the time of comparing two hashes wont help.

[@vinny142]

So remember guys, allways add a random-length delay to your password checks. You should always add a delay anyway to make brute-force atacks futile, but a RANDOM delay makes this timing stuff useless. Checking passwords is the one thing you never ever want to do quickly.

[@Fizzfaldt]

Random length delay (delay for random time in addition to checking) doesn't work. That still leaks some information. If you can do a sufficient number of attempts you still learn something. On the other hand if you can find the longest anything COULD take, you can pick a random *total* time that's always larger than that. Then the only info you leak is information about the min/max that you allowed on the random timer.

[@brawldude2656]

@@Fizzfaldt Just choose an execution time let's say 4 seconds. Then look how much time passed during the check and sleep (4-passed_time) seconds and boom you always give 4 seconds to the attacker.

[@Fizzfaldt]

@@brawldude2656 yup! That's exactly what I meant:)

[@OrtinFargo]

Random question does the python == on string actually correlates to that function cause I tried it out and it definitely was more difficult

[@mCoding]

For CPython, you can find the definition of string compare here: github.com/python/cpython/blob/main/Objects/unicodeobject.c, see the function unicode_compare_eq. You can see it does a length check and then does a memcmp, which is usually implemented as a for/while loop comparing byte by byte (so technically not character by character because unicode may use more than 1 byte per character).

[@OrtinFargo]

@@mCoding Yep guessing that it is c it is much more harder to notice the time difference

[@stkyriakoulisdr]

I wonder, would a genetic algorithm with the fitness function being the time it took for evaluation of a predicted password work better than the iterative approach? Well, I guess I have the whole night to find out

[@SkielCast]

Any Update on that?

[@stkyriakoulisdr]

@@SkielCast Certainly. the genetic algorithm was utterly useless. The reason is that the "vanilla" evolution strategies approach essentially mutates any part (character) of a solution (candidate password) with the same probability. But the string comparison function stops when it detects the first character mismatch. And the execution time of the string comparison is the fitness/objective function. So the first characters are more significant and so, by randomly changing any part of the string (that the GA does) makes the search very unstable.

[@SkielCast]

@@stkyriakoulisdr But maybe that can be solved using an alternative encoding like Gray code to reduce the impact of significant bits or maybe implementing mutation as a random shuffle

[@YeloPartyHat]

Great video! Very well explained!

[@mCoding]

Thank you!

[@markusstaden]

In the real world, the hashing process would protect against this, right? Since it ends up in a constant length and doesn't change character by character.

Nope, the attacker can still retrieve the hash and reverse it if the password is weak.

[@jacksonyan7346]

Very cool concept, and I tried to crack my past final exam pdf with this, and sadly (or fortunately?) it didn't work :(. I guess Adobe wouldn't be Adobe if anyone can just crack its product with a minimal amount of programming experience and 10 mins of Youtubing.

[@circuit10]

This can only work if there is a known plaintext password being compared to, that's not the case for a PDF or you could just extract it directly (unless this is on a server)

[@Clientastisch]

No one would check for the length first. Just hash comparison. To sum up: of course checking the length and THEN doing something will take longer then just checking the length and returning false… I don‘t really get the point. And other people also correctly pointed out that this won’t work in real world due to network delay

[@ProbabilityOverdrive]

5:55 Is iterating over zip(guess, actual) not preferred to using range(len(actual))?

[@LordTails]

Had to look this up to fact-check myself and I have problems when it comes to speech but... zip takes in iterables and returns an iterator with its own things that in turn get referenced. Range here generates a single list that can give you an index to every letter in the string variable "actual". My guess is that range is faster since there is less to do in order to produce a result. Then again it may just be easier to follow with using range. I'm curious to see a timed run comparing each still.

[@ProbabilityOverdrive]

I wasn't even thinking about speed, but rather, what is "Pythonic". We generally want to avoid iterating using an index without an explicit reason for needing it.

[@LordTails]

@@ProbabilityOverdrive I see what you mean. From my experience, I'd say range is more Pythonic (I assume you're referring to readability and simplicity when saying that). It's more easily understood to use range(len... since it is a thing in about every computer language you'd use for calculations. From my experience if it works well, is easily understood, and is concise I wouldn't fret about using indices (especially when first writing a code and just trying to get it to work). I prefer speed and being clear rather than focusing on convention. Then again I started with Python, worked with C++, C#, and Java, then came back to Python/Cython so that's just my preference.

[@foqsi_]

I like the way your head moves when you speak.

[@lsh_]

Can you do something with abudant numbers an optimice it like the prime solver?