When cracking passwords attackers don't just use brute force. The most effective attacks are ones that exploit human patterns such as leet replacements, capital first letter, punctuation at the end, etc. Concatenated words in all lowercase with no spaces is another pattern that can easily be added to their list and probably already is there, so yes, you can assume that that they will be looking at the space of 2048^4 such passwords.
> The most effective attacks are ones that exploit human patterns such as leet replacements...
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.
I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted, but this only makes the attack slower. Furthermore, nothing can protect you if your password is password.
Also, I hope that they don't think this removes the need for SSL. It does not. In a web application the server sends the client the javascript to run. A man in the middle can modify it and defeat the whole point of SRP.
What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.
I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle?
If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.
It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.
