Lost password #FAIL

The file with my old saved password (a strong one: see: a prior post on the topic) for an e-commerce site was inadvertently deleted. No particular reason to chase the backup file out, as there was a lost password mailer. And so, I had occasion to use the 'lost password link' of that site today

Date: Wed, 6 Oct 2010 12:13:36 -0400 (EDT)
From: webteam (at) bhphotovideo.com
To: herrold (at) ... 
Subject: Your Password from bhphotovideo.com
----------------------------------------

Dear Russell Herrold

Thank you for your inquiry. Here's your password:

t3f38RbMMweRhg

We look forward to your next visit to our site. Please feel free 
to let us know if there's any other way we may assist you.

Thank you,
The B&H Web Team
www.bhphotovideo.com
NNN Ninth Avenue
New York, NY 10001, USA
800-606-asdf
212-444-qwer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is an automated email response and cannot be replied to.

A couple threshold matters: I changed the password value they sent me to something similar. More importantly, it seems that the sending email account webteam (at) bhphotovideo.com is unmonitored, although one has to assume an e-commerce vendor DOES have a 'webteam'. How curious

Having a unmonitored email sending role account is fine, of course; driving responses into a webbish workflow is fine as well; but why not use something obvious not a monitored account like: noreply@ ... or unmonitored@ ... instead?

Back to the topic at hand. That is: The 'lost password' mailer sent me a unhashed, plaintext prior password, and when using so, did NOT require an immediate change of credential when I used it to log in

There was a 'feedback form' on their site, and so I sent along this:

email is inherently insecure as it cannot be protected from being read by people 'along the way' on the transfer (such as the ISP of the server that received the email)

Sending a 'reset your password' one time link, and noting a credential change in a permanent part of an account history, is pretty basic

Not having this in you user account management interface, and sending a prior password in plaintext are a big red warning sign. I am left to wonder: Would they also disregard credit card data security [CISP/now PCI] credit card 'hashing' and no saved plaintext' credentials restrictions ;(

There is an old saying: A chain is only as strong as its weakest link ... I think we found a weak one here

What not to wear

Me, quoting me from a private IRC conversation

14:29 =orc_orc> disabling selinux is like
   having perms of 777
   or no root password at all
   or no wrappers
   or no iptables
14:29 =orc_orc> only weak minds should still be doing these things

