Questions? Comments?
Persistent rash?
Use this Contact Card
Contact:
GetHammered

Thor's Password Machine

1000100 1110010 1101001 1101110 1101011 100000 1101101 1101111 1110010 1100101 100000 1001111 1110110 1100001 1101100 1110100 1101001 1101110 1100101 100001 100000

Hello, and welcome! As with most HoG tools, this is the only password tool in the universe that actually gives you a tangible strength metric by which to gauge password composition and complexity for effective development and enforcement of policy. You can get the full description and explanation below. Note: don't use any of your actual passwords; use test passwords of similar structure and form. Or, go ahead and use whatever you want to. Nothing is logged, stored, or otherwise examined. And even if it was, there's no way I would know WTF the password went to. But do whatever you want to. Here, we default to Class=F. If your administrators don't use this, they default to Class=none.
"Latest Features" moved here.

Conversations regarding passwords has flared up again, and I want to make sure you are aware of the most critical part of choosing effective passwords, and that's what they will be used for. For instance, my bank will lock out my account after 5 unsuccessful attempts. I don't need the password complexity they require. If you are interested, here is some Password Myth-busting.
☮ The default setting is Class F.


☮ Enter the password you would like tested:


Terminology Legend
Some of these are painfully obvious, so my apologies if it seems like I'm calling you a nimrod. I'm not. Yet.
Pwd = The word Password abbreviated.
MD5 = The MD5 hash of your password, linked to Google to see if it, by chance, it exists elsewhere.
SHA1 = The SHA1 hash of your password, linked to Google to see if it, by chance, exists elsewhere.
BF = Abbreviation for Brute Force. No, it's not what you are thinking in that dirty-mind of yours!!
BF Class = The selected iterations per second of the chosen class.
Pwd Iterations = This is the number of iterations required to reach your specific password based on the selected base ordered by the BF Base.
✎ = This icons represents the value of the cell above converted to actual, written notations for ease of immediate recognition of just how freaking big the number is.
Time to Crack = This is the time it will take to reach your particular password based on the iterations (Pwd Iterations) and the iterations-per-second selected.
The unit of measure is automatically selected based on a preconfigured range. Seconds, minutes, hours, days, and years are all stored in their own variables. The selection is based on the following:
- if seconds are less than 1000, seconds will be the unit of measure.
- else if minutes are less than 1001, minutes will be the unit of measure.
- else if hours are less than 1000, hours will be the unit of measure.
- else if days are less than 1462, days will be the unit of measure.
- else years will be the unit of measure as none of the previous criteria would be met.
J.H. asked for me to carve out all available units as other people don't' necessarily think as I do (if you can image that) so I, of course, provide for HoG'ers! That and he threatened to publish those pictures from BH Vegas. Just so you know, had I known it was really a statue, i never would have tried it. The full figures are on the "Additional Stats" tab.
Key-Space Iterations = This is the total number of iterations required to exhaust the entire key-space (as opposed to just your password). This may be helpful to you to determine 1) How much weaker your password is than statistics based on the entire key-space and 2) a better frame of reference for what is and what could be.
Time to Crack = This "time-to-crack" measure is for the entire key-space, again opposed to your particular password.

show

Your Pwd

TheHooch
show

Pwd Length

8 (eight)
show

MD5

bf3225e7082b002fc5a1ed0d1b74d1b6   ☜ Google Lookup
show

SHA1

show

BF-Class

1,000,000,000 (one billion) per-second.
show

BF-Base

52 (fifty-two): abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
show

Pwd Iterations

47,451,614,958,548     (Scientific notation of: 4.745161e+13)
show

✎

forty-seven trillion, four hundred and fifty-one billion, six hundred and fourteen million, nine hundred and fifty-eight thousand, five hundred and forty-eight.
show

Time-to-Crack

Minutes: 790.86
show

✎

seven hundred and ninety-one.
show

∑

The below section displays the total iterations for the entire base's key-space:
show

Key-space Iterations

54,507,958,502,660     (Scientific notation of: 5.450796e+13)
show

✎

fifty-four trillion, five hundred and seven billion, nine hundred and fifty-eight million, five hundred and two thousand, six hundred and sixty.
show

Time to Crack

Minutes: 908.47
show

✎

nine hundred and eight point four seven.
show

Iterations (recap)

