poutine

The author of this article Fuchsia Dunlop, has written a couple of fantastic cooking books that bring mainland chinese cuisine to a western audience. If you're at all interested in preparing some fantastic authentic Chinese food I heartily recommend picking up "Every Grain of Rice", available on Amazon.

Started with Rails & Node, moved much of Node to Go, introduced Angular and deprecating Rails where we can and moving the remaining Node to Go.

Check out https://telemetryapp.com -- it handles your requirements I think.

We've been testing the Chromecast, its hard because it's a fairly limited device. However we do have things working on an iPod Touch which works quite nicely taped to the back of the TV. We're going to continue to work on optimizing the Chromecast and will do a posting if/when we get acceptable performance.

Founder here, they're quite different in a number of ways:

- Telemetry is obviously a SAAS, not something you host yourself.

- Telemetry is real time and incorporates a push system that exposes an API where updates are immediately pushed to the dashboards.

- Telemetry has native apps on OSX, IOS and Windows

- Telemetry is drag and drop for arranging your visualization

- Telemetry supports the separation of the data and presentation layer as this blog post discusses.

- Telemetry has a much wider array of visualizations.

- Telemetry has 'viewers' allowing you to remotely control who can see what

- Telemetry's dashboards scale to any size dynamically

- Telemetry supports embedding individual widgets in a web page

- Telemetry has a number of integrations with third parties.

MongoDB isn't the right tool here of course, but the rumoured attack could have been avoided using MongoDB's findAndModify command which gives you the atomicity you need to update a ledger.

The problem here is that developers not taking the time to understand their application and how their tools work. Yes, MongoDB gives you enough rope to hang yourself and I certainly wouldn't suggest using it for a financial ledger, but you could have a durable application based on it if you really wanted to.

However if developers of a financial system cant grasp the need for atomicity in the transaction path then they're going to be buggering things up all over the place.

The difference with China is that much of the entire country is covered by a blanket of smog & dust. Not just the cities, but much of the countryside as well for hundreds of km. China does things big in a way that's hard to grasp without visiting.

http://www.dailymail.co.uk/sciencetech/article-2478300/Pictu...

> EDIT: just want to add, I do think UX should be a primary concern of security; I just disagree with your analysis of his post.

Fair enough. I think the interesting thing to debate is his conclusion: that two factor auth using SMS is so flawed as to be avoided completely. That's complete nonsense.

Even if you accept that giving web apps 10x more CPU than today they'd be equal to today's native apps (I don't accept this), you must acknowledge you've given 10x more CPU to the native apps too. And clever people will find impressive ways to use that CPU in native's advantage (witness all the neat physics stuff in IOS7).

Agreed. If you look at the evidence we're doing quite well:

http://browser.primatelabs.com/ios-benchmarks

(The iPhone 5 is 2.5x faster than the 4S and 12x faster than the iPhone 1)

Call forwarding doesn't forward SMS. I don't think you can do SMS forwarding (at least for any carrier I'm aware of). You'd need to social engineer the carrier to port your target's number to a different phone -- in which case the target is going to be exposed to a ton of trouble...

If both are not required it's not a second factor. Two factor is something you know (password) plus something you have (a phone number).

Oh really? You think that login+password is a trade of equal risk with login+password+sms? Sorry, but the second is clearly has much less risk.

Twitter introduced SMS authentication as a second factor. Do you really think that their number of fraudulent logins for users protected by that second factor hasn't gone down to near zero?

This is utter stupidity. Somehow voicemail PIN weaknesses translate to being able to intercept SMS's?

Security is about systems, not individual components. Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account. The number of attackers that will be able to attack your login page and intercept SMS's for a specific user within the phone network is limited to three letter agencies.

The best security is security that people will actually use. Virtually everyone has a mobile phone and thus why the SMS channel is attractive.

Sure, this isn't the be all and end all in security and an app like Google Authenticator is more secure but SMS as a second factor is ideal for most consumer applications.

I've got a Panasonic Micro 4/3 camera for this very reason. As an amateur wanting better quality photos than an iPhone I find it has much of the quality of a DSLR in a fraction of the size and cost and gives you that arty blurry background depth of field effect.

Camera: http://www.amazon.com/Panasonic-DMC-GX1-Compact-System-Camer...

Lens: http://www.amazon.com/Panasonic-14mm-2-5-Aspherical-Intercha...

We've moved from the old world of the LAMP stack to one of many different solutions optimized at solving different problems. It is more about the problem, your style and your teams programming background.

As a long time Ruby developer who's always in search of faster, better, cheaper I've found the following:

- Rails is still the safe, moderately fast to develop in do-anything framework. It excels at CRUD and will have a maintained library available for pretty much anything you need to do. It however is relatively slow and Ruby comparatively sucks at anything async.

- Node and its supporting frameworks are fantastic at async and smaller single page type web apps. But it's a bit trickier than Rails or similar to structure and manage larger code bases. NPM is awesome for web development, better than Gems. Packages in general are not as mature as Ruby Gems and will be some time until they are. ORMs are quite weak compared to what you have in Rails (see Mongoose vs Mongoid).

My current stack of choice is Rails+Bootstrap for CRUD, Node+Restify for APIs (or Express if you need to throw in a little HTML as well), MongoDB for the DB, Redis for caching/pubsub/jobs. I'd use Postgres instead of MongoDB if I had an application where data integrity is paramount above all. All the supporting processes like job workers I write in Ruby (Sidekiq is great).

I'd like to use Go and I'm keeping an eye out for an application for it -- something that needs really high performance.

Indeed, this is where common usage hasn't really caught up with best practice. It really is no better than showing the user their cleartext password.

Ideally you'd regenerate the key each time the user wants to show it or just use OAuth 2.0 (it's not as bad as everyone says it is).

If you lose your DB you're in trouble regardless. We're talking about the level of trouble here. I'd rather be faced with a 30 day key rollover of all my users than a forced immediate change.

I dont see any reason to continue the argument. It's clear to me that you should hash your API keys in your DB.

Sorry I was a little inexact, when I said SHA-2 256 I meant specifically the SHA-2 256 bit (SHA-256) hashing algorithm as opposed to SHA-1 which is considered weak. Not the key length. Though I suspect a 64 character long random string has sufficient entropy.

Someone can do the math but I expect a 64 character long random string is more than sufficient.

If you use a broken library then you're in trouble no matter what MAC wizardry you layer on top of it. You've got a core issue that is a better place to spend time solving that coming up with some sort of MAC layer to add on top.

I'm mentioning tuning your SSL ciphers a number of times in this thread. It really is quite important. For Nginx you should compile it with the latest OpenSSL (1.0.1e right now -- you can statically link it if you dont want to mess up your OS's packages) to get the latest ciphers.

