Fuck passwords
me.veekun.com
me.veekun.com
Malware trojans don't care about your password.
I don't know why people care about 'password cracking' when it comes to their bank accounts. Please watch "Modern CrimeWare Tools and Techniques: An Analysis of Underground Resources" (http://www.youtube.com/watch?v=zj4VkCB6obI) and your jaw may drop. TL;DW: Bank account sessions are automatically detected and wire transfers happen immediately to shell accounts. Login accounts are detected and sent to databases at C&C servers. People who know nothing about computers can generate a custom trojan to drive-by infect most computers.
Probably 95% of the time, if your bank account gets owned, it's not because someone cracked your magical password. It's because trojans are incredibly sophisticated and will take your money at the moment you log in, all undetected, with no fancy MITM or phishing or SSL cert faking.
Yeah yeah, they got your password and because it's unique now they won't get into some other account of yours. But carders don't care about your other accounts. You're one in a million people owned by their trojan. They'll get the other accounts once you log into them.
There's got to be some weird game-theory solution for "Maximize for security while simultaneously minimizing the sum of all accounts on the Internet which have a password that could possibly collide with a valid password on this site."
So presumably they don't currently optimise for mutual incompatibility. Quick, file a patent. :)
Please file a patent and refuse to license the technology to anybody. :P
What you say may be true, but the banks only enjoy this 'feature' by coincidence.
People on the phone are expensive. (I'm unaware of exact numbers for the banking industry, but based on figures for my first-and-only CSR job, I'd guesstimate in the vicinity of $8 to do a password reset in the US and $2 in India. Given that the median retail checking account is only worth about $100 a year this is not very sustainable.)
Web banking is the best thing that ever happened to cost control for retail accounts and one of the highest ROI channels for getting more business.
Any suggestion for increasing security which results in banks losing money is probably a non-starter. (Not uniquely true for banks: many of the "Wouldn't it be grand if the entire world simultaneously adopted $LOGIN_TECHNOLOGY_FOO" thoughts ask businesses to spend money to solve problems that they do not actually have.)
4igNxz1g
I believe that substantially less than 5% of Americans with a banking account would either a) recall or b) have recorded that when asked for it two weeks later. I have no citation for this other than "I have spent the last couple of years helping people log into their Googles and they frequently volunteer their passwords to me, often in the form 'My password is either kittens or kittens1 or kittens!' They overwhelmingly care about things in life other than computers, password security, and password security on their computers."
Between news sites like HN, content sites like BBC iPlayer, Facebook / LinkedIn / Twitter, eBay, different financial services websites, multiple email accounts, various topic specialist forums, standard and admin logins for each of the three computers I personally own, database server root passwords...... There's just far, far too many for me to be able to tie a unique password to each that complies with their length and character mix standards (and, in some cases, their re-use policies), particularly when the login page (sensibly) won't remind me what their particular complex requirements are.
I'm not at all convinced the end result of their aggressive requirements is more secure. Several of them I end up using the password reset function waaaay more than 50% of the time because it's enormously easier than memorising their particular onerous code.
I've been using 1Passw[or]d since 2007, and literally all my passwords are uniquely generated (including server root passwords, database root, etc.) At one point I'm a bit scared if I ever lost the database, I'd lost access to all websites forever (because I don't even "know" my email password).
Assuming you have a passphrase for Dropbox, as well; then, I didn't know it had a web ui, and that ~does~ make things convenient --- assuming SSL or similar for security.
Dropbox Web UI is just a HTML implementation of 1Password (read-only) sitting in your disk, so its HTTP security depends onto Dropbox (or whatever sync service you use) rather than 1Password itself.
So you have to get a new paper slip every time you log in? How would the logistics of this work? If you have to go to your bank / wait for physical mail on every login, then the convenience of online banking goes away, doesn't it? (Or would you get a collection of them? Then, if you're like me, you'd lose that; and you'd be right back at the inconvenience, while someone else has temporarily unfettered access to your account.)
Much like how they're trying to save money, it's expensive for me to spend time trying to get my money back. Especially since they want to minimise support costs.
Edit: They should provide an option for power users to give an impression of 'strong secure access' while allowing 'secure convenient access' for other users. I've never seen this option before.
So true, and to them "profits" often means "user convenience" long before "user security". I've talked about it here before so this time I'll just post a link to my story about the time my bank reset all its users' passwords to be equal to their usernames (intentionally!):
- Ordered lists: You could only use a number that followed the last used one. So if you had 10 numbers and used the 9th by accident, all previous were void. Forgetting to cross out the used numbers lead to annoyance and the 'dammit, guess I used that number already' factor decreased security (someone could've used the next TAN on your list and you'd ignore the error and think it was your fault)
- A list with columns/rows: The server would know about your 'state' and ask you for a TAN in a specific location. Think of copy protection around the time of Monkey Island.. Progress in a couple of ways, but finicky.
- You had to manage the list to make sure that you don't run out of numbers (the second 'solution' above could help a little, but if you planned to do 10 transaction a day and had only 9 digits left: Bad luck).
Right now, as others said already, you're using your direct debit card with a chip inside combined with a tiny TAN generator that looks like one of these crappy currency calculators. You enter your transaction (you already logged in before, with or without a TAN), the server tells you to enter a checksum (parts of it are clearly identifiable as information that you just entered) into your device w/ the direct debit card inserted to receive a one-time only TAN. Done.
A mobile option is usually present (my bank asks me everytime I log in if I want to use TANs generated by that gadget or being sent to my mobile number), but I actually prefer the other option.
1: https://en.wikipedia.org/wiki/Transaction_authentication_num...
My bank gives me a small card reader (not connected to PC), where I insert my debit card and need to put in my card pin. This gives a one-time code which I enter together with my password to login.
However, this is not all - in order to do anything meaningful (aka transfer money), I need a confirmation code, which is done by me typing into the little machine the amount, part of the account number being credited, and of course my banking pin to begin with. So, I effectively sign the transaction, and having the reader totally offline makes me somewhat confident in its security even if my linux laptop were compromised.
Of course all of this needs to be matched by the proper security rules on the backend, which, given their cluefulness with frontend, I trust them to have.
p.s. That said, indeed now I remember that the password rule they had is kinda stupid. But I have only one bank and I can make the exception for them, given that they have done their homework otherwise.
p.p.s. and no, I would not like to have my bank operations protected by the unlocked private key - the added convenience in this case is not worth the risk at all.
I won't use it, because it means I will be locked out if my phone or SIM breaks.
This could easily be fixed by having a backup phone number to use if the first one fails, but for some reason they never do that.
My bank has an offering that lets you select between getting the code as a text or as an email.
I think it's a great solution and I don't understand why it's not widely used.
While you hit "reload", I establish the connection and login.
Your attempt is the second login attempt. As you propose, it's denied.
Your next steps, while I am changing your contact email and other info ?
Obviously if the cost (to the bank) of online fraud gets high enough it starts to make more sense. What's interesting is that some online apps (eg, World of Warcraft) have seen the benefits of providing 2-factor authentication faster than a lot of Financial Services companies.
2-factor auth of one kind or another seems to me to be a good idea for online banking, given the prevalence of banking trojans which have keylogging functionality.
Those without smartphones could fall back to fobs or more "traditional" forms of auth.
Question: what is a good/trusted one-time key generator for Android and/or iPhone?
It implements an open standard for OTP and they provide source for a PAM module to require the OTP on the computer side.
Being forced to pay a small fee (by your phone-service provider) to log in isn't much better, I think.
It's easy to negotiate to get them for free when you have any amount of leverage on the provider, but out of the box you pay.
Ah, but I can still pay my bill by telephone and all I need is to dial in the card number when prompted...
For example: http://googleblog.blogspot.com/2011/02/advanced-sign-in-secu...
Alternatively, the key-fob could have an arrow to select which site to show the key for, but that would be cumbersome. Personally, I think that a solution similar to the ssh one would be best in that you have some sort of pass phrase that you type into your browser, and it unlocks a private key that can prove your credentials on web sites.
RSA, one provider of such tokens, was hacked making many of those devices worthless.
RSA was hacked because someone in Personnel opened an attachment supposedly from a recruitment agency.
(http://www.pcmag.com/article2/0,2817,2391951,00.asp)
Very frustrating that the expert people supplying the extra security for the people wanting extra security are the people falling for stupid stunts like "include an infected Excel file, and hope someone opens it".
They could just, in RAM, take off the last 6 characters of the password they got and treat those as the token with the rest being the password itself. At this point it's not much different from passing them separately.
The main point of the original rant was that we have a solution that doesn't require this, but it's not used for any websites.
Hashing the password before transmission gains you basically nothing. Hashing on the client side simply means that your hashed password becomes the effective password. Anyone who could theoretically sniff the password could also sniff the hashed password and perform the same kind of impersonation or man-in-the-middle attacks. You're introducing a bunch of complexity (and breaking compatibility with clients that don't, e.g., support Javascript), and you're getting nothing useful in return. And yes, you could implement some kind of challenge-response and basically try to reimplement a secure handshake and auth, but you'll probably get it wrong because security implementations by laypeople are generally quite broken, and at the end of the day, you should just turn on SSL and do it the way that works.
* cost to retrofit the backend of these systems onto the bank's retail software
* cost to roll out tokens to customers
* ongoing support costs for e.g. lost or broken tokens
To all that, you have to layer on the fact that tokens are priced for a different market (enterprise security), so the existing products aren't packaged in a way that makes them palatable to (say) Bank of America's many tens of millions of customers. You can't wave a magic wand on that problem either; tokens are packaged the way they are now because that's how you can keep a token company in the black.
You know, I have a checking account that I don't keep a lot of money in (because I rarely write checks nowadays) but have had so long that I don't really want to close it. I was surprised to notice last week that the bank is charging me $12/month in account fees unless I keep a minimum of $1000 in it at all times (effectively, an interest-free loan to the bank). For $144 a year, I think they can afford an RSA token or something better than the existing nonsense.
I know, the bank makes money from fees and that's the price I pay for access to a large ATM network..yet I distinctly remember a time when they made money from lending, while still managing to have a risk management policy grumble grumble
I think one obvious (but HN-unfriendly) point to be made here is that the overwhelming vast majority of bank customers could give a shit about online authentication systems.
They have the largest ATM network on the planet; every ATM is free-of-charge. (That is, they'll refund the fees, if the ATM charges any.)
You know what was expensive? The bank bailout. I want my $8,333 that I'm paying to keep banks open back.
The question was asked, why don't more banks use tokens? I provided an answer. That's all.
With some variations such security measures are ubiquitous here. SMS tokens, an electronic device that generates numbers. A card full of numbers of which a couple of them are asked before each transaction, etc.
That's not failsafe but it raises the bar quite a bit above 'enter password to own everything'. Also, no extra hardware required.
It's mildly annoying in that you need to take the token with you if you want to have banking at your fingertips, but then it does mean you're extremely unlikely to be hacked.
It's especially important that part of target account is used to generate authentication verification key. Because using static or non-content sensitive confirmation codes is useless.
I see what one of the commenters mentioned about the "extra gadget" - but I usually make internet payments at home - so no need to drag this gadget really. Plus, in theory I can use my friends' one - the gadgets are absolutely identical; the "something I have" part is on the card itself, which is in my wallet.
Patrick, I think you're giving banks much more credit than they deserve. They are slow-moving monoliths that only respond to security issues when their profits noticeably drop.
Edit: And that's probably a smart tactic, as they aren't getting sidetracked from their primary mission of generating revenue.
Which is fantastic when I have to read said password back to them over the phone.
But in my (personal, not professional) experience, they're not mutually incompatible. The bank and credit-card sites all restrict users to short, weak passwords, and it would be perfectly possible for me to use the same password on many of them.
I have unique passwords for my email accounts, github, facebook, twitter and bank accounts. I only need to remember about 8 passwords. They are all pretty memorable. I usually write them down gasp. I then manually type them in until I remember them. I then rip the paper in two putting half in recycling and half in the trash.
For every other site I use 1 of 3 passwords. Why? Why not? I mean seriously, if a site contains no personal information apart from your email why do you need a separate password for it?
I only use unique 10+ character long passwords to guard things that are worth protecting. If a forum account, stack overflow account etc gets hacked.. oh well. I will make another. It really doesn't matter.
I would use 1 password for all non-critical sites but password restrictions means I need 3.
Some of the sites (the ones with more 'social' features) could be used by attacker to impersonate you in an social engineering attack.
The problem is that both position themselves as one login for tonnes of services. I do use Twitter to auth into services from time to time. This is why a strong password is important for these. An attacker could get into your account then cause some serious damage to your reputation both amongst your friends and to the outside world by authenticating themselves into one of the million services and acting like a prat.
I know that one of 3 passwords is compromised. All of my friends know it. Even some of my friends of friends know it. So far I haven't noticed any of my accounts being abused. If anything I have noticed friends using it as their memorable password :)
Way back when, in the days when I used a single "low grade" password for signing up and trying out sites, I registered on perlmonks.org, which I didn't ever end up becoming a regular contributor and pretty much forgot about. I also signed up for this new fangled "micro blogging" service 'cause I could use it to send free text messages to my friends overseas. It was called Twitter. 3 years later, I've got a quite vibrant social life going on in Twitter, and thanks to the browsers remembering passwords for me, I'd forgotten it was using my "low grade password" and I never upgraded it when the importance of that login increased. Until the perlmonks database (with its cleartext password storage) got exposed, and 5 or 6 hours later I started getting questions from friends about why I was spamming them on Twitter with Acai berry spam...
Now 1Password generates and stores all passwords for me. Its data is synced (via Dropbox) to my phone/sparephone/ipad/laptop/work machine/home machine/media center. I'm happy enough to not be able to log into any website whos password I've not bothered to remember when I don't have access to _any_ of those devices - I've got all 3 banking passwords in my head, two email passwords, a few important ssh key passphrases, and a few others (like my Apple ID password, since there's several places 1Password won't fill it in with CommandBackSlash, so I find myself typing it often enough to remember it), everything else I rely on my (multiply synced/backedup) 1Password database for.
Its working out _really_ well so far (I've been using it ~18 months, probably managed to transition to all random passwords about 12 months back.)
This means that ideally you should have chosen two different passwords for both these accounts.
For some sites like reddit, HN, etc. one may know very well in advance that they don't care about their identity and they would be happy to create a new account when they lose one. I think these are the only cases where password reuse is justified.
Suddenly, there's somebody out there in the world who can not only post comments to Engadget as me, but can now upvote stories on Reddit as though they were me.
Honestly, you could give out your password to 90% of the sites for which you have them and it wouldn't affect your life at all.
Personally, I have exactly one site from which I tolerate non-email messages from friends. That's Facebook, and it's in the same category as email, ecommerce, etc. that gets a real password.
You have email, telephones and facebook for talking to people. Why would you expect somebody you know to sift through threads on reddit to find out if you've said something to them?
Can you honestly say that you've done that? I never have, so it doesn't bother me whether you can guess my password to one of those sites. And if I ever ask to you wire some money to me in a comment on an engadget post, feel free to give me a call to confirm.
To be clear, the worst-case scenario I'm thinking of isn't when a single person has your email/password, but when someone has posted it to pastebin and everyone has it.
If one site lost its database. Lets say I have 60 accounts on various sites. Based on my 3 passwords 20 or so would probably be compromised. Apart from maybe my name and email address these sites have almost no other personal information. What is the worst that could happen? The account gets banned? A phishing attempt for a site I don't care about?
I don't need to change the password. If an account gets banned or the password changes I will just make another account. I would rather do this than not know passwords and rely on some third party service to make and store secure ones for me.
For the 10 minutes it took me to write the one-liner that generates passwords from a fixed seed and the domain passed through an hash, it was certainly worth it.
I actually have to think less about passwords now: instead of trying 1-3 passwords before figuring out which one it was I used at a particular site, I just generate using the site name, no thought involved.
Mainly, the reason for switching was the feeling of insecurity I experienced on discovering that someone else had accessed my account, even though it was an account on the non-essential list. I didn't even know what other sites were using that password, so I ended up deciding to switch passwords everywhere. A few accounts into that process, I just got fed up and decided to go back, switch strategies completely, and forget about passwords as much as I possibly could.
I wrote my generator both as a python script on the commandline and as a javascript web app I host on my domain, so I can generate passwords without access to my computer.
Obviously you want to protect your house against break-ins, so you spend money on a great security system. But people would think you were insane if you spent an equivalent amount to lock up your old lawnmower, charcoal grill, and gardening shears.
Google and my bank are my house; those passwords are secure. The password to my MySpace account? If someone discovered it, the biggest annoyance would be finding out which of my friends still have accounts.
For me, kwallet & ssh public keys all the way. Kwallet makes passwords available to all programs I authorize. Authorize either on case-by-case basis, or once forever. If you really don't want to bother with KDE and/or want to be easily portable across everything POSIX, go for http://en.wikipedia.org/wiki/Factotum_(software) -- it has a simple protocol.
I remember literally 5 passwords: home computer, work computer, home wallet, work wallet, auxilliary bank account (just in case something happened to all of my computers at once).
Actually, scratch that, I can /type/ those passwords, but I don't really know their content.
† using ^C^V on passwords is a bad idea anyway; (depending on browser) websites can read contents of your clipboard. And check your recent browsing history. 2+2=...?
Copying and pasting passwords about is fine, as long as you don't leave them in the clipboard after you've finished with them.
My main current password management grip is that I don't have a good way of migrating my GPG-encrypted password file to my phone, other than hand-entering values one at a time.
That and updating password files kept in different locations.
I'd much rather rely on the security of GnuPG for my password store, than Keypass or Lastpass etc. Dropbox provides me with backup and syncing capability for my password store.
There exists a rather elegant alternative to passwords for authenticating a user's identity - it's been around for a while but the user barrier is too high: FOAF+SSL.
The idea is you generate an X.509 cert and install it in your browser(s). You then stick the pubkey in a section of your own publicly hosted FOAF file (hosted by yourself or by an FOAF hosting service) - then when you "visit" a site that requires you to authenticate all you have to do is give it the location of your FOAF file, the browser will prompt you to select which cert you have installed that you want to use. (there are cool things you can do with remembering a user too)
This solution is elegant in two ways - no password entry, it uses a cryptographically secure certificate for authorization (much more secure than a password hash), the application in question can also pull/cache YOUR FOAF DATA (name, address, alias, whatever you have in there) so you NEVER HAVE TO FILL OUT A PROFILE FORM AGAIN.
That's effing cool, man. Why don't we see it? Because it's easier to use Facebook Connect and get the same stuff nowadays then it is to try and educate internet users on A) what is a FOAF file? and B) where/how do you generate it and host it when Facebook basically has all of that already (I know, once is personally owned, the other is owned by Facebook but we can't always control the ebb and flow of internet mass consciousness even if something is "more elegant" or "stupidly better").
Creating a password is not a job that users are good at.
Remembering passwords is not a job that users are good at.
Solve this problem for your users.
It's not super tricky. Make up a couple of new kind of input types. Say, input type=trade-keys. When you see that on a page, create a private-public key pair and swap it with the server. Take the private key you made and the public key you got and encrypt them using the user's passphrase---the only password a user should have. Store that locally and make a back up to your cloud service in case the user wants to log in with another computer or the user loses their hard drive somehow.
Done.
Not only browsers aren't solving the problem, they actively make their users' lives more difficult by obeying autocomplete="off" set by overzealous webmasters. I had to hack firefox to save a password to my yahoo account in it -- crazy.
http://my.opera.com/operalink/blog/2011/05/03/security-of-sy...
It blew my mind because a coder had to burn some calories code the site specifically to disable copy/paste. What kind of UX is that?
I have a few bank accounts for my company (checking/investments/etc.) which each require different logins. That's fine.
However, the security questions for a business account are inextricably tied to an individual. Favorite animal? High school mascot? Where were you born?
These are all questions that are pretty easy to crack for an individual account, so they provide next to no added security. Furthermore, for a business account, they're just an added layer of frustration. When I took over the accounts, I had no idea how the previous president answered the questions, since they're all personal to him, not our company. Furthermore, when someone else at our company needs to access our accounts, they need to know the answer to my security questions... which are the same ones I have to use on my personal bank accounts!
In the end, it's so much of a pain to remember the answer to these questions that when I'm randomly asked to verify, I'm just as likely to call customer support and ask them to reset them. So what does this mean? I call customer support and give them
1. My name 2. My company's name 3. Our username 4. Our bank account name 5. Our tax ID number or the last 4 digits of the social-security number on the account.
...most of which would be pretty simple for a would-be attacker to obtain. And let's face it, corporate accounts at banks are much more likely to be the targets of individualized attacks, rather than random attacks over an array of accounts.
tl;dr: For business accounts, security questions actually decrease security.
So you called customer support to reset the password. You could call them whether or not there were personal security questions. Nothing changes.
OTOH the personal security questions ensure only one person can access the account (when attempting a normal login) instead of any employee at the business. Passwords might be shared but security questions probably wouldn't be (assuming only one person is accessing the account).
The questions are not intended to be impossible to crack. They're an additional data point to verify authenticity. The assumption is that you won't keep the name of your favorite animal next to your password (wherever it is that someone got your password from), thus it's an additional attack vector someone would have to account for. Not impossible, but adds difficulty.
tl;dr: added authentication prompts add to attack complexity, and you're on crack.
[p.s. you might want to change your bank account password and challenge questions when an employee who had it leaves. could be helpful.]
They're just text field responses though. No one is checking that your first school was really called "w4ffl3s and |3eeR".
However, your point stands firm and proud. It's security theatre really isn't it.
In my mind, someone (browser vendors? security community?) should create a standard for handling interactions to do with passwords. Covering password length, characters allowed, characters required, case sensitivity, et cetera. Or perhaps a grading mechanism. Give it a catchy name and get some noted security researchers and clueful businesses to endorse it. You could even have a browser extension which points out to users which sites are handling passwords poorly or in an inconvenient way.
With respect to the issues with banking institutions: why not take it up with your congressperson, or write to the FTC and/or SEC? The FTC is charged with consumer protection, and this seems directly in line with that. Again, if there was a grading tool, the regulators could apply that.
From the document he links to it seems more like a fancy password manager that handles session cookies too with the idea of standardizing account management. Not necessarily a lofty vision but certainly something helpful and interesting (albeit seemingly dead now).
Each of my passwords is made up of the same eight-character non-dictionary word, plus the alphabet-position numbers of the first three characters of the name of the site I've made the password for (A -> 1, B -> 2, that old trick).
So for example, say the common word I was using in my passwords was "pizzadog", then my Hacker News password would be "pizzadog813" (H -> 8, A -> 1, C -> 3)
I admit my goal is convenience, as it's clearly only one step up from using the same password for everything, but with the added numbers making me feel a little better in the event of one of them being compromised. But is there any reason why this approach might be considered a bad idea?
Or, they have you register on just one site they control, and figure out the substitution trick. They now have all your passwords.
Now that you made the post it's even worse: we all know your password here is 8 lowercase characters + 813. If that's really true, I recommend changing all your passwords everywhere, NOW.
It's an extremely, extremely tiny step up from having the same password everywhere.
That's not going to happen with that scheme.
As long as you're not also using this for email/banks, it's not that silly, I use a similar scheme myself, it means you can log in from computers that aren't your own to certain services without having to install anything or carry round a bit of paper.
$ strings ~/Library/Application\ Support/1Password/1Password.agilekeychain/data/default/* | less
You need to pick a good password, but there's only 1 to remember (hence the name).
Did they store them in actual, real plaintext at one point? If so, that's not how it works now.
What's the simplest thing that could work to fix this problem once and for all? I get the impression that there simply isn't one.
Maybe something more simple - a 2-step thing like Google's on my iPhone, except one that logs into multiple sites. That, or get 'Google login' widespread and have it as the auth middleware on other sites out there.
There's http://code.google.com/p/google-authenticator/ for SSH, http://wordpress.org/extend/plugins/google-authenticator/ for wordpress, http://helpdesk.lastpass.com/security-options/google-authent... for lastpass etc. You can use all these implementations with the very same iPhone/Android/Blackberry authenticator app you use for Google
It's not just browsers - here's an example of a budget web / email host telling users to ignore the warning:
(http://www.purplecloud.com/webmail/)
> When logging in your browser may warn about an invalid or untrusted SSL certificate. This is normal and can safely be ignored - the communication is fully encrypted despite this warning.
People only using one computer (that no-one else uses) have nice browser based password managers. Software like Keepass or Password Safe are handy, but not great if you use more than one computer (especially if you use more than one OS.) Keeping databases both synchronised and backed-up becomes tricky. And some companies / public computers won't allow you to use such software.
Trusting my passwords to the cloud just feels weird and unsafe.
[i guess you are still keeping your passwords in the cloud if you keep it in dbox, but the password DB is encrypted).
And Startcom is a right pain in the arse for various reasons, not the least of which is their interface sucks horribly.
I'm quickly coming to the conclusion that SSL PKI as it stands right now is a huge scam.
I guess you could create a small app that authenticates via an API, which could then copy-paste a signed authentication token to the clipboard, or inserts it into the login page via a plugin.
But what is very difficult is to enable website to authorize using your agent or your private key. But ... the SSL certificates in browser should be the way to go, but as author in blog post wrote "they are just so full of glitches and surprises as to be virtually unusable" :-(
I am now logged into my bank. Now each time I try to do anything with my money (move it from checking to savings, or from checking to my dad, or savings to checking, or to investing) I have to insert my card, enter my pin, enter the number and give my bank the number that is generated.
That is secure. WAY more secure than what I currently have with BoA, ING, WF, First bank, Chase, and Capital One.
What kind of Luddite computer programmer is against using computer programs to solve their problems? Yet is fine with using SSH keys?
The argument of bloat is garbage -- you can utilize LastPass bookmarklets at the cost of exactly 1 bookmark in your browser. That adds a 1K bookmark and a very small amount of JavaScript to the page if and only if you utilize it.
Password certainly are painful, and our whole goal at LastPass is to make it easier. We'd be happy to help make other scenarios people are experiencing better, we've looked at handling ssh a number of times (putty in LastPass for Applications for example) -- anyone have a preference for how we tackle that next?
Btw: The SRP ciphersuites have become established as the solution for secure mutual password authentication in SSL/TLS, solving the common problem of establishing a secure communications session based on a human-memorized password in a way that is crytographically sound,
So I understand it still relies on a human-memorized password? How is it a password replacement?
Even public-key authentication isn't secure if you're storing the private key on a regular machine, and are not protecting it with a password. Getting the regular Joe to actually use certificates is difficult enough, too.
This way, even if one password is leaked, it should be impossible (or at least very hard) to calculate the master password.
I just uploaded a simple demo of this: http://onewheeledbicycle.com/junk/passwords/index.html
Another problem in my particular case is that I have my browser set to clear all cookies upon exit. I'd obviously have to change that, because otherwise I'd lose my private key every time I closed the browser. But that isn't the concern of DSWI I know.
I also checked out BrowserID briefly, but as I understand it that requires all logins to go through a central server. Consequently they need to have a "privacy policy" which "promises" not to track your online behavior. That is not true with a system like DSWI, which avoids any central repository or authentication server.
Packaging PKI so that a non-technical user can use it is the central challenge here. There's actually quite a lot of functionality that is hidden in order to keep things simple. To see it visit:
By the way, these concepts of localStorage and sessionStorage are new to me. Evidently they're something like glorified large cookies in HTML5. Chromium handles it just fine, but I don't think my Firefox browser even understands it yet. I see where I can examine all my live cookies there, but I don't see any mention of "storage" there. (I'm using Firefox 3.6.24 on Ubuntu.)
Consequently I haven't been able to get it to work yet on FF. But maybe that's because long ago I did a bold yet insane experiment wherein I deleted all trusted root CAs in that browser. So it might be my problem, not yours.
This is happening on two different Firefox browsers on two different Linux machines. It must be a problem with settings or a plugin. I'll try it on a brand new Linux machine with a fresh install of FF and let you know.
That said, a silent failure is pretty weird. It can happen if you have Javascript disabled (are you running noscript?), but there's a check for that on the demo page. I just added an explicit check on the DSSID page, so please try it again.
I'm pretty sure the problem is actually related to my deletion of all root CAs. Why? Because there's a red exclamation mark over the lock icon at bottom right of window, and when I hover it says "Warning: Contains unauthenticated content."
I already force-accepted the dswi.net certificate as a specific exception when I first played with DSWI yesterday. I would think that acceptance should apply to the JS content as well. But apparently not. So I'm poking around in my FF settings to see how I can trust your certificate even more than I already have -- yet without installing Comodo's root CA certificate.
It's all my fault, because of my bold yet insane experiment in distrusting all root CAs.
A solution for you is using an OTP (one-time password) as a 2nd factor of authentication. Since your authentication is a lot more secure with an OTP, you probably don't need to use such complex passwords anymore.
For example, you can enable the 2-factor authentication with OTP with Google and Bank Of America. With Google, you can either request an OTP by SMS when you are authenticating and/or provision the Google Authenticator mobile application which will generate OTPs for you. For Bank Of America, you can also get OTPs by SMS. They also provide an OTP card called the SafePass card (http://www.bankofamerica.com/privacy/cf/safepass_card_popup....) to generate the OTPs.
"Speaking of usernames, i've run into more than one bank that requires a digit in your username. A digit. In. Your. Username." --> It cost me so much trouble with my BOA online account! I found out I could actually change my username and it made things a lot easier!
This makes sense, as your credential set includes both username and password - enforcing increased diversity in character selection in username to include numerics increases the exponent by 10 for each character.
This seems quite secure as someone would have to have my card and pin number to access my account, which is the same level of security I have when I access my ATM machine. This was my first experience with e- banking. Imagine my disappointment when I tried to open other bank or trading accounts and found out they just used normal passwords.
Now, I only use e-banking with UBS, even though their fees ares somewhat higher - I consider the security well worth it. I guess the cost of the device and administration must be less than 35USD per year, which they easily make up for in fees. My question is, why aren't the other banks doing this as well. I would totally pay for it.
/facepalm
Never mind the fact that this subject ("Use different passwords!") has been beaten into the ground at this point and if people haven't clued in by now, they likely won't until they're compromised.
To log in on the site, you need to do the following steps:
* Load site and type in card number (this is mostly a pain, but if needed you can make your browser remember the number)
* The site provides you with a "challenge code", in the case of my bank an 8 digit number
* You take a little machine provided by your bank, it looks basically like a calculator of sorts
* Slide your card in the machine
* Enter challenge code and your pin in the machine when asked for
* Machine returns a number which you then input on the site
* Click login
This challenge code is different every time, the only (big) downside is always needing the machine when doing online banking. However, I feel that's a small price to pay given that once logged in you can make transactions, something I wouldn't trust much if there was only a password with silly restrictions.
Also note, you have to repeat the challenge->machine->reply action when signing transaction you enter online.
The upshot is that the technology to move away from usernames and passwords exists. What we (the IT world) haven't been able to pull off is the ecosystem, to borrow an over-used cliche.
What we need are identity providers - some kind of body that can verify who we are. A good candidate is the passport office (FCO in the UK), the drivers license people (DVLA, in the UK) or the people who issue birth certificates.
Others, like banks, credit check agencies or supermarkets might also fulfill this role, but the scope for abuse and potential lack of accountability might make these bad choices.
Typically, the technology is not the problem. People are the problem.
It allows for the use of OpenGPG keys.
There's also a web component so your website can use it! However it only has a FIrefox/IceWeasel plugin for now. It's two parts; the server side validation stuff, and the browser plugin.
Like many have said, I have a 6-10 password bank of relatively complex passwords that I use for services I may need to easily use on alternate computers. For everything else, I use randomly generated values (usually 24 char, including alphanum, special, hyphen, underscore, and white space) which I store in a Keepass db. I keep the Keepass db on a flash drive which I keep with me virtually all the time.
This technique is frustrating at times, but I like knowing that if a password is compromised, it's either something that can quickly and easily be addressed, or it's something that I really don't need to address.
Also I'm using SSL client certs for a recent project, and I LOOOVE them. I wonder what sorts of problems render them "unusable" for him.
Basically, his passwords are made of two variable strings: one is the service (easy to guess if you're target a specific account, which in his case you must anyway) and a master password that likely doesn't vary much from one identity to another.
Doing this is basically opening the door to anybody who could gain access to his generation algorithm. I have no maths to back me up but I made a quick proof of concept that I ran against /usr/share/dict/words and managed to find one collision in ~100000 tests (I was generating passphrases though).
I'm going to keep on investigating and try to generate passwords instead of passphrases.
And I'd be astounded if there weren't already automated tools that do this for every website in the alexa top 1000...
I agree reusing passwords for multiple services is risky, but shouldn't having different tiers of passwords handle this? Use a really weak password for stuff you don't care about or sites you don't trust and then use a stronger password for your bank, email, etc.
Technology that implemented in every browser right now (certificates) + compatibility with stuff like USB dongles, smart cards, that have also been available for some time now. Oh and no, you don't need a CA. Problem solved?
http://www.w3.org/2005/Incubator/webid/
Only thing left is using it and making browsers more friendly towards that approach. This mainly involved getting rid of scary technical warnings.
Until then I will use password maker, which isn't a store but creates the correct password when needed:
Uh, how are SSH keys not using a computer program to store your secrets? Just use a password manager. You discovered the hard way why your special scheme doesn't work. Use a password manager (like KeePass). Use it with Dropbox, use it with a Flash drive.
e.g. For gmail rather than "password3" one might use "give me my god damn email you stupid machine!" It's great because it's easy to remember, and complex enough to keep you relatively safe.
e.g. 2.0 : http://xkcd.com/936/
Why haven't they thought of this before!? I can come up with very good security questions that incorporate inside jokes with knowledge only I know and things I know I wouldn't share with anyone publicly.
These are things I will remember all my life and that nobody else will know (unlike say, my father's middle name). Unfortunately, Ally asked me for answers to three pre-determined security questions right after.
But there is hope!
NO. NO. NO.
Password length is by far the most important factor to brute force attacks. Which, I presume, is most people's concerns because if we're talking about weak hashes or plain-text storage, you're kind of fucked anyways. You can have your cake and eat it too.
Take, for example, some convoluted piece of shit password like `1Liek2Progr4m35423\!#@`. First off, most people won't remember that without using a password manager or copying it from your super-secret text file in your encrypted folder.
Sure, there will be a few people that chime in saying, "Hey, I can remember complicated, crazy passwords". Okay. Can you do it when the service forces you to rotate passwords, e.g. AD? Most users can't. Trust me. They can't.
So, what now?
Just make really long passwords. Instead of `fC29ap5w78r3IJ`, make it something you will remember. For example: `$omeb4s1ePr3fix I like to cheat on my wife with the secretary I hate her so much`. The entropy of the second password, due to its length, is much better than the former.
Now, if we're talking about services don't let you have an obscenely long password, that's... a service problem. While the implications are real, we're talking about "how to make really good passwords". I feel like this has been answered, but people are insistent on some arcane notion of using some complex string of characters -- as if the computer gives a fuck. Not everything is a straight dictionary attack, and the computer doesn't give a fuck if your password has words in it or not insofar as it's not just one or two words. It's not going to break a 42 character-long sentence that much faster because it has WORDS in it.
And, there's no way somebody should be able to be trying to guess your password that many times without getting locked out. Unless we're talking about somebody hacking into the server itself, dumping out the hashes, and trying to break it that way. Even in that worst-case scenario, assuming they have done their due diligence with salts/bcrypt/etc, a 42-character length password should take them somewhere in the vicinity of for fucking ever.
EDIT: The benefit comes from the prefix and the sentences. It pretty much deters both kinds of common algorithms even if you reuse the prefix.
But that's not what we're talking about. As you say, that's been answered. But in the real world the answer doesn't work well, and whether or not it's a service problem it's a real problem.
There's only one downside. If you generate your password based on a phrase and add the service name to that, it could be easily guessed in other services.
If you use RedBananasFlyReallyHighAmazon for Amazon and RedBananasFlyReallyHighPayPal for PayPal (which, by the way, doesn't work, as PayPal for whatever reason blocks the word PayPal), one could guess the password from the other service, if one gets compromised.
Ultimately, you can only hope for the service to store the password hashed and salted, but in reality, that is not always the case or there's some novice programmer trying something out and all passwords are logged in plaintext somewhere else, while the database stores them hashed and salted.
But generally, I prefer this approach, as it provides a lengthy password, different for every service and easy to remember.
Paypal -> $pr3f1x29# elh oh el I liek money u gieve
1) Try known common passwords: "password1", "monkey", etc. 2) Try dictionary words, maybe with leetspeek substitutions, maybe with a single digit on the end 3) Try likely guesses based on what they know about you (if anything) 4) Brute force.
Assuming your password isn't dumb enough for 1-3, you just have to put your needle in a HUGE haystack. If your password is ":$have:$fun:$cracking$:THIS1", brute forcing your password requires trying every combination of upper and lower case, numbers and special characters up to 28 characters.
At one hundred trillion guesses per second, that would take "76.43 million trillion trillion centuries".
Check this out. https://www.grc.com/haystack.htm
This does mean that 90% of the time I need to go to PassPack before I can login anywhere. Recently I've also wondered if a public key solution could work in a browser. That would be fantastic.
It's an open-source, portable password generator. No ads, no gimmicks, no password storage. The basic premise is "Don't store passwords, generate them locally on your computer when needed."
Support OpenID!
Any other ideas?
too many "pros" are too tied to die hard password auth ;-)
whenIamabletoImakemyimportantpasswordsaverylongphrasethatIthenmemorizelikeapoem
I was saying that a) firesheep does not have anything to do with passwords (which he implies it does) and b) it would be prevented with ssl anyways. I don't even know why he brought it up.
Here are a few things I learned:
* Banks don't need complicated passwords. Though they force you to use something that you'd normally consider ridiculous, like ^([a-zA-z0-9]){6,8}$, they also are much more quick about locking the login. On top of that you typically don't have to worry about SQLi with your bank and they do all use SSL. Phishing attacks are much more likely.
* I use LastPass and my typical password is a random 32-character alpha + numeric + all sorts of special chars string and different for every site. Some exceptions still apply: I want my main Google password to be something I remember and I feel all right about that since there I can use two-factor auth.
* LastPass knows your passwords. Or at least they could. Consider that when you log in to share your password with someone (see below for why), you can expose your password to yourself on their site. Now all they need is some JavaScript (potentially inserted by a malicious person from a third-party domain) to grab it out of the DOM.
* LastPass has the ability to share passwords with others. This works well in my situation where my wife has all of our banking and utilities passwords, and either one of use can pay the bills. Once again, the fact that every site gets a unique password means that I can share these without sharing the passwords to my employer's servers, etc. On the flip side, explaining how LastPass works to a non-geek was a challenge. Their plugin for Chrome is just sort of ugly and clunky (Chrome's fault).
* SSH agent is fantastic. I set up all my personal servers and workstations to only allow pubkey-based logins which means no more script kiddies trying random passwords. I also set up a PAM module to authenticate sudo using pubkeys and SSH agent, so I never enter a password into a remote machine.
* SSH agent forwarding may be set up in a very insecure way. The biggest problem is that if your local machine doesn't ask for permission to answer a pubkey challenge explicitly, you could have the following situation: an attacker compromised your remote machine. They have replaced /bin/bash with a clever script that executes bash, but also scans your ~/.bash_history for other hosts that you SSH'ed to. Now as soon as you log in, /bin/bash starts trying those hosts one by one, logging into those hosts and doing whatever the attacker wants since they also have access to sudo.
* Other things to be paranoid about: evil browsers, compromised operating systems, malicious browser plugins, key loggers, people with physical access to your machines, other people's dumb passwords on the same servers that you log into, MITM attacks and not checking the key signatures of SSH servers, monsoons, terrorist organizations, drug cartels, brain washing, swine flu and Soviet era doomsday devices.
Basically, LastPass and SSH agent are way better than using the same password, but just be careful about how you set it all up.
How is it Chrome's fault? It looks like pickled ass on every browser I've installed it on as a plugin, and it looks like ass as the iPhone app.