> "This package will install io.js v1.0.0 and npm v2.1.18 into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node."
The windows install for this took the liberty of removing my original nodejs install, removed the binary and batch files from the program files\nodejs directory, even though I opted to install iojs to its own folder. Nodejs shortcuts are removed from start menu, and path variables were removed as well.
Go to reinstall nodejs, and that install says a later version is already installed and cancels the install without giving me an option to install anyway.
I've had a totally opposite experience. Stripe has been amazing for us. Clean API, good documentation, a slick dashboard, responsive support team, etc.
Processing credit card transactions is a hard enough problem that it rarely makes sense for any non-payments company to do it themselves. Dropbox and Airbnb use Braintree (a Stripe competitor) for payments, and they are both much bigger than Kickstarter. Even Twitter and Facebook have been known to use Stripe for various products, and they are obviously much bigger than Kickstarter as well.
In the future, I imagine almost every site will use HTTPS—maybe browsers will even refuse to connect over plain HTTP. Then this kind of attack won't be possible.
I'm sure that there will be free proxies that "require you to install this program" (which also installs a certificate) to work. But yeah, it helps for e.g. the middle schoolers who don't have admin rights on the computers anyway.
This is called "learning experience". How children are supposed to not think of computers as magic boxes if they're prohibited from doing anything interesting on it (and that very much includes breaking them and fixing by themselves)? Restoring the machines back to original state should be a trivial task for whoever is responsible for the computer room.
> How children are supposed to not think of
> computers as magic boxes if they're prohibited
> from doing anything interesting on it (and that
> very much includes breaking them and fixing by
> themselves)?
The first thing every kid did in the computer lab was highlight all the icons on the desktop and try to delete them. We already knew how to use computers because we had one at home to mess with. The whole goal of the computer lab was to figure out how to create a bomb for the next user.
Now pretend we aren't in the heights or mid/upper burbs anymore. There is no IT/networking staff. It's just Mr. Perkins, the English teacher that volunteered to look after the computer room. And there are kids without computers in their household. Too bad, all the computers are hosed because lol.
> SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate passwords. Specifically, it concatenates the master password and the domain name of the Web site (masterpassword:domain.com), hashes the result at least ten times (and until it satisfies the generated password requirements), and cuts the result to the desired length.
Yikes! MD5 is known to be broken, and 10 rounds of hashing is no defense against brute force attacks. Hashpass uses SHA-256 (not broken) and does 2^16 rounds of hashing.
No, SHA-256, the way you use it, is not "far too slow for brute-force".
To anyone reading here: Please do yourselves a favor and stay away from BOTH SuperGenPass and from this one.
They are nearly equivalent to using the same password for every website. A malicious website owner can derive your "master password" from the hash that you gave them and thereby gain access to all your websites.
It sounds like you're asserting that Bitcoin is not secure because it uses SHA-256. i.e. a pass phrase that has been hashed with SHA-256 could be brute forced to find the master passphrase, thus, a Bitcoin private key could be compromised by a brute force attack.
That's an extraordinary claim. (I'm not gonna argue too strenuously about MD5 being somewhat dangerous in this context, as it is very easy to find collisions...slightly harder to find the exact passphrase, particularly if it is a very long/strong passphrase. A collision in this context is not enough to break the usage.)
Don't put words in my mouth, I never suggested anything like that.
In Bitcoin the private key is derived from the public key which is normally randomly generated and not provided by the user.
The browser 'password manglers' mentioned here instead derive it directly from the password provided by the user. That is a big difference.
Most users don't choose a password of sufficient strength since they are limited to printable characters and especially when they are required to type it in all the time.
This is why key stretching functions such as PKDF2 and Scrypt were invented. To make relatively bad passwords (which users are prone to choose) harder to crack.
Screwing this particular step up in a tool that wants to be a password manager (of all things) strongly indicates that the creator has no remote clue what he is doing and that everyone should stay far away from his software.
So, pass phase length and strength is the concern here? If a human were to generate a reasonably strong pass phrase (say 25 characters), would that mitigate the problem? (Certainly this is stronger than a memorizeable unique password for every site, but I'm willing to believe I should do better.)
What does a good password manager look like if not this?
A good password manager generates a new, strong, random password for each site, stores them in a file and encrypts the file with a key that is derived from a user provided password via one of the aforementioned methods (PBKDF2 or scrypt).
This lets the user change his master password without invalidating all stored passwords and the compromise of any single or multiple site passwords does not affect the master password in any way.
And since the password-file is encrypted it can also be trivially backed up and synced across devices using any untrusted transport (e.g. Dropbox).
As it happens, this is exactly how the common solutions (KeePass, LastPass) operate. This part of the wheel is in no need to be re-invented poorly.
It's true that changing the master key is a pain, but you don't have to do it for every website at once. Though it might be hard during the transition to remember which sites have the updated key.
Not having a database certainly has its downsides.
Re usability: I've been using it for a couple days now, and I find it pretty tolerable. It's nice to not have to memorize a new password when I sign up for something. I did change my master key once; it took about 5 minutes to update all my passwords. If you only do that once every few months or once a year, it's not so bad.
A salt is random bits added to a password. Hashpass prefers to be stateless, so it just asks the user to pick a strong password (possibly by adding random bits like a salt). It puts more trust in the user, which obviously comes at a price.
Re key strengthening: Agreed, but only salt-less schemes will work in this stateless model. Unfortunately they are few.
> Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.
Addressed this in the article: "Some websites have certain requirements on passwords, e.g., at least one number and one capital letter. A simple way to meet such requirements is to append something like A9! to the generated password (and remember you did that)."
Yes, you should not use this unless you are willing to memorize a strong secret key. There are warnings in the article, but perhaps it could have used a few more.
This is one of those "only use it if you know what you're doing" things.
This is not a new technique. In addition to the Stanford paper, there are several other implementations mentioned in these comments. It's a compromise, not a mistake. It is better to memorize one strong password than a dozen weak ones.
This isn't custom crypto. It's a well-known hash function that serves as a filter, transforming the passwords you would otherwise enter directly into a website's login form. It is no less secure than typing in passwords by hand.
Stanford published a paper that is basically the exact same model
Um yea.. "basically".
Except they demand an 'ultra-slow' hash function in that paper. You ignored that requirement and that makes your implementation equivalent[1] to using the same password for all websites.
2^16 rounds of SHA-256 might not be "ultra slow" but it's certainly not as bad as you make it seem. If you read the analysis in the article, it would take many years to crack a random password with this hash function. It's unfair to say I "ignored" that requirement.
Correct, there is no salt. A dictionary attack will uncover common passwords. It's crucial to pick a strong secret key. That's the price you pay for using a stateless password manager.
However, the gigazillion rounds are not for nothing. That is the defense against brute force attacks, which could otherwise crack passwords even if they are random.
I have made a CLI stateless password manager for myself once (still use it, actually) and I generally "solved" the salt issue by providing the salt manually.
Examples:
syntax: gassy salt base [password length || 16]
gassy spoiler news.ycombinator
gassy email@personal.me home_email
gassy name@ work.com 32
in the next step you're prompted for a password (with echo off). Also, it calculates a token based on the salt which determines in which way the password will be generated.
I know it's not ideal, but it served me well so far! :-)
> "This package will install io.js v1.0.0 and npm v2.1.18 into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node."