About Me!

This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.

Résumé [PDF]

Other Pages

Quotes

Links

Oak Island

Items for Sale

Presence Elsewhere

jim@jimkeener.com

del.icio.us

Twitter

Facebook

LinkedIn

GitHub

BitBucket

Read-only on /dev/tty causes ssh-add to show passwords when typed and ssh'ing to new hosts to fail

Date: 2014-07-17

Tags: openssh linux

I have an OpenVZ box that’s always been nothing but trouble to me. I’m not sure why I keep it around, but I do. One day, ssh-add started echoing my password to the terminal. I was sad. I then tried to ssh and just kept getting “Host key verification failed.” What’s up with that?

Eventually through the use of ssh -v -v -v I figured out that /dev/tty wasn’t usable. (WHAT?) I ls -l /dev/tty and found it had permissions of crw------- owned by root:root. I did chmod a+rw and everything started to work.

I’m still trying to ascertain why that happened, but I wonder if openssh could provide an error if it can’t confirm a host key via input and so that ssh-add doesn’t echo passwords; sudo doesn’t, so I’m curious if the other methods possible on linux could be used on other systems or not. Anyway, off to #openssh to see if they have any input.

I just wanted to put this up so that if anyone else has this issue they can be guided to a (temporary?) solution. I’ll attempt to keep this post up-to-date as I learn anything.

Traffic Light Yellow Times Not Long Enough

Date: 2014-07-13

Tags: pittsburgh traffic-lights transportation walkability

I went back to school for Transportation Engineering because I feel that by making places more accessible, I can help improve people’s lives. One such way I feel that I can help, is by advocating for safe conditions for pedestrians. In one of my first attempts to use what I’ve learned, I’ve written a letter to my city council representetive:



On my walks to work, I’ve noticed that a bunch of intersections on Centre Ave and Baum Blvd do not have clear-times (the sum of the Yellow and All-Red phases at a traffic signal) that are sufficent to allow pedestrians to cross safely. Numerous times I’ve been caught in the middle of one of these roads, and I’m a quick walk — doubly so when comparied to an elderly or disabled person.

The Manual of Uniform Traffic Control Devices &sec; 4E.06.07 provides guidance to use 3.5 feet per second as the walking speed of a pedestrian.

The MUTCD &sec; 4D.04.04.A.3 states that “Pedestrians facing a CIRCULAR GREEN signal indication, unless otherwise directed by a pedestrian signal indication or other traffic control device, are permitted to proceed across the roadway within any marked or unmarked associated crosswalk.”

The MUTCD &sec; 4D.04.03.B.3 states that “Pedestrians facing a steady CIRCULAR YELLOW or YELLOW ARROW signal indication, unless otherwise directed by a pedestrian signal indication or other traffic control device shall not start to cross the roadway.”

My measurements are as follows

Intersection Clearance Time Crosswalk length Suggested Safe Crossing Time
Centre @ Liberty 6 s 55ft 16s
Liberty @ Center 6 s 57ft 17s
Centre @ Graham 6 s 30ft 9s
Graham @ Centre 6 s 30ft 9s
Baum @ Graham 6 s 60ft 18s
Graham @ Baum 6 s 80ft 22s
Baum @ Aiken 6 s 55ft 16s
Aiken @ Baum 6 s 60ft 18s
Baum @ Liberty 6 s 70ft 20s
Liberty @ Baum 6 s 86ft 25s

None of these intersections are anywhere near the amount of time required to cross them by a healthy adult, let alone an elderly or disabled person. Especially given that efforts are being done on Baum Blvd to install microwave sensors to aid traffic flow, steps should be taken to ensure that pedestrians are given the proper amount of time when crossing.

Installing Pedestrian Signals (PedHeads), would provide feedback to pedestrians as to the amount of time remaining for them to begin safely crossing. This option has no affect on traffic or intersection geometry and doesn’t require retiring the signaling system. I would strongly urge you to have Public Works audit this corridor in order to determine the exact need and configuration of pedestrian signals.

This corridor is also home to a hospital and two hotels which attract many non-locals, who are not familiar with the configuration of these intersection. Even as a local, I find myself many times a week caught in the middle of the road needing to sprint to exit the roadway after opposing traffic is given a green light.

