6

So I really have no idea how to better describe this than the title.

So I discovered this website called pwnedpasswords, where you can apparently check to see if your password's sha1 hash has been leaked somewhere. So I made a script to automate the process, here's my script:

#!/bin/bash

read -s -p "Input your password: " your_pw
echo
your_hash=$(printf "$your_pw"|sha1sum|tr '[:lower:]' '[:upper:]'|head -c40)
hash_head=$(printf "$your_hash"|head -c5)
hash_tail=$(printf "$your_hash"|tail -c35)

pwned_count=$(curl https://api.pwnedpasswords.com/range/${hash_head} 2> /dev/null|grep "${hash_tail}"|awk -F ':' '{print $2}')
echo "Your password has been pwned ${your_pw} times"
echo "Your password has been pwned ${pwned_count} times"

And I used as a test password 1, and this is the output:

[me@my_compuuter aaa8]$ ./was_your_password_pwned.sh
Input your password:
Your password has been pwned 1 times
 timesassword has been pwned 197972

Notice how when I echo "Your password has been pwned ${your_pw} times" it gives me the correct format ($your_pw is just the password itself), but when I echo "Your password has been pwned ${pwned_count} times" it gives me this weird format where it takes the times from the end and somehow overlaps it in the beginning... I have no clue what's going on...

Can somebody figure it out?

7

The list returned by that site has lines terminated by CR/LF. A CR (\r) will move the caret/cursor to the beginning of the line:

printf 'good \r times'
 times
  • Wow thanks! I just added |tr '\r' '\n' to the end of the pwned_count variable and now it works properly, thanks! – user323587 Mar 17 at 19:23
  • 6
    @user323587, tr -d '\r' would be more common, it actually removes the carriage return. Changing it to a newline of course works in your case, too, since the command substitution removes all trailing newlines. – ilkkachu Mar 17 at 19:31
  • 1
    Note use of CRLF line endings is common in Internet protocols, and in particular is required for content-type: text/plain in MIME (email, or news), see rfc2046 section 4.1.1. It not clear all MIME requirements should (or sometimes can) carry over to HTTP, but it is best to assume they do when there is no statement or clear evidence otherwise. – dave_thompson_085 Mar 18 at 4:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.