poutine

22 ms·

91.
The General Purpose Kiosk Computer(blog.telemetryapp.com)
9 points by poutine 11y ago|1 comments
92.
by poutine 12y ago
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 he
93.
by poutine 12y ago
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.
94.
by poutine 12y ago
Check out https://telemetryapp.com -- it handles your requirements I think.
95.
by poutine 13y ago
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
96.
by poutine 13y ago
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 push
97.
by poutine 13y ago
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
98.
by poutine 13y ago
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
99.
by poutine 13y ago
> 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
100.
by poutine 13y ago
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
101.
by poutine 13y ago
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)
102.
by poutine 13y ago
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 --
103.
by poutine 13y ago
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).
104.
by poutine 13y ago
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 numb
105.
by poutine 13y ago
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
106.
by poutine 13y ago
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
107.
by poutine 13y ago
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'
108.
by poutine 13y ago
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
109.
by poutine 13y ago
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
110.
by poutine 13y ago
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 h
111.
by poutine 13y ago
Someone can do the math but I expect a 64 character long random string is more than sufficient.
112.
by poutine 13y ago
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.
113.
by poutine 13y ago
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 you
114.
by poutine 13y ago
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. Yo
115.
by poutine 13y ago
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 exampl
116.
by poutine 13y ago
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
117.
by poutine 13y ago
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
118.
by poutine 13y ago
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.
119.
by poutine 13y ago
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 reques
120.
by poutine 13y ago
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.

More ›