Additionally, Liberty at Baum has a leg of the intersection closed to pedestrian crossings. I believe that this is a terrible thing to do, not the least of which is because pedestrians have a habit of crossing at intersections regardless of being told not to. Additionally, to legally cross this intersection now requires waiting through 2 additional phases of the traffic signal — adding a noticeable amount of time to someone just wanting to stroll to a diner or restaurant a little further down the block. Moreover, it is extremely rude and unfriendly to pedestrians, who may be visitors to our city, to tell them that an intersection that is visibly clear and poses no immediate threat, is closed — it reflects very poorly on city trying to build a pedestrian and bike friendly image. I would also urge you to have Public Works consider removing this closure, especially if PedHeads are to be installed as it will provide reliable feedback to pedestrians on how long they have left to cross this intersection.

Thank you for your time regarding this issue. I believe that little things such as providing pedestrians reliable information on how long they have to cross an intersection go a very long way in increasing the safety, usability, and pleasantness of walking around.

Sincerely,

Jim Keener

APNS Woes

Date: 2014-06-29

Tags: programming software apns apple ios

I’ve recently been working on interfacing with APNS and have found it to be a terribly desinged API. It doesn’t feel like what I expect from an Apple product.

APNS a completely binary protocol, meaning that you can’t use any of the nice, well tested, battle hardened HTTP libraries out there (like you can with GCM). Being a binary protocol in-and-of-itself isn’t that bad of a thing, but it does feel awkward for the decision to be made to transport JSON via a binary protocol in 2009.

The worst part is that it’s not synchronous. You’re expected to throw packets at the service until the service kills the connection, possibly sending you an error packet before it does so. For the feedback services, you’re expected to just listen if there’s anything and disconnect. I don’t believe it would have been that difficult to, and would have the usage process much, much nicer, if the protocol would respond consitently. For instance, if I say I’m going to send 10 packets, it could wait until it’s recieved those 10 packets to send an “All Good!” or “Error: xxxx” packet. Or when connecting to get feedback, tell me that there is no feedback.

The whole system seems to be designed to be as “efficient” in terms of bandwidth as possible, but then duplications tons of fields, e.g. when setting the Device Token in a Notification packet, you need to add a Device token section that has a header and the token length, both of which are rednundant because the token is always required and always the same length. Also, being bandwidth eficent to save possibly 100s of bytes, at the expense of a crappy development experince seems very un-Apple. As much as I dislike IDEs, XCode is much much nicer of an experince to work with then Visual Studio was and the Apple Docs often feel much better than MS’s docs.

The efficiency may be warranted on the phone’s end, but a simple HTTP endpoint for sending notifications and getting feedback would have made the development process at my organization much more streamlined and quick.

APNS just feels like a quick project done by someone using vastly underpowered hardware and kind-of became a bigger thing, but that was never cleaned up. Part of me feels that it’s designed so that people refrain from using it; it feels that awkward, especially when you’re not use to dealing with raw sockets day-to-day.

Galactic GPS and Calendar

Date: 2014-02-25

Tags: space gps calendar time

I’m a layman when it comes to astronomy, and would greatly appreciate feedback from anyone “in the know”. These are just some things going through my head earlier.

I grabbed a pulsar database earlier today because I was bored.

If a ship could see a handful of the pulsars, with a minimum of 3, the

angle between the ship and each pulsar should be fairly unique for any

given place in space (within sensor limits).

Looking at some of the periods (/psrcat -db_file psrcat.db -c "P0" | tail -n +4 | head -n -1 | awk '{print int($2 * 1000)}' | sort -n |uniq) and was thinking that the least-common-multiple of many pulsars could be a handful of millennia at the least. This may prove to be useful as a long-term (by human standards) calendar.

Why you shouldn't trust people with your data, and how to prevent it

Date: 2014-02-15

Tags: srp crypto security authentication payment bitcoin chipnpin otp

Database breaches are becoming a common occurrence anymore.

Sometimes, in the case of health care data, there is little alternative to but to have your doctor have access to your records. However, many times, including passwords and payment information, there are better ways; we just need to use them. The first part of this post is aimed at users and the second at developers.

Users

Authentication

