Showing posts with label passwords. Show all posts
Showing posts with label passwords. Show all posts

Nov 3, 2010

Making Secure Recoverable Passwords ( part 3 )

If you haven't read Part 1 please do so.

Although the criticism of Part 2 should be taken with a grain of XKCD Salt, and even the primary plaintiff admitted that it would take him 2 months to crack the final salted sha512. Usually your attacker shouldn't have your shadow file, and having stored them as anything less is just plain not secure. I will acknowledge it has some merit.

Doing a base64 transformation on hex only digits is a bad, idea, and does not have nearly enough possible combinations. Nothing is going to be more secure than random, but random isn't really recoverable, if you lose it. That's why I do some kind of transformation.

I believe that somewhere someone suggested that it would be better to convert from the binary digest into base64 as it would be more random than from hex. I believe this is accurate, but the method suggested was in Perl, which is kind of messy, and more importantly hard to remember. So I asked, on unix.stackexchange.com, how I could do this on the command line. Here's the answer I decided to accept:

echo -n `date` | openssl dgst -binary -sha512 | base64

Remember you should slightly modify the result in a way that you can remember in your head to make it random, and probably use something in place of the "date" command, since it's not reproduce-able.

Again: this is not meant to be as secure as random passwords, just secure enough compared to non random alternatives.

Jul 23, 2010

Making secure recoverable Passwords (Part 2)

This has been prompted by Dave Jacoby's post on generating passwords and the fact that I've learned a new trick since my my first article in 2008; which you should read first (it's a prereq).

Some might point out that using a hex digest limits the characters that will be generated too much, do this then.

echo -n "date" | sum | base64

So let's say you have to change your password every month. Pick a day, let's say the second Tuesday of the month. Since your memory sucks write this down "Pipes on second Tuesday @ 5:08!". Sounds like an event reminder right? Here's your actual password algorithm for this month. First you want to has the 'second Tuesday of the month'.

echo -n "2010/07/12" | sha1sum | base64

which outputs

NTFhMTY4NmJkNWQyZmIzNWJlZTlmYmQxYzEwN2FjNGE1MjUyYjI1OCAgLQo=

So what was the rest of that reminder for? Now you're going to make it as good as random, take the first 8 characters 'NTFhMTY4' and insert a pipe '|' at the 5th character, resulting in 'NTFh|MTY4'. Now you have a 'good as random, but recoverable' 9 character password.

Given if you work with really clever people they might be able to figure it out if they know you use this kind of process. But I'm sure having read this article and my previous one you'll come up with something even better, but just as reproducible.

UPDATE:

I do not believe that anyone can seriously prove (after having read both articles) that you could crack this with anything less than a brute force attack. Because I've suggested inserting 1 or more characters into the final outcome, chances are those are anything in the 94 printable characters of ASCII. Yes you might limit the end possibilities but after seeing passwords that most people have... this makes you a hard enough target that no one is going to bother. Basically all assumptions that using this is bad revolves around someone knowing exactly what you do (so in reality it's probably only bad for me).

I should also note that my personal system encrypts passwords with a salted sha512 and I'm having trouble find a password cracking tool that can even try to brute force that.

UPDATE:

oh and just in case you forgot... no one is trying to brute force your password. Remeber this XKCD

Aug 22, 2009

More Security = Better. Wrong!

So I just had a discussion on #ubuntu-server on freenode about why my not having a password to connect to postgresql via a socket (read local cli) is insecure. So I asked them, how exactly is it that someone is going to get this access? The answer "there are bad people on the Internet". I'm sure many people right now are agreeing with them and thinking I'm crazy. Let's discuss my setup though shall we.

Postgres: I'm using Ident, and not just sameuser ident. no I had to set a custom rule in the pg_ident.conf file for this user to access because the systemuser != the db user. so just typing psql at the command line should you get access still won't get you into the db. you have to know which user/database to connect to. But that's not that hard right? in fact it's trivial.In addition you have to be a certain systemuser, only one works.