Actually, one should set the root password to a unique and hard one for each box, and only use it for recovery [our practice per the 'blue ring notebook' of procedure at one site I ran. The 'per machine' passwords were 'remembered' and kept in a bound book journal in the CIO's office safe; usage logged, resets after use noted in said journal, audits performed]. Non-local root password based login should not be enabled. Rather, one should rely on pass-phrase protected, keyed SSH access the rest of the time

TTYtter move to OAth

One of the command line tools of interest for light weight micro-notifications is TTYtter. In the CentOS-devel mailing list a few months, I described using it to issue completion, and build closure notices doing a long running, unattended distribution build for a IBM s390x architecture

Twitter has announced, and been testing a move to using OAuth -- Rather repeat details here as to why this is compelling solution to federated authentication, and how it is still secure, please to take a look at: http://oauth.net/, and the Twitter writeup on that topic

Cutting over to the latest TTYtter (which has the needed code to use OAuth) is as easy as doing a download, setting a file permission executable, and updating a test symlink. Some minor edits to the 'rc' file were needed -- the lynx seems to lack needed crypto hooks, and so we edit to cut over to using curl. The tool then leads one through generating, and injecting locally the needed OAuth keying

[herrold@centos-5 ttytter]$ ./ttytter
-- using SSL for default URLs.
trying to find cURL ... /usr/bin/curl
-- checking version at http://www.floodgap.com/software/ttytter/01current.txt
-- your version of TTYtter is up to date (1.1.3)
** warning: -user is ignored when -authtype=oauth (default)

++-------------------------------------------------------------------++
|| WELCOME TO TTYtter: let's get you set up with an OAuth keyfile! ||
++-------------------------------------------------------------------++
Twitter now requires all applications authenticating to it use OAuth, a
more complex authentication system that uses tokens and keys instead of
screen names and passwords. To use TTYtter with this Twitter account,
you will need your own app key and access token. This requires a browser.

The app key/secret and user access token/secret go into a keyfile and
act as your credentials; instead of using -user, you use -keyf. THIS
KEYFILE NEVER EXPIRES. YOU ONLY NEED TO DO THIS ONCE FOR EACH ACCOUNT.

If you DON'T want to use OAuth with TTYtter, PRESS CTRL-C now. Restart
TTYtter with -authtype=basic to use a username and password. THIS IS
WHAT YOU WANT FOR STATUSNET, BUT WON'T WORK WITH TWITTER AFTER AUGUST 2010.
If you need help with this, talk to @ttytter or E-mail ckaiser@floodgap.com.

Otherwise, press RETURN/ENTER now to start the process.

Start your browser.
1. Log in to https://twitter.com/ with your desired account.
2. Go to this URL (all one line). You must be logged into Twitter FIRST!

http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=credentialelided12345

3. Twitter will confirm. Click Authorize, and accept the terms of service.
4. Copy the entire string you get back.

ck=BbEgsckKyR1234567890fw&
cs=QhuEHoZoh1234567890rg5oZjCmaddogk
kjhFnaYE&at1234567890n3lqqFjredbullX
pyTM3iQH6I1234567890k8Wilz&
ats=BVrFP1234567890ggODKHmTChME1234567890PCo9Y

-- Paste it into this terminal, then hit ENTER and CTRL-D to write it ---------
ck=BbEgsckKyR1234567890fw&
cs=QhuEHoZoh1234567890rg5oZjCmaddogk
kjhFnaYE&at1234567890n3lqqFjredbullX
pyTM3iQH6I1234567890k8Wilz&
ats=BVrFP1234567890ggODKHmTChME1234567890PCo9Y

-- EOF ------------------------------------------------------------------------
Written new key file /home/herrold/.ttytterkey
Now, restart TTYtter to use this keyfile -- it will use this one by default.
(For multiple key files with multiple accounts, write them to separate
filenames, and tell TTYtter where the key is using -keyf=... .)

Easy enough. The edits to the 'RC' file, post changes are shown thus:

[herrold@centos-5 ~]$ cat ~/.ttytterrc
#
# user=herrold:oldpass3.2.7172.14159word
keyf=/home/herrold/.ttytterkey
hold=1
ssl=1
# lynx=1
curl=1
# url=https://twitter.com/statuses/public_timeline.json
vcheck=1
#
[herrold@centos-5 ttytter]$

and let's fire it up again and test for function:

[herrold@centos-5 ttytter]$ ./ttytter
-- using SSL for default URLs.
trying to find cURL ... /usr/bin/curl
-- checking version at http://www.floodgap.com/software/ttytter/01current.txt
-- your version of TTYtter is up to date (1.1.3)
(checking credentials) test-login SUCCEEDED!
-- processing credentials: logged in as herrold
######################################################
...

After showing recent and direct posts, ends up at a prompt ready for content

...
-- notification: API rate limit is currently 350 req/hr
-- your version of TTYtter is up to date (1.1.3)
-- you are logged in as herrold

TTYtter> hello world and @ttytter using OAuth credentials
TTYtter> c9> hello world and @ttytter using OAuth credentials

Let's look a bit at the files with an eye to privacy. Oops

[herrold@centos-5 ~]$ cd ~ ; ls -al .ttytt*
-rw-rw-r-- 1 herrold herrold 174 Aug 18 09:43 .ttytterkey
-rwx------ 1 herrold herrold 161 Aug 18 09:48 .ttytterrc
[herrold@centos-5 ~]$

I fix that thus, of course:

[herrold@centos-5 ~]$ chmod 600 .ttytterkey
[herrold@centos-5 ~]$

I'll send a bug report to the author, suggesting use of a umask 077 before creating that keying file. A quick restart of the client indicates it is fine with that set of permissions

All done

line noise and random numbers

"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin"
  -- John von Neumann

Stipulated, but I am beset by closer devils, and I've tinkered with a mild solution I like. Let me tell you more

I've been badgered as some web sites have moved to Java-script evaluation routines for site passwords. Some require mixed case; others punctuation; no doubled letters; minimum length. Contrariwise some limit the character set to prohibit what others require

As such, for the last year or so I have been playing with a quick script on my CentOS 5 box, to generate a unique password per website, and keep a master index of the userid, email address used, and password used. This of course limits my ability to connect to those sites when away from that list. Open-ID roll-in seems to be coming however, and I have a rather clever device, backed by Verisign, and using an inexpensive OTP -- one time password -- hardware device as part of the authentication process

The little generator I wrote is based on simple shell tools -- md5sum, df, date, ps, cut, tr and so forth. It gathers a bit of entropy from a few sources froma few systems around the office, which should be non-correlated from a theoretical basis in the time frames at issue. It does some hashing to get good dispersion. Then it expands into 3 or 4 character vectors each 16 characters wide, using the hexidecimal digits that md5sum emits, as translated by tr; the first three are letters, upper, lower, and digits; the fourth character set are selected specials and punctuation excluding some shell meta's. Depending on a limitation by an option to -a, that vector may be limited to the alpha-numerics only, or also stir in the specials

That 'deck of characters' is handed off to a 'repeated cut of the deck' shuffler, and returned mixed once more just for good measure

I then add a 'bumper' of a letter or digit at each end [one site prohibited starting with a special], and a second character of 'bang' to prevent a mouse slip from dropping a password into the bash history in the case of a panel slip

The results are assembled, trimmed to an optionally specified length, and displayed, where I harvest them as mentioned above

Really, passwords need to die, die, die, but that is for another post

[herrold@centos-5 bin]$ for i in `seq 1 10 `; do ./gen-pw.sh ; done
e!~YJAJ{e:sU[4
2!R5K*U#)LoH~2
c!T)T7A10RjS}7
1!cGJ5T@]YjW>4
5!Q+#)K8:@rT]2
8!^)S~FF:5lV<4
b!dJ:TcKK{tQ)9
2!1dEa:fe~mR{4
3!cD1:eH^6wO*d
d!U*5(UEFWsI:e
[herrold@centos-5 bin]$ for i in `seq 1 10 `; do ./gen-pw.sh -a ; done
5ec280RSY5wIfd
0ddQ31EdJGmIdb
7eb52645U1tH06
0bfb401eG1jUa5
c2cT85QY22pS2d
ba8EALA9RRtR1f
35f59JRD6KpN04
7ed956UbA9pV59
402H3YLLR8hR3e
f2a0Aa9J0JrPde
[herrold@centos-5 bin]$

Completely un-memorizable of course, so really only suitable to a protected physical environment where one may write them down

Random number sin, of course, but the cyber-ninja can more readily put my thumb between pliers jaws, than predict the pseudo random source values I used, I'll readily spill the secret to access my LOL CATS site account. ... I still have to get around to building a few non-correlated hardware random number generators -- diode based, lava lamp based, dice tumbling machine for serious entertaining, I guess

"We're going to need another Timmy!"

Mr. Lizard, Dinosaurs

A running gag on that show, and in IRC, the same.

04:37 msivak> umga9pej
04:37 msivak> hups
04:37 msivak> time to change another password ;)