Since, for the time being, sending your password to the server seems to be the only option in many cases is to use a password manager to create unique passwords for each site. The password manager uses your master password to encrypt all the other passwords and username combos you create. Applications like KeePass have Windows, iOS, Android, Mac, and other OSs support and can synchronize your (encrypted) password database you can use Google Drive, Dropbox, or move the file around by hand. (N.B. your password database is only as good as the master password protecting it. See the bottom of this section for suggestions on strong passwords).

Another option is to turn on Two-Factor-Authentication. What that means is that you need two things, one you know (password) and one you have (your phone), to log into a service. The second factor (the one you have) could be a One-Time-Password app (Google Authenticator is available on iOS and Android) or an SMS message, depending on how the service handles it.

However, both of these require you have your phone or password database with you. If that’s not an option for you, then the traditional rules for good passwords are a good recourse:



Credit: “XKCD”:http://xkcd.com/936/

  • NEVER, EVER, EVER give your password to anyone. This includes writing it down and putting it somewhere other than a safe (i.e. DO NOT put it on a post-it note on your monitor or under your keyboard).
  • A password should be hard to guess, but easy to remember. Hard to guess means it shouldn’t be your name, username, email address, spouses name, any single dictionary word (or leetspeak translation of).
  • Different passwords for each site is recommended (because if one site leaks your password, all the other sites are vulnerable too)

With longer passwords, like Correct Horse Battery Staple you may run into sites that don’t allow very long passwords. My suggestion then is to do your best and send the site a nasty email.

Here is some advice from CERN and CMU. While I disagree with CMUs advice to shorten the password by taking the first letter of a sentence, the rest of the site is useful, and that advice is very useful for sites that don’t allow long passwords.

Based upon your trust of the service providing authentication and the permissions required by the service you’re logging into, OpenID or OAuth (e.g. “Log in with Google”, “Log in with Twitter”, or “Log in with Yahoo” provided by sites). For instance, I just used github to sign into a forum because the forum only required read-only access to my email address on github, something I felt comfortable providing.

If a site offers Persona a protocol designed by Mozilla (the creators of Firefox and Thunderbird), that is also a good option because it doesn’t require trust of the site you’re using to not abuse the service.

Credit Cards

There have been a couple large credit card breaches lately, namely from Target breach last December. One way to protect yourself against these types of security failures, is, when shopping online, to create virtual credit card numbers (VCCN). A VCCN is a credit card number associated with your account but:

  • Only exists as a number (you don’t get a card, hence being virtual)
  • Can be canceled/deleted easily
  • Have limits set (e.g. only valid until sometime or only $X can be charged to it)
  • No relationship to your real credit card number

These properties make them very useful for one-time payments (set the VCCN to expire in a week) or when a retailer saves your credit card number (Amazon, Target, &c) (valid for a few years or until deleted and not associated with your real credit card number). Citi supports this (log into your credit card account and search for “Virtual” on the page. It’s in the left-hand column towards the bottom). I can’t find it for Chase, American Express, or PayPal. Bank of America has ShopSafe which is a VCCN.

There are other companies that do this in a pre-paid manner (e.g. EntroPay) but I haven’t used their services and cannot vouch for them.

A technology common in Europe is Chip-and-Pin which requires a PIN, creating a 2-factor system for payment cards. This is more useful for preventing in-person attacks against a card (i.e. cloning where a person makes a copy of the data on the magnetic strip and puts it on another card).

Developers

Passwords

If possible, use systems that don’t require passwords at all (SRP, TLS-SRP, or Client Certs. This prevents you from even having to worry about storing passwords correctly because you never have the passwords to begin with.

If you can’t change how authentication is being don, please us a key derivation function like PBKDF2, bcrypt, or best yet Scrypt with large memory and time complexity parameters. Also, NEVER EVER EVER store a plain-text or encrypted (which means decryptable) password.

If possible, using services such as openid and oauth (google, yahoo, twitter, github, &c) also means you don’t have to deal with passwords.

Mozilla Persona is also a great option, as your users don’t have to trust you not to abuse the access you’re giving them (because they’re not really giving you access.

Credit Cards

Never store credit cards numbers. If you must identify if you’ve seen a card before, store hashes.

Most, payment providers provide a service that store client credit card information and provide you an opaque id. Auth.net’s Customer information Manager and Cybersource’s Payment Tokenization Service are two examples; just ask your gateway or processor about it! If you’re not storing information, you don’t have to worry about securing it!