Some models you can literally just pull a fuse for the telemetry modem and the car will be offline. Worth considering.
220 karma · joined September 8, 2008
Phactory was born from a desire to have something like Factory Girl for my day job writing PHP. A couple of my co-workers and I have been using it for a few weeks now, and we're finding it really useful.
If you have time to give it a try, any feedback/criticism would be much appreciated.
What features would you want to see in a library like this?
The rest of your library is the part you want to spend your effort on. Make it easy to use, make it flexible, put in some great features like a user admin panel. That stuff is the domain of the webapp library builder. Just trust the crypto part to the cryptographers, and use bcrypt/scrypt.
The best practice in password hashing schemes is well understood by the security community, so you have to understand that it can be frustrating to watch the same mistakes made over and over again.
As tptacek pointed out, the correct answer is "use bcrypt". He's not telling you not to offer your library for public use, he's just pointing out that there is absolutely no reason to roll your own password hashing scheme.
"Also, could I not continue using SHA2 256, and add an option to specify the number of hashing repetitions, which would increase the time to compute, as well as frustrate dictionary attacks?"
Are you sure there is no inherent property of SHA256 that would allow an attacker to shortcut the computation of successive hashes? I'm not saying there is, but simply that cryptographers have already solved this problem and considered all the angles. Why are you trying to start from scratch?
The slowness of an algorithm like bcrypt is a tunable property of the key expansion algorithm. A step in this process will be repeated 2^n times, where n can be configured by the user.
If a password function was only slow because it wasn't implemented in assembly on your server, an attacker would obviously just go implement it in assembly for his brute-force crack.
Node.js doesn't make it easy to share state between processes, but once you're scaling to multiple processes, the jump to multiple machines probably isn't far behind. You'll need to design a distributed algorithm, or just centralize your shared state in something like Redis anyway.
I stuck to straight JS since I'd like the source to be simple for most developers to understand.
An ideal visualisation would be to show the activity as blips on a Google Map.
Do you really think so? I'd prefer to live in a society where everyone was well-educated, or at least enjoyed learning.
I think you'd find there is some spillover benefit for yourself to be had from "these low-income and minority kids" receiving high-quality education.
Besides, when a customer requests pricing, many systems will send an e-mail to the salesperson who can hit "reply" to send an e-mail to the customer.
That's technically true, but the time frame it takes to find an algorithmic weakness or complete a brute-force is the important factor here. It comes down to a question of how long your data needs to remain confidential.
As is usually the case, no cryptographic primitives were subverted to 'break' the USB stick. A somewhat silly implementation flaw is to blame.
So like I said, it's nice to have that hash for every reference, but I wonder if it's worth the storage overhead, and if a developer will use it when he's building his own distributed system anyway.
As an aside, I generally do a quick walkaround on my car before driving away. Check for low tires, see if somebody banged their door into it, etc. For my motorcycle there are even more things I check each ride for safety reasons. It's inconvenient, but worth it I think.
It seems like the author is really stretching for things to complain about. If you neglect to inspect the vehicle for damage prior to driving it, what do you expect?
Basically a subtly buggy SWAP() implementation causes the RC4 cipher to output more and more plaintext as time goes on.
"Every ID of an Enchilada Value is calculated by taking the SHA1 hash of the Value's contents."
The docs suggest that this can be used in a consensus protocol. Many nodes can compute the same result, and quickly test for equality by comparing the ID. Seems nice to have this built-in to the language, but I have to wonder:
a) Why SHA1? Why not a member of the SHA2 family? b) If you're creating a distributed system and want to implement a consensus protocol, a hash ID isn't really sufficient. Who is going to end up using this feature?
It doesn't seem terribly egotistical to want to correct people who are spreading an inaccurate representation of his product.
If you are hiring for a position where the developer will work primarily with Ruby, it makes sense to ask Ruby-specific questions or have a Ruby coding exercise. That shouldn't be the whole interview of course; as you mention, an all-around strong candidate is preferable.
That said, the questions in the article don't require much Ruby experience. Anyone with a grasp of OOP concepts could probably get most of them right.