47,451,614,958,548     (Scientific notation of: 4.745161e+13)
show

✎

forty-seven trillion, four hundred and fifty-one billion, six hundred and fourteen million, nine hundred and fifty-eight thousand, five hundred and forty-eight.
show

Seconds

47,451.61
show

✎

four hundred and seventy- thousand, four hundred and fifty-one point six one.
show

Minutes

790.86
show

✎

seven hundred and ninety point eight six.
show

Hours

13.18
show

✎

thirteen point one eight.
show

Days

0.55
show

✎

zero point five five.
show

Years

0.00
show

✎

zero.
 Click printer icon for hard copy.
T
TPM's Featured Feature!
MD5 and SHA1 hash generation, with an automatic link to Google to see if your hash is out there.
Not only are "Rainbow Tables" far overrated, some actually consider them some sort of "magic" password cracker. They are great tools against specific, known character composition hashes - i.e. passwords consisting of Upper/Lower/Digits with up to, say, 9 characters or so. And they are almost a requirement for repeat engagements where they have been built specifically for any given scenario. But, the thing to remember about RTs is they cannot match against anything they are not generated for. To show where they can be effective, I've used "Scorpio" as the password I want to check - it would require at the least tables comprised of Upper and Lowercase letters and character sets of at least 7 characters. The image to the right shows how the straight (unsalted) password is easily found just Googling for the hash, itself.
Stacks Image 170
Rainbow Tables are impotent against "decent passwords" with a cryptographically strong salt. Since you are reading this, you're obviously using TPM to gauge your passwords so you have an idea what that means. Actually, you could have "crab" for your password and a proper salt will thwart RTs - that's kind of funny too as crabs properly seasoned are yummy. Unless you got them in Vegas. Anyway, where RTs CAN be of use is if you have an unknown salt, but somehow the Ghost of Bob Marley has told you the passwords *and* salts together are less characters than the maximum generation of the RT. It's a good bit entertaining to hear what some folks think RTs are. Now try "Scorpio" with the SHA1 link. Scary, huh? Actually, it's not. The default password of "TheHooch" has no matches, as no one has gone through the trouble of created a rainbow table for upper and lower case letters. They're available, but apparent not online. You see, Hash is Hash (unless you're in Taiwan). The main difference is length, which is a manifestation of the hashing algorithm. Every character combination's hash is theoretically unique. No word other than "Scorpio" should have the SHA1 hash 267d8ca2af1eefa7c7c5fb508f24a3c218725a2a. Notice the "should." The MD5 algorithm has produced "collisions" where two inputs have the same output. Theoretically, if your password is ShammaLammaDingDong, I just might be able to use "TheHooch" to get in to your account. SHA1 has mo, betta, and different algorithms, and supposedly is supra-resistant to collisions. But we'll never know. Actually, just use SHA256 to compare logon data with restored hashes and this all becomes academic.
Additional recent features
Direct "Print Results" function
While I've kinda liked the colors of the previous table-style (which was way easy to read if someway cheesy), I've changed it to a more plain "black on grey" format. This also gives the Print function more uses. I originally just figured folks would print direct to a pdf or something, but then realized that someone way actually want it on paper. This way you can print it and then put it on your administrator's chair telling him he's a wanker for making you use big, stupid passwords.

Formal Notation
Through MadDevSkilz, I present numerical data in Formal Notation now - you know, like reading spelled-out numbers and all! Every time I looked at the results of a password, I had to cypher for a few cycles to figure out exactly what the HUGE numbers were. Now we don't have to.

Sticky Class
Brute Force Class" selection is now sticky through page loads. The default is Class F, however previous class selections are retained through page reloads. I've found this to be quite helpful when you are checking multiple iterations of a password and don't want to have to set the desired class each time.

