No Crappy Passwords Files

No Crappy Passwords v11.39 - 26 December 2022

No Crappy Passwords will take an input, presumably a crappy password, hash the
crap out of it, and return an eighty five character password. It takes little
imagination to come up with a system of easy to rememember passwords and offsets
that will produce these unbreakable final passwords.

Hashing text (or files) is like one-way encryption, you can always figure out
the hash of the text, but it's impossible for all intents and purposes to
determine the text that produced any given hash.

Wannabe hackers that brute force web sites, databases, and other password
protected items can send thousands of common passwords in attempts find crappy
ones, and if the server in question isn't salting, or is improperly salting
passwords, that can be a problem.

No Crappy Passwords eliminates this possibility by simply turning your crappy
password into a ridiculously long and random password through hashing.
Additionally, no two crappy passwords will be hashed in the same way, as the
script doesn't determine how many times to hash your crappy password, or how
many cycles will run between doing an encryption, until your crappy password is
analyzed.

In short, you don't have to remember these long passwords produced, only the
crappy password that produced it.

The hashing digest used is SHA256, and the encryption routine used every few
cycles is RC4. (this "encryption" is not meant to secure anything, only to
further randomize things)

For what it's worth, the reason I decided to do this was to produce passwords
for text encryption that were extremely robust but with no need to store on
disc. I have a system that I consider to be extremely secure while being very
easily memorized.

ncpw - Linux
ncpw.exe - Windows

Just a note .. If you do the math, you'll find that if each possible combination
in the eighty five character password were equal to one second, that number of
seconds would be several trillion times the age of the universe.

If you look at the source, it's obvious that I don't write software for a
living, but if you like these little scripts that I make, please consider
writing an email and telling me where you're from. Have fun,

Dana Booth
danabooth@mail.com


CHANGELOG

v11.39 - A bug was discovered where the Linux version was retaining linefeeds
within the result when using the Ascii85 option. Although the linefeeds are not
visible in the output, they take up a character space, so each linefeed in the
output was reducing the length of the output by one. This has been fixed.

v11.19 - Had to quickly fix a bug

v11.18 - It was brought to my attention that some sites and services will no
accept some of the special characters in previous versions. This version fixes
that using the "SiteSafe" format option

v11.0 - Added option to output result in Base64 or HexDecimal in addition to the
default Ascii85+. Also added a short help file from the pull-down

v10.0 - it came to my attention that some web sites will not accept passwords
beyond a certain length, or will truncate them. This version offers the option
of creating shorter passwords, I did this against my better judgement, as adding
more options like that kind of defeat the purpose of the script. To help in this
regard, ncpw will maintain a file in it's working directory, .pw_length, which
keeps track of the last used output length

v9.0 - uses ascii85 rather than base64 output for greater character variety,
meaning this version will produce different outcomes, keep that in mine, that
passwords you'd created with any previous version will be different with this
version given the same input

v6.x thru 8.x - these versions changed the output, but weren't worthy of
release

v5.0 - the script now throws in an encryption routine every thirty seven to
forty six cycles depending on conditions

v4.xx - unsuccessful

v3.11 - the script will hash the user provided crappy password between five and
ten thousand times, depending on information found in the first hash. The odds
of obtaining the original crappy password from the final result are 0.0%,
however, if it's known that this script produced the result, it would be
possible to see how the result was obtained. Although I don't see how this could
be reverse engineered, I've added an entry field which accepts a numeric input,
and will add or subract that from the number that the script obtained from the
first hash, i.e., if the script will hash 7000 times, an input of 75 in the
offset box will hash the crappy password 7075 times. You can also use negative
numbers, inputting a value of -75 would hash the crappy password 6925 times.

v3.0 - fixed an overlooked problem, the sha224/256 hex output was only producing
sixteen characters to be base64 encoded. I've put an RC4 encrypting routine
between the final hash and the encoding, which fixes this.

v2.01.1 - added more special characters to the output

v2.01 - gave it an interface and prepared it for public consumption

Pre 2.01 - Just messing around with a TCLSH terminal and thought, hey, something
like this might come in handy.