Posts Tagged ‘password’

One of the things that has always fascinated me is when you are watching some Hollywood movie and they talk about stuff like “rotating string cipher encryption with a strength of 228 bits”. Now this has always sounded both funny and interesting to me. Like what if you could convert data that is normally static into actual continuous rotating data? This morning it hit me, this is something we can actually accomplish with password hashes. We can rotate them continuously, without the user even noticing and hopefully make it harder for attackers to crack the hash. Which is the main goal of this “idea/solution” making it harder or hopefully impossible for attacker to crack the hash when they obtain it. Here is a PoC preview output, screenshot OTP and usage OTP don’t match because they were obtained at different times:


./ S3cretP4ssword 545130
 Current password hash:
 Login OK
./ S3cretP4ssword 545130
 Current password hash:
 Login Failed

Like you can see we attempt to login with the same credentials both times and yet the second time this fails. If you are impatient then you’ve probably guessed that this is due to the added 2FA data in the login credentials and as usual you can jump straight to the code on my github. Now if you are curious how this works and how you could set this up in a real life setup keep on reading, do note that I haven’t tested this yet on a real life environment however. The setup is actually one of the important parts for this to work and actually slow down or hopefully prevent an attacker from successfully cracking the obtained hashes.

Now after you’ve read that you are probably thinking “shut up already with those ‘uncrackable’ claims” and yeah you are correct. It can probably be cracked, but hopefully we can settle for the second best which is (tremendously) slowing down the attacker.

For the remainder of this entry we will be focusing on further protecting the stored hashes and not on how to protect the in transit plain text password. This since obviously if you have full control of a server where the SSL is terminated you could just intercept all passwords in plain text. This can be solved with fancy challenge-response protocols or maybe (in browser) public-key cryptography. For now, let’s dig further into this ‘continuous changing hashes’ concept.


Just when you think that all possible google password dorks have been found and documented. For the ones still not familiar with the google hacking database (just click it) :)

I just stumbled upon this new dork to find passwords(and all other kind of interesting network related data(just enter the following into google):

ext:pcap password

example stuff you can find(I have censored the sensitive information using ***):

+OK Hello there.


-ERR Invalid command.

USER ***

+OK Password required.

PASS ***

+OK logged in.


+OK 0 0


+OK Bye-bye.

This was just a quick post…cause I honestly didn’t think people would STILL let google index their sensitive stuff.