User Access: There is only one user account on the system that can be logged into (it's not root or a generic name). Only 2 people have the credentials to get shell access. One is my host, who happens to have physical and kvm access. The other is me who has ssh access.

SSH: I have ssh on a high port with no password authentication, or root, allowed.

So in order to passwordlessly access the database you would have to ssh into the system from a remote location or find an exploitable bug in apache (the only other service listening, or the kernel) that allows you to switch to my non apache user (meaning root access).

In addition, this system user had rw access to the entire website which includes a file containing the password to the database in plain text. So let's say I created a .pgpass file or variables? what exactly is it that would keep anyone who has access to this account from gaining access to the database? in fact wouldn't it just make it easier, since pgpass has a known location and contains all connection info including the username/dbname string?

But why do I need passwordless access anyways? I wrote a script that dumps the db every hour to a git repo and then pushes that to a remote.

Could I secure it further? yeah I could. I could make the script run as a user who can't log in at all and then put a pgpass in that users account. I'd have to properly ACL the webroot to give the correct write and read access. But is all this really necessary? maybe and I might do it, but at this point it's not nearly as important as it was for me to get backups up and running, because regardless of all the security I implement, if I have no backup and someone finds that loophole in one of the pieces of software and uses it, I might just be screwed. At least now I can restore the site if it gets attacked.

P.S. I was having a problem with my backup not being run by cron, never did figure out why.

Apr 27, 2008

Making secure recoverable passwords

For the basic you need a calculator with a decimal to hex function. Your OS should have one built in (scientific mode), many calculator's do to. For advanced you'll need special hashing software, suggestions for it can be found below.















Windows HashCalc
Macintosh MacHash
Linux/(*nix) Gnu Coreutils


Now that we have the software we need. You'll need an 8 digit (minimum) number that you won't forget. Guess what numbers fit the bill perfectly. Dates. All date's can be expressed in 8 digits, but they require a year. The date we'll use (for example) is Linux's Birthday. August 25, 1991 (I recommend something more personal like your anniversary or birthday).

So we are going to write down the date we picked for the password (note we aren't done yet).

something like

Linux BDay

Date's can be formatted in several ways, Just make sure to remember the numeric format you use. For our example we'll use the ISO 8601 standard. Which leaves our example date in format, YYYYMMDD, looking like 19910825.

So let's make a note of the format (to throw people off use a diff format say DDMMYYYY).

Linux Bday ISO

whatever you do make sure YOU understand your note, but that it isn't easily understandable by OTHERS.

alright... now we're going to take our number and make it hex. So open your calculator enter 19910825, then use the convert to hex function and you should have this 12FD0A9 (if you aren't using our example you may have a different 'number', or it may not be displayed exactly like this, display's vary between calculators). This is your first basic password. you can use it as is, or you can make it a bit more secure by using one of the hexadecimal notations. example: 0x12FD0A9. You can add a word or funny characters to either side of it to make it stronger too, just make sure to note anything you add to it.

Due to a Rainbow Table database you should make sure your password is at least 8 characters but I would recommend no less than 9.

But your hex number is less than 9 and what do the programs you listed have to do with this?

good point... let's make something a bit more crypto and less predictable.

Take the same date and plug it in to your hash creator, I'm going to use an md5sum for my first example.

if you put 19910825 into md5sum you get 6f9822851dfc6c1045c6fef827e5d729 (for you nix people enter the number like this 'echo -n "19910825" | md5sum'
on the cli otherwise you might end up with newline issues because different operating systems use different newlines).

so lets say you need an 12 character password you could just use the first 12 characters of your hash, example: 6f9822851dfc if you need an 8, example: 6f982285 ,etc etc.

if a stupid 'cracker' or black hat hacker get his hands on your actual password he might think he hasn't decrypted it fully because it'll look like a hash or memory error. want to throw people off even more just remember you aren't using the first 8 but the first 8 after the first 2 example 9822851d.

Or use a different has like sha1 or sha512.

Ultimately you could make your note to yourself like this

Sha1LinuxBDayISO to a non IT person this will look like a random password as is.

Also the cryptographic hashes take words too. So you could do your name. Caleb into an md5sum is

9ced73b8525de1db8e232ad575baa9dd

but it's different if I use caleb.

2f0154d7db348840676529dd72f1c034

if you always enter them the same you will always get the same result back. I guarantee after a couple days typing your new password you won't need to have it written down. If you work at a place that requires things like monthly changes.. just put the date you changed it on in to create the hash. Just make sure no one knows but the number/word(s) you used and the hash you used or they will be able to duplicate your password. Of course you're smart and you added somthing to it right? like a symbol (!@#$%^*{}|:"<>?[]\;',./) will all work find if the auth methods allow it.

have fun never having a hard time creating passwords again.