Huge Notation Foo
Through my Not-So-MadDevSkilz, you may see number-to-notation anomalies on really, really huge written number results. Still trying to get that sorted. That said, if you do, then you have no worries about your password strength.
Introduction to Theory, Application, and Mechanics
After you've finished reading, I recommend watching the Password Metrics presentation i've converted and posted here. You just might be surprised as how much of your time and effort people have been wasting making you use silly combinations of Upper, Lower, Special, Number, etc in your password. Am I a password expert? Nope. Never believe anyone who tells you they're an expert at something. I just put thought into things and share my opinions. My intimate familiarity with passwords comes from being a password user. That and I do a lot of math in my head. No, it's good. It keeps me from doing other bad things in my head. Anyway, when I'm forced to use some wanker password, I can't help but set the noggin to chewing on it. Well, enough to confirm it's a wanker password anyway.
The Mechanics
I think the Password Strength qualifier is very valuable.  Administrators tell users that their password must be "complex" (which users hear as "difficult") but they don't tell us what makes a good password/passphrase "good."  Password strength meters I've seen simply make a Best Effort to say "bad, good, better" or some ambiguous qualification.  But nothing ever actually quantifies a strong passphrase.  I wanted to do something differently - as such, I've decided to add a measurable and valuable attribute where I actually calculate how long it would take to crack the key-space of the password you've selected based on they "base" characters you use.  I look at it this way:  To really pick a good password, you should assume the best case scenario for the attacker, and the worst case scenario for you.   When an attacker brute-forces your password, they basically iterate through all possible character combinations.   a-z, A-Z, 0-9, the top row !@#$%^*()-=_+ characters, and then other printable characters like ~, {>, etc.  Of course, it is not always like this, but it is typically how they go about it.  If you enter "abcd" as your password, that being 4 all lower-case characters, the attacker shouldn't know that, but you can't be sure.  If they DO know that, then you are toast.
Stacks Image 1657
Get it?? Al-gor-ithms?? I know; it’s a gift. Anyway, let's talk math. Math, math, math. The reason this is a concern is all an attacker has to do is iterate through all possible combinations until they get your password - in this case, begin with a, and loop through over and over.   Actually, I shouldn't refer to "all they have to do" in the diminutive like that. As you'll see, you can easily make it effectively impossible. The entire key-space to guess a 4-character lowercase password is 475,254.  Oh, one thing - almost all the "brute force" crap I see on the internet tells you that brute forcing a 4-character lowercase password is 456,976 (or 26^4).  That is incorrect - the iterations would only be 26^4 if you STARTED OUT with 4 characters as the base aaaa instead of starting at a.  You've got to get to aaaa first by going through a, aa, and aaa.  To properly compute this, you would have to use  26^4+26^3+26^2+26^1 as your formula.   The difference between 475,254 and 456,976 may not seem like much, but there is a 5.6 trillion iteration difference just when you get to 10 characters.   So right from the start, systems using that formula are simply wrong.  TGP calculates the entire brute-force effort required to get there from a where an attacker would start.  Further, I look at the password and try to determine the minimal base key-space it uses.  If you type in abcd then I'll only use a-z.  If you type abcd1 then I'll give you a-z and 0-9 (increasing the base to 36).  If you type abcD then you get a-z and A-Z, or base 52.  If you use abcD1 then you get base 62.  A ! or & character gets you to base 76, and finally a [ or ~ then you get the total 94. 


Now, I obviously have to make some assumptions here, but there's no other way formulate useful algorithms without some manner of postulate.  Deriving the base from what an attacker would have to use makes sense to me.  Combining that with the "known" information of what you are typing in makes even more sense.  So that you know, I'm assuming what an attacker would have to assume if he knew some of what you know (as odd as that may sound).  So I group the bases as a-z, a-z, A-Z, 0-9, ! through = and then everything else.  So if you type A I have to assume that you've probably got lower case in your password.  So a single A is up to 52 possibilities since I count lowercase.  0-9 is always just added in when used - a1 is 36 (26+10), and A1 is 62 (52+10).  A single ! is 76, so A! is base 76.  A single [ is 94, so A[ is base 94.   So finally, if you had Ab44! then the entire key-space would be 76^5+76^4+76^3+76^2+76^1 or 2,569,332,380 combinations.    For reference, the actual base characters I use are broken out as follows - these "base" character sets are what correlate to the “Key-space Derives 'x' of 94” above in this order:

Base 10⑆ 0123456789
Base 26⑆ abcdefghijklmnopqrstuvwxyz
Base 36⑆ abcdefghijklmnopqrstuvwxyz  0123456789
Base 52⑆ abcdefghijklmnopqrstuvwxyz  ABCDEFGHIJKLMNOPQRSTUVWXYZ
Base 62⑆ abcdefghijklmnopqrstuvwxyz  ABCDEFGHIJKLMNOPQRSTUVWXYZ  0123456789
Base 76⑆ abcdefghijklmnopqrstuvwxyz  ABCDEFGHIJKLMNOPQRSTUVWXYZ  0123456789  !@#$%^&*()-=_+
Base 94⑆ abcdefghijklmnopqrstuvwxyz  ABCDEFGHIJKLMNOPQRSTUVWXYZ  0123456789  !@#$%^&*()-=_+ 
        []\”{}|;’:,./<>?`~

The above groupings are just how I chose to organize character sets based on how I’ve seen different crackers implemented, and the way I’ve seen the propensity for people to group top-row special characters together like T$i*D3 as opposed to T$i]D3. There is nothing in the 'hacker handbook' that says you check for any particular special characters in order, other than some that iterate in ASCII order, but I try to group these the way a person would create the password even though it is a computer cracking it.  There is no "right way" and there is no set 'hackers do THIS' way.  Just know this as you think about how this applies to your password policy.  No, I didn't forget A-Z 0-9.  I just didn't find value in all upper and digits as I normally don't see that.  I see all lower and digits because it is the default.  That's not to say passwords won't be all upper with digits, but rather, that I have chosen to have represented by base 62, and more importantly, "all upper-case and digits" is mathematically equivalent to "all lower-case and digits" now isn't it? Trying to pull a fast one on me, eh? So just use Base 36 - it's the same thing.

Now - with THAT information, I take the highest class of cracking (Class F) which is 1,000,000,000 (one billion) attempts per second.  That's a bunch.  Again, I want the worst case for you so you know how strong your password is.  I then calculate the amount of time it would take to crack the key-space of your password and display that.  In the above case of Ab44! the entire key-space would take a whopping 2.56933238 seconds to crack!  That should tell you something.  It may be considered "complex" since it has upper, lower, numbers, and a special character, but 2.5 seconds isn't that much.  Granted, most ankle-biters with a cracker will only get a few 100,000 per second, but we have to be sure.   And this is where the power of this type of analysis comes in - don't tell your users to have a "strong" password (whatever that means), but rather, require that they have a password that can withstand a Class F attack for X time (whatever you decide).  That way you have something you can MEASURE.  And that's good. So let's look at the above screenshot - I used aaaaaaNotGood as the password.  That's 13 character mixed case characters.  The key-space to attack that would take 650,000 *years* to crack at Class F.  Seems strong, right?  Well, that's what got me to thinking.  Again, I let myself limit my imagination by looking at it from the attacker's view.  Why do that when I *know* the password I'm entering?  That's when I decided to write an algorithm to calculate the iterations required for the actual password I ENTERED to be reached, and not just the entire key-space.   THAT's where the real value comes in.  Don't just quantify the key-space, quantify the actual password.   The algorithm I wrote worked well, but it was not super-fast -- so I'm using a formula my buddy Will Fischer came up with (Thanks Will) since it's better than mine.  He's actually helped me quite a bit with this, so thanks^2.  Since we know the password, we basically calculate out the steps required to hit each individual letter in each column based on an index string I define in memory from "a" on.  That string allows me to easily determine what the character is a column (character) at a time,  for each character in the password.  I then compile the column-by-column data into a final "iterations" value that is then in turn compared to Class F.  As such, we see that the 650,000 year key-space for aaaaaaNotGood is reduced to 12,637.66 years since I chose to begin my passphrase with 6 lowercase a's.  Simply changing the first "a" to an "H" takes the calculation from 12,637.66 years (based on 398,541,262,291,912,000,000 combinations) to 13,297,482,476,338,200,000,000 iterations, or 421,660.40 years.  Still a big difference between an "a" and an "H" and the overall 20,724,145,598,800,400,000,000 iterations for the key-space at 657,158.35 years.
Classes, brute-force, and dictionary attacks: The Obvious

Mr. Wayne Anderson, a fellow Focus-MS participant, and other folks suggested that I add a user selectable value for the brute force class; this has been added, and it was great idea. I love it when the community works on things to everyone's benefit. I actually thought about doing this when I first wrote the tool, but I wanted to make sure that the user saw the “worst case scenario” for cracking. If you build your password strength from the worst case, that being a Class F at 1 billion iterations per second, then you really don’t have to worry about attacks on slower platforms. However, I can see the value in being able to select your own class.
Part of the reason for this is so that you can see what a “real world” attack will look like. Not everyone has the NSA trying to get to their data. Also, I think it is valuable for when you don’t get to choose your password strength and want to know how much risk you are at by normal, everyday attackers.  For instance, take the following screen shot from a Cisco product:
Stacks Image 364
In this product, you had to create an Admin user.  But note the restrictions: “Your password must be less than 8 characters and cannot contain spaces or special characters.” Nice. Thanks, guys. In these cases, I’m forced to use a crappy password.
Selecting the worst case for the attacker, a Class A attack at 10,000 per second (which your printer could probably do in its spare time), you get a max of 61 hours to crack the key-space of a base 62 (a-z,A-Z, 0-9) password. Something like AaZzaa99 cracks in 26 hours. When you consider this, Wayne has a point that this type of "lower class" attack could be valuable.  I never thought I would care about low class attacks.  Ba-dum.
In this product, you were required to create an Admin user.  But note the restrictions: “Your password must be less than 8 characters and cannot contain spaces or special characters.” Nice. Thanks, guys. In these cases, I’m forced to use a crappy password. Selecting the worst case for the attacker, a Class A attack at 10,000 per second (which your printer could probably do in its spare time), you get a max of 61 hours to crack the key-space of a base 62 (a-z,A-Z, 0-9) password.

This also could provide you some insight when it comes to how secure certain other restricted and default passwords are. For instance, let’s just do a quick search for “mailing list memberships reminder.” This query will provide all sorts of links to archived emails where the admins of mailing lists didn’t think about how their reminder notices to users, which contain the full username and password, are archived to lists and thus index-able via your favorite search engine. While we won’t need to crack these as they are already clear-text, you can see how most are simple lower-case 8 character random characters. For this, you can brute-force the entire key-space at the slowest class in only 217 seconds, or roughly the time it takes to listen to AC/DC’s “Have a Drink on Me.” Nice.
Classes, brute-force, and dictionary attacks: The Not-So-Obvious
The "obvious" example was, um, obviously, um obvious. Pure math, and two factors contribute to whatever risk you wish to assign to it:
1) An attacker unequivocally know the extents of the password restrictions. When they find the device during whatever scan they make, they'll see the make and model of the unit, and upon examining the manual online, they know all they need to know.
2) The most important factor is the fact this unit has no password lockout capabilities. You can brute force it all day long without it locking out. The only restriction is the speed by which you can execute the attack. A basic way to look at risk is a factor of "likelihood" + "impact." Impact is up to you to decide. But likelihood is high as you can't stop it.
Keep those factors in the back of your head as we discuss the following service. There is a bigger point to be made. This was my requirement for creating an account with a finance-related service. You may not know this, but I am a self-made thousand-aire and am very skilled in managing my 2 shares of Google stock!
Stacks Image 1297
Take a look at the screen-shot of the "Create User" processes where I had to set my password. It looks pretty standard for these types of services, but let's examine the requirements and see what it tells us about the technical implementation as the policy implementation.

The "6-20" characters requirement seems reasonable, but I wonder why they restrict it to 20. From a "strength" standpoint, 20 character passwords far exceed anyone's requirements and (with today's technology) can't be broken before our sun goes Red Giant, destroying all evidence of our existence in the universe, and thus rendering my futile attempts to make money moot. The 20 character restriction obviously indicates they are aware of the fact length dictates the "strength" of a password more than anything else. All they need do is make the restriction 11-20 characters which could take up to 45 days to crack IF they could make 1 billion attempts per second. But here's the real question: exactly HOW is the attacker trying to brute force? Via the web interface? If so, they might get 500 RPS (requests per second) . But let's give them the benefit of the doubt and give them 20 times what they could do, or 10,000 per second. If only an 11 character password, AND if it were only lowercase letters only, it could take over 5,100 years to crack with over 1.6 quadrillion combinations. It will lock you out after 5. Hmmm. What if it were only 8 lowercase letters? It could take almost a year with 217 billion combinations. It still locks you out after 5.

So that's bull-dog-nanny. Now, when you see "6-20" your brain says "20? Fark that. I'll just do the 6." Also because you have to do upper-lower-digit. That's a maximum of only 66 days at 20x their capabilities and ~ 58 billion combinations. It still locks you out after 5 tries.

So I ask again, "why?" Are they protecting against a break-in where an attacker gets the user-base password hashes? Why does that make a difference? If I'm inside a system to the point I am accessing the actual password hashes for the users, then I don't need the password, now do I? It's the old "barn door" and "horses" thing. In fact, as I've said a few times in different posts, why would I care about someone's password when I can simply change the hash to a known value and access everyone's account? There have been many a BlackHat conversation where people were all proud of cracking the hash because "they got a user's password." I don't think I've every received a "real" answer when I say - "So what? What did you do with it?" The one thing I can stretch to contrive some value is where someone assumes the user has some other account somewhere and they've used the same password. But man, that is indeed a stretch. You've read this far, so you've some interest in this - if I'm wrong about that or not seeing something, please let me know.

The last bit is the best though: "Your password should be easy enough to remember without writing it down, but difficult to guess." Wow. upper, lower, digit, up to 20 characters and you're supposed to remember it all the time. This is pure-T bullshit they are throwing out there just in case they get popped and you have an "easy to guess password" they can blame you. Period. Which brings us to the last "suggestion" - "Avoid words in any language." Wow. Just, wow. And of course, no "slang, dialect, jargon, etc." This is just a a blatant way of saying "we don't know what we are doing, but it doesn't matter, because any breach will be your fault."
Classes, brute-force, and dictionary attacks: Summation
The checker automatically changes the labeling to reflect seconds, minutes, hours, days, and years. So if you are mucking about with a password class and see that the number doesn’t change dramatically, it’s probably because you are crossing the boundary for the unit of measure being presented.
Dictionary attacks and other attack methodologies:
The first thing the l33t hacker-types will say is "what if I start with Z and go backwards, tough guy?"  Then they do that.  Whatever.  If you are really worried about it then get your calculator out and figure out how long it would take going backwards.  Or just start everything with M.  Of course, they might then decide to start in the middle on the off chance that you did that, and so on and so forth.  When you see people making these kinds of arguments, it is a sign they've actually not used things like "rainbow tables" before - rather, they think reading a blog-post is enough. To that effect, I don't expect you to believe everything I say - I hope you will go forth and experiment. Anyway, I chose to use this base structure because that's how tables are built in the first place. These are arguments of diminishing returns. More than that, it’s an empty way for people to challenge whatever they see so they can substantiate their egos. I honestly think hacker-wannabe’s try to make things as complicated as they can in order to show off how “smart” they are. I’ve seen crazy, silly metrics and people who think they know everything about passwords - these things don’t work. This is simple. And easy. And it works. I’m good with that.
WTF is a BananaDog?
I think the same sort of logic applies to dictionary attacks - Will and I call this the "bananadog" syndrome.  (The reference to Will originates on the TGP docs here, since moved). That's where you can have a dictionary of 10,000 words, and use it to attack people who are so dense that they use "banana" or "dog." Let's say you double up on the words (100,000,000 (one hundred million)) so that if they were very clever and used bananadog the attacker would still get it in milliseconds.   Thing is, the bananadog key-space would only take about 94.11 minutes to crack.  In that time, the attacker would get any possible combination of 5,646,683,826,134 lower case, up to 9 character passwords.  Any of them.  The "bananadog" attack will always be limited to 100,000,000 total possible passwords, and will miss things like bannaadig .  Attackers want your password, so they'll make sure they get it.  As such, I'm not worried about bananadog.  And if you are the bananadog type, I doubt you would be reading this anyway. 

Will's point, and it is a good one, is that if I as an attacker can spend a couple of milliseconds getting x passwords up front from a dictionary attack, why not do so?  And I agree.  The logical extension of that is to build some sort of sanity check in the password strength checker to weed out BananaDogs.  And I may do this.  The difference is the level of assumption one must make - meaning, the actual application of dictionary attack logic is very subjective, where the brute force assumptions made around ordering attacks (in regard to a-z, A-Z, 0-9, etc) are fairly established by current implementations.  Do I concatenate words to score BananaDog?  Do I do it 3 times to score DogBananaDog?  What about BananaDog1?  or B4n4n4D0g?  I find the application of dictionary attack logic too "random."  It certainly can be done, but I don't know how applicable it would be to build into a tool.  As such, I'm putting that on the back burner.  If anyone has any suggestions around that, feel free to contact me at {thor at hammerofgod dot com}. 
So that's that.  The above checks are made when you generate your keys so that you have the little extra bit of security.
Stacks Image 95