Evernote hacked
blog.evernote.com
blog.evernote.com
Their lack of encryption and lack of 2 factor auth just became a much bigger issue for me...
I'm not sure if there are any bookmark services that actually support this, though it'd be a decent selling point.
It was a big deal, when Google finally assed themselves to implement it for Gmail, but companies have been embarrassingly slow in following their example. Especially when they provide e-mail services.
Twitter hired TFA specialists a few months back, but they are taking their sweet time about implementing the system. I've wondered for a long time why social networks aren't on top of implementing this.
It's the SSL discussion all over again.
Crappy consumer services not supporting 2fa is somewhat understandable. No one uses Apple or Yahoo web services for business. People do seem to use Evernote in business contexts. Google Apps for your Domain is a fairly legitimate business option, as is Google Docs.
The weakest link at every hosting provider seems to be the customer admin panel/provisioning interface. This is one thing AWS does relatively well vs. other providers (now); IAM is pretty featureful, but few people actually use it to even 5% of what it can do.
I just with their built-in text encryption was better.
They've got competent people operating the service; it's just not well designed for security.
Recently https://crypton.io/ was released and my hope is that lots of new SaaS offerings will use it and that this will in the end force even the big names (Dropbox, 37signals, etc) to adopt real security.
Won't happen until it's perceived that the lack of security is costing them money.
The FREE product is still in Beta but the Pro version (due out in two months) WILL allow you to request zero knowledge and there will be no Recovery key. I know that you know that this means that if you ever forget your password, there is no helping you but I say it so that others reading this understand the dangers of this.
Why are we going to supply this functionality then? Because users keep requesting it
Of course there's a tradeoff, but for me that's easily worth it.
[EDIT: clarity about client-side encryption]
The "tradeoff" seems to be "make the server into a
dumb store for encrypted data." At which point, you
don't have Evernote (an API for fuzzy-matching
clippings punted into it from various devices),
you have Evernote (a set of fat client programs)
plus a POSS (Plain Old Storage Service, like S3.)
In fact, the workflow sounds like it would have more
in common with editing a Word document over SMB than
with making web requests.
Otherwise, yeah most Web Apps are nothing more than editing stuff over the network and visualizing it differently.
The #1 competitor or a SaaS isn't some other SaaS but rather Word/Excel: http://www.startupcfo.ca/2011/05/the-1-competitor-for-saas-v...
Edit: Also there's no reason to believe the client-side store wouldn't be encrypted. That'd be exceedingly stupid.
Without that, what you have is a OneNote notebook stored in your Dropbox.
> Edit: Also there's no reason to believe the client-side store wouldn't be encrypted. That'd be exceedingly stupid.
It's encrypted with a key that's stored on the client, which is the same as the server being encrypted with a key stored on the server: effectively about as secure as DRM (i.e. not.)
To put it another way: presuming you have a motive to gain access to just my data--with this hypothetical service, if you steal my phone, you have my data, and the key to decrypt it. Or if you steal my laptop, or my desktop, or any other device the service is synced to. Or if you hack into them. All you need after that is the passphrase I (hopefully) set to unlock my encryption key--and for a single target, social engineering (or lead-pipe cryptanalysis) can get that right quick.
Meanwhile, there is only one thing people can do to steal my Evernote data: hack into Evernote's servers. If you just want my data, that's a whole lot more effort than it's worth, compared to just palming my phone.
[Now, if you want a bunch of random people's data, this is where using passphrase-locked + per-account-salted encryption-keys server-side is actually relevant to security. If it takes O(N) time to crack N accounts, there's much less incentive to do it than if it's O(1).]
If your imaginary attacker can social engineer your local encryption password out of you, he can just as well engineer your Evernote password out of you. There is no difference.
The real issue is that today someone who hacks the Evernote servers will gain access to all users notes. With end-to-end encryption they'd have to target each user individually.
Thinking off the top of my head:
priv_key = AES_DECRYPT(PBKDF2(pincode,salt),iv,RSA_key_from_keychain)
aes_key = rsa_decrypt(priv_key,encrypted_aes_key)
You could also have some files server-searchable (and accessible via a web UI -- there would be a way to download a client each time with the web ui, in js, to do client side crypto in the browser, but that has its own security vulnerabilities).
You might have 3 tiers -- client side encrypted and non-searchable, client crypto and client searchable including a javascript client, and server-searchable (and thus encrypted only using keys held by Evernote, just as a way to keep drives from getting cleartext on them).
The trick would be educating users and making a clear UI for this.
Zero Knowledge will be an option with the pro version due out in about 2 months but as I have commented before, if the password is forgotten, there is no accessing that data
Sorry, I'm sure the Evernote tech team is competent, but clearly some marketing spin has been put on this announcement.
What exactly leads you to this assumption?
They designed a service that stores sensitive user-data in an obviously insecure fashion (no end-to-end encryption).
If that's not incompetence then the only other explanation would be criminal negligence?
(FWIW I didn't get the email so I was simply locked out and used their "forget password" form instead of trying to log in, which may have a different reset process).
Important: Evernote just implemented a service-wide
password reset. Please read our post for details and
instructions
Can someone post a paste of the blog post in here?
-----
Evernote's Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.
As a precaution to protect your data, we have decided to implement a password reset. Please read below for details and instructions.
In our security investigation, we have found no evidence that any of the content you store in Evernote was accessed, changed or lost. We also have no evidence that any payment information for Evernote Premium or Evernote Business customers was accessed.
The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.)
While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com.
After signing in, you will be prompted to enter your new password. Once you have reset your password on evernote.com, you will need to enter this new password in other Evernote apps that you use. We are also releasing updates to several of our apps to make the password change process easier, so please check for updates over the next several hours.
As recent events with other large services have demonstrated, this type of activity is becoming more common. We take our responsibility to keep your data safe very seriously, and we're constantly enhancing the security of our service infrastructure to protect Evernote and your content.
There are also several important steps that you can take to ensure that your data on any site, including Evernote, is secure:
Avoid using simple passwords based on dictionary words Never use the same password on multiple sites or services Never click on 'reset password' requests in emails — instead go directly to the service Thank you for taking the time to read this. We apologize for the annoyance of having to change your password, but, ultimately, we believe this simple step will result in a more secure Evernote experience. If you have any questions, please do not hesitate to contact Evernote Support.
The Evernote team
Over the past few years I've told everyone to refrain from using Evernote. I told them that Evernote doesn't use end-to-end encryption and that eventually this would happen.
Hardly anyone would listen ("You're just paranoid", "I don't store anything private in there anyway, except.. oh").
For once I take cruel pleasure in being "that guy". The general public needs to learn this lesson.
http://news.ycombinator.com/item?id=5154502
While there are (so far) no such comments about Evernote releasing this stuff on a Saturday morning. I think security breaches are just discovered at inconvenient times.
"The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.)
While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com."
What it doesn't say is how the passwords were dumped in the first place, or what they're going to do to ensure it doesn't happen again (outside of taking "additional steps"). I understand that not all users of Evernote are technical, but I'd like some peace of mind that a similar thing is less likely to happen in the future.
Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.
As a precaution to protect your data, we have decided to implement a password reset. Please read below for details and instructions.
In our security investigation, we have found no evidence that any of the content you store in Evernote was accessed, changed or lost. We also have no evidence that any payment information for Evernote Premium or Evernote Business customers was accessed.
The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.(http://en.wikipedia.org/wiki/Salt_(cryptography) ))
While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com(https://www.evernote.com/Login.action).
After signing in, you will be prompted to enter your new password. Once you have reset your password on evernote.com, you will need to enter this new password in other Evernote apps that you use. We are also releasing updates to several of our apps to make the password change process easier, so please check for updates over the next several hours.
As recent events with other large services have demonstrated, this type of activity is becoming more common. We take our responsibility to keep your data safe very seriously, and we’re constantly enhancing the security of our service infrastructure to protect Evernote and your content.
There are also several important steps that you can take to ensure that your data on any site, including Evernote, is secure:
Avoid using simple passwords based on dictionary words Never use the same password on multiple sites or services Never click on ‘reset password’ requests in emails — instead go directly to the service Thank you for taking the time to read this. We apologize for the annoyance of having to change your password, but, ultimately, we believe this simple step will result in a more secure Evernote experience. If you have any questions, please do not hesitate to contact Evernote Support(http://evernote.com/support).
The Evernote team
Or the author is not qualified to do security, or thinks readers are ignorant.
I can't blame companies for not having one such on hand to begin with, but I'm sure they'd appreciate that someone with the unfortunate experience crafted a draft for them in stressful times like these.
The only way to "break" correctly working hashes is to encrypt tons of passwords (+salt) and see if the lossy output is identical to the output you got from the previously hashed password.
Which is a very time consuming and computably expensive process (in particular when using something newer/better than MD5/3DES).
http://www.freebsd.org/doc/handbook/crypt.html
See this: http://en.wikipedia.org/wiki/One-way_compression_function#Co...
The question is - can we predict these collisions or guestimate when they might occur without having to actually try every combination? If the answer is "yes" then the hashing algorithm is broken (see MD5).
and
> Never click on ‘reset password’ requests in emails
Is sure to confuse a lot of people.
Upon logging in with my (presumably) exposed password, I was given the option to enter a new password immediately. Their password reset should fire off an email instantly, not using a batch delivery process, with a confirmation link that then logs me into their system with a one-time key, forcing me to change my password only then.
Yes, that is marginally more complicated, but it's miles more secure. They just gave a free password reset form to whoever is sitting on their database dump for any trivial dictionary passwords they're able to bruteforce. Not doing a mass password reset would have had the same effect.
FWIW, I've also yet to receive any confirmation email that my password has been reset, another potential security problem.
That's great. But to really reassure people they would do best to reveal the algorithm. After all, DES-based password hashes are both 'hashed and salted' but are easily broken with JtR.
Situations like these specifically call for not leaving things up to the users' imagination.
The recent Facebook incident (well, one of them) created a big scare. Better to control the narrative, before others decide to tell their version of the story.
Their description would satisfied by a simple MD5 + salt, which wouldn't be very good for password storage.
What type of encryption does Evernote Use?
If you encrypt text within a note, we derive a 64-bit RC2 key from your passphrase and use this to encrypt the text. This is the longest symmetric key length permitted by US Export restrictions without going through a complex process to gain export approval.
We do not receive any copy of the key or your passphrase, or any escrow mechanism to recover your encrypted data. I.e., if you forget your passphrase, we can't recover your data.
User authentication (i.e. username + password) is always performed over SSL when you communicate with Evernote. This uses 1024-2048 bit RSA keys and a symmetric session key that's negotiated between your client/browser and our server.
The data in user notes is also transferred via SSL.
Several of the company's founders come from a strong encryption background (founders of CoreStreet, recently acquired by ActiveIdentity). For Evernote's consumer product, the current encryption algorithms are chosen more for exportability under the Commerce Department rather than strength, since our software permits the encryption of arbitrary user data with no escrow.
We'd be interested in offering something stronger in the future when we have the staffing to fight the lengthy export battle, but Premium users can currently use an external encryption solution to encrypt important files and then add these encrypted into Evernote.
So with some experience you can often tell (or guess and test) what something is hashed with.
That said, revealing the exact algorithm would basically be throwing people with weak passwords to the wolves while really only supplying the rest of us with a false sense of security (because it will probably be cracked anyway).
We'd also be better off if they didn't announce the algorithm if the passwords get leaked (like with LinkedIn).
$6$AhHvI8ay$I0ED2wWVU9eheJKvCxzcbc/ZYRoN60q5XNHruYp8yFlQvEOjJ1WtIHUwjG6L4ZGntf3ei8osB7s2GYdkN01gx1
dGhpcyBpcyBzdHVwaWQKCg==
286755fad04869ca523320acce0dc6a4
some_salt:ac01346ad1553221506dd091800a1974
c8fed00eb2e87f1cee8e90ebbe870c190ac3848c
6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e
/5L0cR/wpFqSA
Want to see how you did? Here's the answer key, in base64:
MTogTW9kZXJuIGNyeXB0LCBsaWtlIHRoZSBraW5kIHlvdSdkIGZpbmQgaW4gL2V0Yy9zaGFkb3cK
MjogSnVzdCBiYXNlNjRpbmcgdGhlIHJhdyBwYXNzd29yZCAoc3R1cGlkKQozOiBVbnNhbHRlZCBt
ZDVzdW0KNDogbWQ1c3VtLCB3aXRoIHNhbHQgcHJlcGVuZGVkCjU6IFVuc2FsdGVkIHNoYTFzdW0K
NjogVW5zYWx0ZWQgc2hhMjU2c3VtCjc6IE9sZCBVTklYIGNyeXB0KCk=Example: crypt stored the password in the format: $id$salt$encrypted
The security of your system can never depend on an attacker not knowing the implementation.
Or: Security through obscurity (is no security)
Using gimmicks like for example shuffling some characters in the hash may delay some attacks. But the problem is that these techniques are usually done on systems that have no sufficient security.
Have a big salt and use PBKDF2 or Bcrypt and you know the exact difficulty of getting the passwords.
Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.
Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.
Leaving identifiable bits in the hash makes it easier to do things like
if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$)
> At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.
If you ever know at all.
Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that requires far more work and far slower cracking.
Re hash: yeah, use a strong hash function. Never advocated otherwise.
Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.
Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that.
Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it
For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism
It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory")
So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think.
Example: taking the hash and encrypting it (for some choices of hash and encryption)
(Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)
What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.
What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.
So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.
And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.
That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.
So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.
Assume a central account/profile service. This service would allow you to have a single login to this service, with a directory of pretty much any/all sites and services online.
The external services would receive a hashed token of your account/authorization. They would check for the validity of the token each [interval|day|time-the-service-was-accessed] to determine if the token/auth is still valid.
They would also be able to tell the central service whether or not they require an updated token/auth, for circumstances just like this.
Further, form data could be stored on the central service, like mailing, shipping, billing, etc info. A log of all sites/accounts that request/require/use this information is kept.
Access to this and all other profile information can be reviewed/revoked by the user at any time.
Groups and layers of account information would be something that could alternately be added to the central service. I.E. - you could have a first level login to get to your dashboard, but additional security could be required to change various portions of your profile details (one passwd for address info, another for accounts)....
Avatar galleries would be available and you could tell each service which avatar to associate with what.
There are hashing algorithms (bcrypt, scrypt, PBKDF2) that are specifically designed to be slow to prevent these attacks.
That said, you are right. You should always change passwords that are leaked. This, however, is due to the poor security practices of most companies, not some bizarre distrust of hashes.
There have been such huge improvements in hashing through tools like hashcat and hardware implementations that i don't think it's unreasonable to distrust hashes. Once a hash is leaked you're essentially hoping that brute forcing it is too high of a cost. Given the history of order of agnitude improvements in hashing speed, i consider it unreasonable to believe that any password database remains safe indefinitely once leaked.
I find your trust in the difficulty of brute forcing a hash just as bizarre as you seem to find my distrust of hashes.
"Since the hashed password is never exposed outside of our data center, we don’t think that the differences between MD5 and SHA-1 are relevant. I.e. the risks for MD5 are about producing two inputs that match the same output. In the case of a purely back-end MD5 hash, any hypothetical attacker doesn’t have access to either the output (the MD5 hash) or the original input (the user’s password and our salt), so there really isn’t any productive attack based on MD5 vulnerabilities.
Of course, if someone has your original password and our salt, they might be able to come up with a SECOND synthetic password that hashes to the same value. (Since we constrain password characters that we accept, that might not be possible, but let’s assume it is…) The attacker could theoretically use this second password to access your account. But that same attacker could just use your original password, so I don’t see a real-world attack that would be improved with SHA1.
(Before Evernote, I spent five years building high-end cryptographic systems for government customers [e.g. http://www.isto.org/ose-site/file-fix/Public/corestreet-secu..., so I get to make use of my old crypto knowledge from time to time…)"
http://blog.evernote.com/tech/2011/05/17/architectural-diges...
Anyway Evernotes android client wasn't very good and it was far too slow to start.
And now the have been hacked. Anybody know a good alternative?
I only found out about the hack because my evernote client kept on bugging me saying my password had changed.
Curious as to why I found out the cause via Twitter.
Email is way too slow for these sorts of things
> "Avoid using simple passwords based on dictionary words"
And yet your password algorithm rejects highly secure pass phrases:
> "New passwords can contain letters, numbers and punctuation."
Disallowing spaces is particularly annoying for a company with a strong security requirement, as passphrases are simultaneously far more secure and far more memorable than the monkey rules your validation demand.
It gets worse.
If I type a long sentence without spaces such as "thisphraseisdefinitelynotinthedictionary", you give me an orange warning checkmark and suggest:
> "Try using a combination of letters and numbers"
If I replace that long phrase with "abcde1", just 5 lowercase letters and a digit, you give me a green checkmark! Same green checkmark for "abc123", the third most popular password online.
Have whoever wrote your validator needs to go read http://xkcd.com/936/ and really internalize the idea.
EDIT: See also:
1. How people choose passwords: http://www.troyhunt.com/2011/07/science-of-password-selectio...
2. Top 25 passwords: http://www.prweb.com/releases/2012/10/prweb10046001.htm
3. Twitter banned passwords: http://securitywatch.pcmag.com/none/284196-the-twitter-banne...
The example passphrase does have the equivalent of 44 bits of entropy:
log_2 (2048^4) = 4 * 11 = 44
However, if we take a random password formed by just seven of the 95 printable ASCII characters, we already have a password four times stronger than such a passphrase:
log_2 (95^7) ≈ 45.99
XKCD is great and all, but I wish Randall had been more clear that this comparison does not touch on the strength of a random password, because I have since seen an infuriating number of people point to it to claim that passphrases are more secure than random passwords. They are not.
Any password cracker smart enough to exploit the patterns in "900gage!@#" is also smart enough to exploit the construction of an English language passphrase. The passphrase is still secure enough (probably), but it is not more secure than the random password. And if there is any one thing to take away from that thread, it should be that it's foolish to assume the obscurity of your passphrase's formulation gives you any extra security whatsoever.
And this must be true in order for passphrases to be a reasonable choice. Because if people start using passphrases commonly, then this formulation will immediately be added to password cracking toolchains along with all the other common types of password.
On the other hand, the passphrases's actual "entropy" is probably lower than the advertised 44 bits, because patterns like the appearance of an adjective ("correct") before a noun ("horse") are common enough in the English language that they, too, could be factored into a smart password cracking tool.
I noted to internalize the idea, the entropy idea versus human "random" passwords which aren't random at all. "Normals" are using their name with a 3 instead of an E, or some word with a 1 on the end. This tends to put them in rainbow tables or easy attacks. See my link #1 in GP comment for reference.
That's why I said "pass-phrases are stronger than monkey rules".
Meanwhile, "random" passwords don't necessarily come up stronger. Forget just seven. Let's use 1Password's random sixteen (16) char generator as an example[1]:
2Fro%7gMfQbwBktm : 85.3 bits of entropy from 72 char set
[xNyCHZc44RzPeMJ : 85.1 bits of entropy from 82 char set
thisphraseisdefinitelynotinthedictionary : 153.7 bits of entropy from 26 char set
correct horse battery staple : 104.2 bits from 27 char set
log_2 (2048^8) = 8 * 11 = 88 bits of entropy
1. Quick entropy check: http://rumkin.com/tools/password/passchk.php
2. Manual entropy check: http://www.wolframalpha.com/input/?i=log_2%282048%5E4%29
I think you missed my first paragraph, where I made that point:
"Normals" are using their name with a 3 instead of an E, or some word with a 1 on the end. This tends to put them in rainbow tables _or_easy_attacks_.
Also, my example passphrase that I was annoyed Evernote wouldn't let me us isn't log2(2048^4), but ~ log2(5000^8) even assuming you know it is words.
This thread is getting of on the tangent of debating XKCD's particular formula. XKCD is not the point.
My original post asked Evernote Team to please grok the idea of that cartoon, which it's obvious they had not given their clearly wrong tips and rejection of a very strong password and acceptance of one of the weakest.
This password strength test is attempting to estimate the entropy of given passwords under the assumption that it is a word roughly obeying the character distributions of English text, using Shannon's approximation. It does not apply to randomly generated passwords, which violate these assumptions, as described in Appendex A of the NIST plublication linked on that very site.[1] As that document describes, the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password. (If the password had any less entropy than that, then by definition it would not have been pseudorandomly generated!)
Additionally, the algorithm employed by this site does not take into account that an intelligent password cracker is capable of exploiting the construction of passphrases.
In other words, you've taken an algorithm designed to approximate the entropy of a user-selected password and misapplied it to both randomly-generated passwords and user-selected passphrases. The fact that the algorithm is able to give you a number for these inputs does not mean it is any valid indication of how difficult such a password or passphrase would be to crack.
[1] http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1...
EDIT: But you're right that passphrases can be easier to use by people. I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.
Our job is to recommend things that can help real people use tech more safely.
> "the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password"
Yes, I'm aware of that. Using that site's check, "correct horse battery staple" comes out weaker at 104.2 bits, so I listed that weaker "lower bound"[1] for that phrase. I'm happy to use whatever formula comes up with less entropy for reasons discussed in [1].
I also don't care when sharing with less technical users if it's exact. I care if I can point them to a URL that gives a reasonable approximation, which that "quick check" does. For users who want to do math, I listed both approaches:
> 1. Quick entropy check: http://rumkin.com/tools/password/passchk.php
> 2. Manual entropy check: http://www.wolframalpha.com/input/?i=log_2%282048%5E4%29
The "manual" check is pre-filled with your suggested formula. It's interesting to compare the entropy check to http://www.passwordmeter.com which I think users will "solve" as if it were a password meter puzzle, in very predictable ways.
Meanwhile, to an attacker trying the whole character space, "correct horse battery staple" is log2(27^28) or 133.1 bits of entropy. And if you use H = log_2 (b^L) on the passphrase that Evernote wouldn't accept, it comes in at 188 bits of entropy.
In any case, the approximation is a more conservative "lower bound" than the formula you're suggesting as applied to character set ^ length.
> I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.
I agree. And I use 1Password and generate random passwords.
Btw, the two truly random passwords from 1Password (equivalent of keepass, lastpass, etc), if working with the H = log_2 (b^L) formula, give only 98 bits and 101 bits. Again in their case, the "quick entropy check" URL gives lower numbers, meaning it's a remains a reasonable "lower bound" check for casual users who don't grok formulas.
I tell non-technical family members and friends who can't be bothered with password minders to use sentences meaningful to them and unlikely to be in a book.
This phrase is definitely not in the dictionary! : 227 bits or 286 bits
--
1. lower bounds: http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...
Also wouldn't a hash of a long passphrase be longer? (I am completely ignorant the details of hashing algorithms)... so if I'm cracking a table of hashed passwords, I could set a "passphrase" cracker on hashed passwords of above average length?
The problem with this is hash collisions, weaknesses found in hash algorithms can make it so attackers could generate files to match another files hash (or password or w/e). I think the idea is that they create a harmful file, then add null characters or w/e so the hash algorithm will generate/assign the two different files the same hash.
Different problem domains have different additional requirements: password hashes want to minimise collisions (multiple inputs hashing to the same output), checksums want to make similar inputs produce wildly different outputs, hashtable/dictionary/map key hashes want to create an even distribution of outputs etc. But the thing common to all hashing algorithms is the output is the same size.
https://github.com/lowe/zxcvbn
zxcvbn, named after a crappy password, is a JavaScript password strength estimation library. Use it to implement a custom strength bar on a signup form near you!
zxcvbn attempts to give sound password advice through pattern matching and conservative entropy calculations. It finds 10k common passwords, common American names and surnames, common English words, and common patterns like dates, repeats (aaa), sequences (abcd), and QWERTY patterns.
Sample results (including Tr0ub4dour&3 and correcthorsebatterystaple) and a demo can be found here:
I wonder if this is a good way to create passphrases. Anybody want to chime in?
I've recently converted all my accounts to that - my passwords are practically unbreakable, at least with the current tech. I feel way more secure than with the shit I had to memorize before.
https://github.com/rpearl/python-zxcvbn/
I am a bit slow at pulling patches (sorry, I just get super busy) but I do get to it eventually.
xyzzy scores 'instant'.
My B of A pass phrase, Jer1m1ah Cl4rke, scores 31 years. Should I change it?
https://dl.dropbox.com/u/209/zxcvbn/test/index.html
Edit: I just checked 9223372036854775808L, and it answered 'centuries' with a suspiciously round crack time in seconds. Don't think so.
https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...
zxcvbn currently only supports English words, with a frequency list skewed toward American usage and spelling. Names and surnames, coming from the US census, are also skewed. Of the many keyboard layouts in the world, zxcvbn recognizes but a few. Better country-specific datasets, with an option to choose which to download, would be a big improvement.
It appears you have assumed all passphrases must take the same methodological route as outlined in the xkcd comic.
However, 'noozle stroodle' has an entropy of 69.303 [1]
The above quotation, is a passphrase, and it's more secure than any 7char printable ASCII password.
While I accept your argument that not all pass phrases are necessarily more secure than seven lettered passwords, one cannot rightly make the antithetical claim either.
The correct judgement is: It depends
[1] According to the JS tester, http://dl.dropbox.com/u/209/zxcvbn/test/index.html
[0]: http://en.wikipedia.org/wiki/Password_strength#NIST_Special_... [1]: http://reusablesec.blogspot.com/2010/10/new-paper-on-passwor...
If you are talking about short passwords, entropy is critical in determining the strength of the password, but the true measure of a password's strength is the permutations required to perform a brute force attack. While range of character sets determine permutations, so does the password length. You can make up for one with the other, which is why "vvvvvv.vvvvvvvvvv7vvvvvv" is a very secure password.
That aside, I did address more of the math of the XKCD comic here: http://xato.net/passwords/analyzing-the-xkcd-comic/
I just don't understand the logic behind some of these password rules. Wouldn't it require more effort to explicitly disallow certain characters? Like, they wrote code somewhere that is specifically making sure your password doesn't have a spaces, and other arbitrarily chosen characters.
It doesn't make sense to restrict anything in passwords other than length (and of course testing that is meets certain complexity/length requirements-- smartly). Just set your DB field to be 30 characters, accept any character, and be done with it.
There must be some logical explanation behind why companies implement these rules. And banks are the worst. Because people far more experienced than me at programming (e.g. Evernote devs) make these decisions, so there must be some reason. Is the decision a defense against SQL injection techniques? Since injections usually contain spaces. But then again, this is 2013 so you think they would use prepared statements, or something.
Madness!
Look fellas, we've got an optimist over here!
Subsequently, NEMB got subsumed by successively larger banks, until, finally, Bsnk of America took over. Suddenly, my ATM card wouldn't work! It turned out that they had kept my full PIN on file through the whole chain of acquisitions, but only with B of A did they start comparing ATM PIN entry against the full PIN! My card still worked with the full PIN (which I still remembered, it being an old phone number).
When you first create your password they translate the characters to the numerals on the phone and then hash it.
In my experience that is the most common reason why you'll see password for policies like: "Your password must be between 6 and 20 characters and only contain upper and lower case letters."
> everyone has always believed or been told that passwords
> derived their strength from having “high entropy”. [...]
> But [...] when the only available attack is guessing,
> that long-standing common wisdom is not correct!
I dunno, isn't logging into a site that has just been hacked exactly the thing I don't want to do?
For that matter, linking to a hacking announcement on a hacked site seems like a bad idea, too.
As long as we're stuck with passwords, this is the single best practice for protecting your accounts. Services WILL be compromised, again and again, and attackers have made a pattern of compromising a poorly-secured service as a side channel to get credentials for a more critical service.
Props to Evernote - it seems like they've done the right thing with password salting and hashing and hopefully this breach won't result in actual plaintext password reveals. But every week on HN we read about another shitty web app that is storing passwords in plaintext or with weak / unsalted hashes - when those services are breached, at least you'll know that the attackers don't have a credential they can use elsewhere.
This would be easier if non-critical password cookies didn't expire. Why does my Slashdot or HN password cookie need to expire? Answer: it doesn't, but the fact that it does means that I have to write down dozens of different passwords... and carry them with me if I expect to use those services on a mobile basis.
Life would be a lot easier if password cookies didn't expire (or even if - gasp! - the user was given a choice in the matter). Whenever I'd find myself locked out due to the use of a different browser or platform, I'd request an email reset and keep track of the resulting new password only long enough to update all of my browsers.
If I try to use this strategy now -- and I have -- I'll spend an hour every other day doing nothing but resetting password cookies that didn't need to expire in the first place.
Christ, passwords are stupid. Somebody fix this shit.
/rant
I'm comfortable with that level of forced inconvenience.
Were the attackers ables to access the salt ?
pbkdf2_sha256$10000$rdfyoPhMNhnC$3QEJ9hp0Qe68/p8+b1tVsYmNqVHiFrhmpWizXq+xQoo=
algo $ iterations $ salt $ hash
But to answer your question: I'm not sure, but probably.
A hidden salt that is used across all passwords is useless on a public service, because that becomes the password to hack.
The attacker takes an account that has a known password and brute forces the salt from that.
Salt and hash are good for protecting well chosen passwords, but because the speed they can be processed mean the hacker can try billions of different passwords a second. These days choosing a cryptographically hard (memory hard) is the best bet to extend the time from a breach to password discovery so the majority of the users can change their password.
e.g.:http://links.evernote.mkt5371.com/ctt?other_params_removed
I just went straight to the site instead of following the email links in order to confirm the legitimacy of this mail.
This depends on how hard they looked - do people believe content wasn't accessed?
Is it fair to ask them for a technical post about why they don't think content was hacked? I'd love to know how they separate auth from content, and how they ensure that a hacked auth node can't view notes
Why couldn't an attacker do that at this point?
Does anyone know a decent password keeper? I have a list of logins/passwords for my key sites in a word .doc file stored locally, but given I have a work mac, home mac, tablet and iPhone it really is a pain to access the locally stored file.
I thought about saving this file on google drive, but their 2-factor auth doesn't seem to apply for drive (only gmail).
How do others do this - is there a way to store an encrypted file somewhere online, then typing in a known password to unencrypt / open it when I need to access it?
www.lastpass.com
Huh? All of Google's logins are through their single-sign-on. TFA protects everything.
Also, please, just use LastPass. I don't know why everyone has it in their head that password managers are a hassle. It's literally easier than using the same password for everything AND more secure.
i guess they're counting on compromised passwords not being used individually to create new ones?
so i guess since passwords were encrypted they weren't fully compromised and a simple change should be enough.. at least that's what Evernote appears to think.
I'd even be happy with an encrypted disk image on Dropbox if there's a good way to OCR scanned docs, then be able to search them.
Since you ask and since you appear to be a Dropbox user looking for more security, check out www.ncryptedcloud.com It is a Privacy, Security and Collaboration app that layers on top of dropbox (Skydrive and Googledrive soon)
1) I'm sick of going through this password reset crap every month or so. Please lets get rid of passwords.
2) Could Evernote please look at some sort of oauth based signin for mobile devices? I have to enter this unique and very long password multiple times on every device I own.
It'd be nice if my linked phone and tablet didn't need me to use the same login system as a human.
"Dear Valued Customer,
We're truly sorry for the inconvenience this has caused you this morning. We are attempting to contact our entire userbase about this matter, but we feel that immediate action in these cases is the most prudent course."
The rest of the email contained the contents of their blog post.
I wrote up a post with some of my security concerns. http://news.ycombinator.com/item?id=5311010
Surely, you must know more than the username. But they cannot rely on the old password either, because the whole thing was set off by assuming that the old password is hacked. And they advise their user to ignore instructions per email.
So how do / could they do it?
Twitter, tumblr, Pinterest hacks are all having zendesk connection
People on Dropbox have issues too
Please, be very careful, people. Of course, this won't reach the people who need to hear it :(
Instead, you have to tap the "authentication failed" notification. Then you can change the password.
I wouldn't lose anything, it would be just inconvenient for me.