Kinesis | Full Stack Web Developer | Sydney, Australia | Full-time, Onsite | https://kinesis.org
We build tools that enable sustainable and liveable cities, from planning and development through to operational tracking and optimisation of existing infrastructure.
We’re looking for a mid-senior generalist web developers who can move between back and front of the stack, ideally with experience in either (or even better, both) Django and Rails.
Current stack/technologies: Ruby/Rails, Python/Django, JavaScript/Ember.js, PostgreSQL + PostGIS, AWS.
If you’re interested email me at chris at kinesis dot org for more info.
Wasn't a huge pain in my opinion. I always use http://railsdiff.org to start, but yeah I did run into a couple of unmaintained gems that weren't compatible and I had to patch myself.
Kinesis | Full Stack Web Developer | Sydney, Australia | Full-time, Onsite | https://kinesis.org
We build tools that enable sustainable and liveable cities, from planning and development through to operational tracking and optimisation of existing infrastructure.
We’re looking for a senior generalist web developer who can move between back and front of the stack, ideally with experience in either (or even better, both) Django and Rails.
Current stack/Technologies: Ruby/Rails, Python/Django, JavaScript/Ember.js, PostgreSQL, AWS
If you’re interested email me at chris at kinesis dot org for more info.
Kinesis | Full Stack Web Developer | Sydney, Australia | Full-time, Onsite | https://kinesis.org
We build tools that enable sustainable and liveable cities, from planning and development through to operational tracking and optimisation of existing infrastructure.
We’re looking for a senior generalist web developer who can move between back and front of the stack, ideally with experience in either (or even better, both) Django and Rails.
Current stack/Technologies: Ruby/Rails, Python/Django, JavaScript/Ember.js, PostgreSQL, AWS
If you’re interested email me at chris at kinesis dot org for more info.
This worked! Just a couple of problems. Hashrocket needs dev version of Ruby and pg wouldn't build, but StackOverflow told me I needed to install libpq-dev. Then I had to install postgres, but wasn't hard.
I've been using Authy[1] without any problems on iOS7. Great thing is that it can also be used for other services that use OTP (AWS, Cloudflare, Facebook etc).
Count me as another vote for Authy. One more amazing feature: Your tokens stick to your Authy account instead of your physical device. If you need to restore your phone or delete the app, you don't need to disable two-factor on all your accounts and then set it up again.
Just reinstall Authy, reauthorize with your Authy account, and you're done! Helped me countless times, from when I had to rebuild my iOS install because of a backup problem to when I got a replacement device due to a hardware issue.
Doesn't giving the device keys to a third party, while also authenticating using a password with that third party, sort of defeat the whole purpose of two-factor authentication?
Unfortunately, their marketing is highly convincing. Most people (even most engineers) won't realize the tradeoff here: Authy replaces "two factor authorization" with "two password authorization". It should be clear which is more secure.
The "two factors" with GA are a knowledge factor (something you know - your password) and a possession factor (something you have - your phone number for SMS or phone for GA app).
Ultimately all of the cellphone 2FA are at some level "two passwords". If the machine on which you enroll initially is pwned at that time, the attacker sees the seed. It's a little better with physical tokens (where you'd need to compromise the token itself, or do MITM at setup time and persistently after). I believe most of the good iOS TOTP apps use the "keybag" correctly so the seeds don't leave the device when backed up, but it's not perfect. An x509 cert would fundamentally not be any different, and PK-based MFA (which Duo, OneID, and I think some other companies do) isn't that different -- it just requires the verifying application talk to the app directly vs. something you can do as a human.
For gmail, Google texts me an auth code; the seed (if there is one) is in their data center. They could switch to seedless down the road since they own both sides of the auth.
I've never trusted the SMS auth; too easy to play phone routing tricks, and most high security environments don't allow phones or have coverage (of course there's also the same problem for no-phones for a phone-based TOTP; the solution is a physical token).
Although using Authy's backup service is optional and the app works just fine with local-only storage and no Authy account, which is how I have it set up.