Use a config line like the following in nginx:

ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;

RC4 is a problem right now but unfortunately there's not a good solution until we get more TLS 1.2 support out there.

If you don't do this sort of tuning you're exposed to some weak ciphers that can result in attacks.

You're only using SSL which protects you vs relay attacks (it's doing its own MAC). Authentication is being done through the HTTP request Authorization header and the attached pre shared key.

Use SSL only, tune ciphers and you're good. You're wasting time trying to overthink the problem by adding another layer on top.

In common usage the user will take an server generated API key and embed it within their application that makes API requests. Take a very typical example of a merchant selling snowboards and using Stripe to process the payments as an example.

Since this API key is embedded within their app it'll require a programmer to change (and customers often may be non technical with sites built on contract). These are things you dont want to force customers to change with any frequency as it can cause pain and expense. You dont want to ever be forced to flush all your API keys, it could be a serious disaster.

Now there's protocols that rollover access keys hourly or the like such as OAuth a but that's a complex and often unnecessary use case that's beyond most API implementors. See how Google does OAuth 2.0 with their APIs for an example.

Since it's secure, simple and performant to hash API keys stored in your DB and just compared hashed values for authentication why would you ever not want to do it?

Incorrect. The PCI-DSS is an industry standard that everyone who touches credit cards must adhere to, which I suspect is a good portion of the audience here.

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

See section 8.5.9 for the password change policy. Section 3.6.4 for the key rollover policy (which references NIST 800-57 that basically says 1-3 years for most keys.

There's other standards (such as the 1-5 years for an SSL certificate from the issuer) and tons of best practices out there. In short you should be rolling over keys and expiring passwords on some sort of schedule. My point was that because humans use passwords they are conventionally seen as needing quicker expiration than keys.

I don't think you understand the distinction here, this is a random key, not a user generated password. The purpose of using something like bcrypt is to protect against brute forcing hashed passwords.

You cannot brute force search against a large random number that is hashed with unsalted SHA or the like. This would require you to guess the number, hash it and check to see if the hashes match. A large random number encoded as a 64 character string is simply too big to guess, even at millions of guesses per second.

Thus using bcrypt to protect your api keys does nothing but impose a serious bottleneck in how many api requests per second you may authenticate.

If you store keys plaintext in the DB then if someone gets your DB then they're able to perform API requests on behalf on any of your users.

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users.

While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

You should almost never know a users plaintext password. Outside of a small set of scenarios you're likely doing something very wrong if you need a users plaintext passwords. Passwords should almost always be bcrypt'd.

You've described OAuth in part with its refresh and access tokens.