I'm a big user of https://www.grc.com/passwords.htm to get strong passwords. However, having to go to the site and manually copy the password every time gets old fast, so I decided to do a little script to do it for me. Every time you reload the page, it presents you with new passwords in plain text, so this is the script.

curl 'https://www.grc.com/passwords.htm' | grep '63 random printable ASCII characters:' | sed 's/^.*size=2>//' | sed 's/<\/font>.*$//' | pbcopy

Since there's no identifying classes or IDs, I get the page through curl, pipe it to grep to get the line I want ("63 random printable ASCII characters:"), and then I use sed to delete everything up to the password, as well as everything after it, finally copying to the clipboard with pbcopy.

This all works fine, except for one small detail. The string I get in the end should always be 63 characters long, but it's not. It usually varies between 64, 67, 70 and 73 and I have no idea why.

Can anyone shed any light on this?

  • I seriously wouldn't trust a server-side generated password. – Dennis Dec 29 '12 at 20:02
  • That is of course your choice, but we're not talking about amateurs here, we're talking about extensive knowledge and research. Just read the first few lines on the page, and you'll see why it's safe. – user137369 Dec 29 '12 at 20:14
  • The design seems sound. The problem is that the server generated the password. That means they know it. – Dennis Dec 29 '12 at 20:16
  • @user137369 The danger is in the remote provider storing the generated passwords (for any reason) or someone intercepting network traffic (again, for any reason). No matter how clever the generation algorithm is in getting really random bits, you're opening yourself to e.g. "dictionary" ("all passwords generated by GRC in 2012") attacks. – Daniel Beck Dec 29 '12 at 20:16
  • Please read the website (most of it is interesting for this subject), but again, even the first lines answer those concerns. Cracking 63 characters is not even realistically feasible by today's standards, and even if you could get "all passwords generated by GRC in 2012" (which you cannot), since they're used in different websites that themselves hash it, you'd need impossibly long rainbow tables and combinations to do it. Furthermore, the page can only be shown if a secure connection is available. – user137369 Dec 29 '12 at 20:35

As mousio already said, the problem is the HTML encoding of some special characters.

Perl can convert those reliably and easily:

curl 'https://www.grc.com/passwords.htm' | \
    grep 'ASCII characters:' \
    perl -MHTML::Entities -ne 's/.*2>|<.*//g; print decode_entities($_)'
| improve this answer | |
  • grep gives me an error (the -P option does not exist). Probably we're using different versions of it (I'm on OSX). – user137369 Dec 29 '12 at 20:42
  • Interesting. Well, the perl part is the important part. You can either keep using sed or perform the replace with perl (see updated answer). – Dennis Dec 29 '12 at 21:02
  • Although I never used perl, right now I can read that command and just about understand what it is doing, and it is much more efficient than my extensively verbose command. Thank you, marked as the new best answer. – user137369 Dec 29 '12 at 21:14

It might have to do with HTML encoding, where e.g. a < in the 63 characters is actually represented as the entity &lt; in the source, making your string a bit more lengthier.

| improve this answer | |
  • Thank you. That was exactly the case. The command is a lot more verbose, now, but it seems to work every time. curl "https://www.grc.com/passwords.htm" | grep "63 random printable ASCII characters:" | sed "s/^.*size=2>//" | sed "s/<\/font>.*$//" | sed "s/&quot;/\"/g" | sed "s/&apos;/'/g" | sed "s/&amp;/&/g" | sed "s/&lt;/</g" | sed "s/&gt;/>/g" | pbcopy. If you know of a less verbose way to do it, I'd appreciate it (as long as it does not need any tools not installed by default). – user137369 Dec 29 '12 at 19:47

Here is something for you to consider - the resulting string of your script may often contain certain characters that are not being escaped properly in the sed operations.

For example, these characters may be suspect: brackets, single and double quotes, curley braces, exclamation points and the forward and back slashes, and asterisks.

I would try stripping one of these characters from the returned string in a series of tests, comparing the results to see if the removal of one of any number of these characters will bring the count to 63.

| improve this answer | |
  • The sed operations were done one by one and tested as I went along. See mousio's answer, he found the problem, it had to do with the HTML characters that have special encoding. – user137369 Dec 29 '12 at 19:57

Based on your comment to mousio, your chain of grep/sed... can be reduced to one command:

Perl is usually installed by default

perl -ne 'next unless /63 random printable ASCII characters:/; s/^.*size=2>//; s/<\/font>.*$//; s/&quot;/"/g; s/&apos;/'\''/g; s/&amp;/&/g; s/&lt;/</g; s/&gt;/>/g; print; exit'

Not all sed's understand this syntax

sed -n '/63 random printable ASCII characters:/{s/^.*size=2>//; s/<\/font>.*$//; s/&quot;/"/g; s/&apos;/'\''/g; s/&amp;/\&/g; s/&lt;/</g; s/&gt;/>/g; p;q}'
| improve this answer | |

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.