I love this post, but must point out something about banks and passwords:
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 is a (mildly) compelling reason for every bank to have a stupid password rule which is mutually incompatible with every site in existence: it means that compromising that other site's identity:password dictionary and then running it against your bank results in zero successes. Regular users reuse passwords given the opportunity to do so, and most of them will happily cough up their bank password to, quite literally, any site on the Internet.
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."
As someone that has been the lead for many large banking systems, I can say your intuition on this one is off. Banks enforce these rules because some internal security group set the rule a while back and thats what they use. Many smaller banks use whatever password scheme the banking software service provider has as its default. Its just bureaucratic deluge. Its certainly reasonable to pontificate that this deluge results in safety per your rational. But I have never seen a study that shows this to be so. It may well be that many set their banking password as the first account they ever used on the Internet and then reuse this same password for subsequent systems.
I think using the password alone in the bank is a stupid idea in the first place. If all that stands between my dollars and miscreants is a few characters - this is careless to say the least. Think trojans/keyloggers.
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.
Few years ago my friend had an account in a bank that gave him security token, that generated a random number every 60 seconds, that had to be appended to password during login. So even if someone sniffed your password, it would be valid only for less than a minute :).
I think it's a great solution and I don't understand why it's not widely used.
Because they are hellaciously expensive, in terms of:
* 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
Banks are moving to multifactor auth systems. Expense is slowing the process down. Buy me a beer next time I'm in San Francisco and I'll give you anecdotal details I can't give here.
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.
Switch to a credit union, then. If your profile info is accurate, you live in a region served by the SF Fire Credit Union (http://www.sffirecu.org/). I switched to them a few years ago and it's been a great experience. Save yourself that $144 a year.
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.)
Make it an optional smartphone app, like Google's two-factor auth. Maybe let people buy a token like Mt.Gox does (they are hardly huge, and they could afford it...name.com and World of Warcraft too.)
You know what was expensive? The bank bailout. I want my $8,333 that I'm paying to keep banks open back.
Short answer from my experience is cost. The individual tokens have a cost, then there's the management overheads of running the system. Initially it doesn't seem like too much but if you've got a customer base numbering in the millions, it can get quite pricey.
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.
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".
That's not an inherent flaw in the idea, though, just in RSA's implementation. There's no real need for the servers to hold on to private device-specific data.
This is a horrible solution. I don't care what security experts say about two-factor authentication. I'm not about to start stuffing my pockets with a pile of security tokens. I have more than enough keys on my keychain, thank you. Unless everyone can agree to use the same physical token, I simply refuse to use a service that makes me carry an extra piece of junk with me all the time.
Although slightly ahead of its time for the masses there are implementations which do not require you to carry another device. You can use your telephone and be provided with your second factor via voice, sms or application running on your smartphone.
It's a particularly horrible solution when your bank decides to replace their existing clever nigh-impossible-to-sniff multi-factor authentication system with a little dongle sent to your home address whist you overseas. Specifically, I need it to pay off my credit card bill with the same bank; I can still log in and shift money between savings accounts at will.
Ah, but I can still pay my bill by telephone and all I need is to dial in the card number when prompted...
The only problem with this, is that it requires everyone to trust a single third party with the authentication. Since the input space that you type in is small, any one-way encryption is easily reversible. This means for every site that the code is good for, you would need to reveal a means to generate the code, rendering it the password problem all over again.
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.
Lastpass is awesome and even with google authenticator if you do not have your phone with you they give you the option of printing out like 30 one-off codes in case of situations where your phone is dead or missing.
That's a problem with cell-phone providers who overcharge for SMS. An SMS is almost free nowadays, in some cases it actually is free since it goes over channels that would otherwise go unused. SMS seems like a good, cheap, ubiquitous solution for most of the developed world.
From horrible providers, yes. The big three legacy operators in Canada charge 15 or 20 cents per unless you're specifically on a plan that includes a larger allowance.
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.
It depends on your contract. In general, by default, you pay a bit for every text (10 cents maybe?). But you have the option of paying a flat rate for unlimited texting, which is generally something like $10/month. Most people I know choose that option.
Let me ask again the parents question for clarification. Do people really pay for the received sms-es? It sounds like total bullshit, because you don't have an option not to receive sms from a person, like you have with calls.
Absolutely (in the US here). Some carriers will allow you to block all text messages, which can get rid of the annoying ones you wouldn't want to accept, but also forces legitimate ones to get eaten - causing some people to think you're ignoring them when you actually had no idea they even tried texting you in the first place.
Less than a minute is also short enough that the bank can simply deny a second login attempt during that time without causing any inconvenience to you.
Absolutely. i got your TCP segment with data on your WIFi, and sent a TCP RST from a location with the lower overall latency - so both your SSL connection got reset.
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 ?
That's bad solution. As well as password lists. Because it doesn't verify sum or target of the money transfer. Money can be transferred to anywhere when you give the confirmation code.
My bank requires both my pin (numeric) and password to log into my account, and SMS's me when I login. If I need to transfer money to anybody outside of my usual payment recipients it SMS's me a token that I have to enter.
That's not failsafe but it raises the bar quite a bit above 'enter password to own everything'. Also, no extra hardware required.
I have two accounts with security tokens. In one case they charged me $20 for the token, in the other case they gave it to me for free with the account.
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.
If the description of password+number is accurate, then it's a poor solution because it means your password is sent to the bank as opposed to being hashed and the hash being sent to the bank.
This comes up every time passwords are discussed, and it's a bad idea. A password sent over a secure channel is fine. A hashed password sent over a secure channel is generally fine, though more complicated. A password sent over an unsecured channel is not fine. Neither is a hashed password sent over an unsecured channel.
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.
This is common practice. Our password forms all over the internet send the password just as part of a normal request. We rely on SSL to protect that data as it goes over the wire and then there are all sorts of ways that it might be stored in plain text somewhere on the servers.
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.
It is widely used. At least in several parts of Europe I've been to and/or lived.
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.
It's really nice see that some banks and sites have good policies. But most of sites and banks got absolutely horribly bad security. Afaik, that's one of the best ones I have seen this far.
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.
Exactly - because all of those solutions do not take into the account the possible active keylogger which might interfere with the "authentication code". In fact I think here in Belgium there was an incident where chunks of money were stolen from people.
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.
This is much better than password alone - and very nice usability-wise. But it significantly increases the area that you need to trust to be safe. I would not like to have it for all of my accounts. But would be cool if my bank used this system for transactions under 100 euro, for example.
Set up a Google Voice number and have the text sent there. GV can then forward that to your phone, so you have the convenience of getting it on your phone with the knowledge that you can get to it even if your phone is not working.
My bank has an offering that lets you select between getting the code as a text or as an email.
And probably you are right. I can't use my internet banking of one Singapore bank right now. I am not there and cant receive an sms with one time password on my Singapore sim. It sucks!
That's an interesting idea. Unfortunately it looks like you can comply with all the rules in his banks section by having an 8-digit password, which is conveniently the number of digits in a birth date.
So presumably they don't currently optimise for mutual incompatibility. Quick, file a patent. :)
There is a (mildly) compelling reason for every bank to have a stupid password rule...
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.
Or the bank could just issue a secure password (or better yet, a list of one-time passwords) for the user. No need for silly rules, and probably much more secure than letting sixpack joe pick his own password.
Banks don't optimize for security, they optimize for profits. Picking passwords for users would be more secure, but it would also disincentivize use of the website and cause a huge spike in support requests.
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.)
Unfortunately, I left such services due to this. It makes me think their system security is poor and asking to be broken into. No matter what 'security' marketing speak they use, I'll assume they have a similar if not same password policy for their IT department.
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.
> Banks don't optimize for security, they optimize for profits.
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!):
Why do you think that bank-issued passwords would either disincentivize use of web banking or cause more support requests than the current convoluted systems?
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."
I realised a while ago that the most problematic logins for me were the ones with the most onerous password requirements. OK, I know this isn't great, but I do reuse passwords. The ones I care about least have the least adherence to good security practices, because it so vastly improves the user experience for me. Other solutions have been tried and cause more problems than they solve.
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'm willing to be persuaded, but I'm currently using two different machines, each with two different browsers open, and this is a relatively light usage case... It's a remarkably complex problem.
1Password can sync between multiple machines via Dropbox. I'm not sure about other OS, but on a Mac there is a browser plugin for Safari, Firefox and Chrome (and a companion iOS/Android app).
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).
If you're using this 1Password for everything, how do you log in to your Dropbox?
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.
I don't use (no longer use) Dropbox. 1Password database is synced to my phone via Wi-Fi, and I always have my phone with me so it never really a problem. If I ever leave my phone elsewhere, then I've got a bigger problem anyway.
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.
If banks would supply the password on paper, then that issue would go away for most people. And if the bank would use OTP then supplying passwords on paper slip is a natural solution. I know that that kind of solution works even for computer illiterate people, as most, if not all web banks around here use OTP.
> If banks would supply the password on paper, then that issue would go away for most people. And if the bank would use OTP then supplying passwords on paper slip is a natural solution.
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.)
My bank gives a three times folded, credit-card sized password-card, and mail automatically a new one when you are about 2/3 through it. As it is credit-card sized, it can conveniently be stored in wallet, and thus losing it isn't much of an issue.
Deutsche Bank does this for online transactions. All your purchases and, if I remember correctly, bank to bank transfers require you to refer to a sheet of TAN numbers that is mailed to you when you open an account. It was surprisingly annoying at first but I got used to it.
These lists of TAN [1] numbers are phased out everywhere around me. They usually were hard to carry with you (just as a token, but more easy to destroy), had usability problems:
- 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.
There is a (mildly) compelling reason for every bank to have a stupid password rule which is mutually incompatible with every site in existence
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.
Actually the main reason I have seen in practice is that banks still use a lot of legacy software in their core banking systems and many of the green screen mainframe programs have things like maximum password length of 10 characters or no punctuation (alphanumeric allowed). Of course eminently solvable but still surprisingly common.
I always thought it was done this way to avoid attacks such as XSS, SQL injection and so on. Free text fields are hard to validate and the authentication is usually a very sensitive feature! It seems to be the easy way to be safe (from the developer point of view).
Why would you need to worry about these at all?
The password is supposed to be given to bcrypt, and the result from bcrypt is something that's usually not suitable for attacks on anything.
So yeah, it may be sensitive, if you store plaintext passwords, but then that'll be the least of your worries.
This is why I use the longest password I can on these sites. If they're going to force me to use lowercase letters and numbers, I'm going to use 20 of them.
Which is fantastic when I have to read said password back to them over the phone.
I don't understand this whole never reuse passwords nonsense.
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.
I did what you do until one of the accounts I had with a "shared" password actually got compromised, and then I switched to generating unique passwords for every site.
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.
But what happens if one of those sites lose their user database? Your other accounts would be compromised and you would have to change your passwords in every site you registered with the same password.
That's the kind of worst-case scenario I can live with.
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.
They can also message your friends as if they were you. Scams and social engineering attacks do and have operated this way. If you or your friends are high-value targets, they or their interests can be seriously hurt by this sort of thing.
Which of the sites that you use your throwaway password for have friends and messaging?
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.
Uh... the specific examples given were comments on engaget and reddit. You think people don't talk to their friends on those sites? Yours is precisely the kind of thinking that leads people to fall for social engineering attacks. Clearly you're too smart for it to happen, right?
Correct. I don't think people talk to their friends on engadget or reddit. Why would anybody do that?
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.
This is why I always roll my eyes when people analyze passwords that have been exposed from consumer sites. Is it really meaningful that XYZ news/gaming site has 10% usage of the word 'password' as a password?
Yeah, my rule is to give a unique password to any site with my credit card or personal info, email addresses, and social networks that have my contacts (I've seen Facebook used in a scam before where the scammers pretend to be stuck in a foreign country and beg for cash from friends). Everyone else can just use the same password. If that means my reddit karma is in danger when YC gets cracked, so be it.
Is it not a pain when someone starts spamming as you on Reddit and Engadget? You have either go back through a third of the sites you've ever signed up for and change them, or just write them off. I think the latter is somewhat irresponsible.
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.
Yep, I use the exact same strategy as VonLipwig and recognize that many of my accounts could be compromised. However, without having a central email account compromised, the ability of attackers to find other sites or extract meaningful value from them is quite limited, IMO. In fact, I'm not sure that there is anything meaningful to be extracted outside of email / dropbox / bank accounts / lastpass / github.
And it's not always clear at the beginning which sites are going to become those "more important" ones...
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.)
You care about your identity and your tweets on Twitter. So, this is a sensitive account. It wasn't clear earlier whether you cared about your perlmonks.org identity so much. So, assuming the worst case scenario, this should have been considered a sensitive account as well.
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.
In my case, if the site becomes important to me, I change my password for that site. Except for certain sites, I don't make use of the browser remembering passwords feature.
My most secure passwords are for Twitter and Facebook. I don't really use either anymore but I don't want to delete them as they contain some history.
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 :)
I agree, there is cause for some to be concerned about a "reputation damaging" attack. For most of us, however, this would be an annoyance and mere blip in our social presence. Also, what I mentioned is that there is not much incentive for anyone else to spend a lot of time and effort damaging my reputation. What would they get out of it, especially if the perpetrator remained anonymous?
This is the point I am making. These sites do not matter. I have no attachment to them. I have no need to keep them secure.
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.
I was going to write a blog post about this, comparing one of those 3 passwords to the lock on your toolshed in your backyard.
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.
Personal information isn't the only thing worth protecting; some accounts would take a long time or even money to recreate if they were banned. Movies ranked on recommendation engines, games bought on Good Old Games, domains and hosting accounts from different companies, invite-only accounts, etc.
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.
+1 I try to reach a middle ground in terms of security vs convenience. I have 5 different passwords and I re-learn one at a time when I want to change them.
How's passwords an unsolved problem for any power-user? There's a ton of password management software out there that does /not/ require you to copy-paste passwords around†.
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=...?
keepasss is a better solution; it does the same auto-entry thing, but stages part of your password through the clipboard and part through direct keyboard entry. Works everywhere (even on mac and linux) and is far more usable.
Is there an import/export tool for Keepass Droid by any chance?
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.
Keepass2 also has a "synchronize" feature that can merge edits made in memory to a stored file on disk; just throw your keys into dropbox, and when you need to change anything just hit "synchronize with file" and it will merge your keys. Works great.
My passwords are all generated by mashing the keyboard, and are stored in a PGP encrypted file in my Dropbox. When I want to add a password to that file, I just edit it using Vim. Vim automatically handles decryption/encryption because I have the "vim.gnupg" plugin installed. When I want to know a password, I type "password foo", where foo is a substring of some identifier I've used, eg the domain name of the site. It searches my encrypted text file for a line containing that identifier, and selects the last string of non-space characters on that line as the password. It then displays the password, and also copies it into the clipboard. It waits for 10 seconds, and then overwrites the clipboard with it's previous value. My "password manager" is this tiny script: https://grepular.com/password.pl_txt
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's password generators (usually within most password managers). Far more better because even mashing the keyboard produces patterns. I bet some of your starting characters are on the left side of keyboard for example and you never use capitals or symbols.
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.
BrowserID (https://browserid.org/) does exactly that. Once implemented in a browser, it effectively turns authentication into a key exchange with the browser.
As far as I can see, it's not different from all the other solutions. When you logged in to Hacker News you had to notice that there are tons of already working alternatives out there. It's also one factor authentication and requires password. So why not to use OpenID, Google, Facebook? Because it's linked to browser, it's most probably possible to steal your identity. So it's not prefect solution either.
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.
I had to register my Apple ID. Apple's site disallows copying and pasting in the password field. I really REALLY hope this isn't a trend, because I use strong passwords for everything, and these 128-bit monsters will make your hands explode if you try to type them in manually.
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.
....what kind of crack are you smoking? Can I have some?
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.]
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).
I've often wondered to what extent my own password mnemonic "system" is either sufficiently secure or woefully misguided.
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?
Now the bad guy has to crack two sites which you register on. (Or just make you register on two of his sites). Bam, all your passwords are effectively 3-letters long.
This scheme is pretty common, so yes they would think of that. They might not try and figure out the alphabet position thing, since the password is laughably easy by now.
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.
I think you're being a bit alarmist, the most likely attack is that someone compromises one password and then logs into a higher value site with it. They can't do it in this case.
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.
Who cares about the list of sites you have accounts? Unless you're paying for goat sex porn, the site names themselves are utterly boring and useless. Attackers already know you have an account on Amazon because you are a human being living in the developed world in the 21st century.
1Password is apparently unusable without a required master password (as it should be), so failing to also protect the site list with it was a serious and lazy mistake. If you have nothing to hide, that only means you aren't doing anything controversial, which I regard as a personal failing.
If you can't imagine a scenario where this is a Bad Thing, you aren't that imaginative. "Who cares?" is almost never the correct response to a bug report, especially a security-related one.
? what's your point, so there's a file that it stores on your hard drive. That's obvious. The passwords in that file are still cyphertext encrypted with your master password. Using "strings" doesn't give you anything that you can use to log in.
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.
:O so much for the concept of a password vault. I had better security than this when I was manually decrypting/encrypting a .txt file with my passwords with AES256
Public key cryptography. I don't know if it's the simplest solution, but it does fix the problem. You have a private key, which you keep SUPER safe (e.g. encrypted with a strong passphrase), and you distribute your public key to anyone who wants to be able to verify your identity.
I'd really like a portable device / managed service I can carry around that encodes my biometrics in a private key. I don't know if fingerprints or iris scanning would cut it, though as you'd want something that would hash reliably.
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.
I use KeePass myself and because of its awesome auto-type/global hotkey I rarely need to go open it and look up credentials myself. Just add the windows' title to the auto-type list of the corresponding entry and you're off the hook.
> You know those SSL certificate warnings? You know how you always ignore them? Yeah, you shouldn't do that. They're the only warning you get that someone might have hijacked the connection to your bank or whatever. It's a shame that browsers have trained most of us to ignore the warnings, because they're the only thing making SSL useful.
It's not just browsers - here's an example of a budget web / email host telling users to ignore the warning:
> 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.
Keepass is cross platform. Not sure about iOS devices but I use it across windows, linux and my 2 android devices. Put the kbdx file in dropbox (you also have dropbox on all platforms), set keepass to autosave on every DB change, job done.
[i guess you are still keeping your passwords in the cloud if you keep it in dbox, but the password DB is encrypted).
Lots of fail here, but I'm surprised no-one has mentioned www.ironkey.com yet (I just did). I've been using one for a couple of years (admittedly mostly on Windowses) and was so impressed I bought a couple more for my partner, family members etc. The identity manager does a reasonably good job, and the two-factor authentication works well for Ebay / PayPal. I use the on-board browser, which I keep as my "secure" / trusted-sites-only browser (where trusted mostly means "can cause money to change hands") or the integration with IE for some banks. The only thing that doesn't work automatically is banks asking for random digits (from a 16+ character random string, yeah, thanks). For that I use the ability to store notes alongside account credentials in the identity manager. IronKey also provide a degree of device management on their website, which is maybe the obvious weak spot - the credentials and checks needed to log on to their site WITHOUT having the device. That sort of thing is maybe best written down and stored with a will in a lawyer's safe - it's a worst-case-scenario if you need it.
Ok, SSH agent is fantastic, but why it is not used to log to websites? Is it so complicated to paste my public key to some textarea during account creation at any website? What is the reason that no site is using this?
I did some googling and the part of copy/paste of public key to website is pretty obvious and could be useful maybe for some tech sites. At least many people can do copy/past of key very well, as you can see by trying to find all public/private keys at pastebin.com ...
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" :-(
There's no browser support, and it's too much of a hassle to do manually.
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.
Personally, I use Keepass over Dropbox. I have my latest passwords available on any device I use. So if my phone and my computer burns up in a fire, I can still access my passwords from anywhere I can securely log in to Dropbox and my safe. If anyone hacks Dropbox, they will still need my safe key. If I lose Internet access, I can still access all but the most recent password changes.
I wish banks in the United States started offering two factor authentication. If I want to log into my bank (Swiss bank) I input my card number, I then get a one time code from my bank, I insert my pin card into my card reader (not connected to the computer), I type in my pin number, I then type in the code I got from my bank. What I get back is another number that I then type into the browser field.
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.
I love how LastPass isn't the solution because ... "it's a computer program".
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?
Google Authenticator facilitates two-factor authentication. It's a very good complement, but it is not public-key authentication nor a replacement for passwords. SRP is probably the closest: http://srp.stanford.edu/
6 digits is indeed too easy to brute force as a password replacement (though it depends on the setting). I guess it could be used as a replacement for passwords if the keys were longer, longer sequences or maybe groups of words like S/KEY.
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?
It is a replacement to sending passwords over the wire. There are no viable replacements to passwords, which are really just secrets, memorized or not--short of issuing secure tokens or installing high-grade optical sensors in all laptops and getting all services on the Internet to add support for those authentication methods, anyway. This is why we're still using them.
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.
The approach I use is to combine a master password (so only one password to remember) with a site specific name (e.g. the domain name or site title) using some difficult to reverse combining / hashing algorithm.
This way, even if one password is leaked, it should be impossible (or at least very hard) to calculate the master password.
I completely and utterly loathe the security question-answer system. Has there been any study into how effective they are at improving security compared to, say, being forgotten and causing a complete annoyance? I've been unable to get access to fairly important accounts because I couldn't remember which answer I gave to a generic security question 4 years ago; I know full well that I gave a perfectly correct answer at the time, I just have no idea what it was.
Nice, I checked that out. It looks like you store the encrypted private key in session storage (i.e. a glorified cookie). My main concern would be how to back up that private key. As a technically savvy user, I shouldn't have a problem with that, but I'm not sure how a novice could manage while still keeping everything "Dead Simple". (I suppose a "backup to cloud" option could be arranged somehow.)
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.
Actually, the encrypted key is stored in localStorage, not sessionStorage. If you choose "keep me logged in" then the UNencrypted key is stored in sessionStorage (which automatically goes away when you close the window). There are no cookies involved (unless the site using DSSID for login gives you a session cookie).
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:
Yes, thanks for clarifying. I see that now. I've been through your demo a few times in Chromium, and I've been poking around and looking at the "Cookies and Other Data" values. So yes, I see now that my actual private key is in "Local Storage".
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.
DSSID has been tested in FF, Chrome, Safari and Opera. It doesn't depend on certificates, so deleting your root CA's shouldn't make a difference. Google "HTML5 local storage" for more info on localStorage and sessionStorage.
When I click "Login with DSSID", the page says nothing except "Welcome to DSSID". No login box, button, or anything. Of course, it's not your fault, because when I do a View Source, I see all those things. They just don't appear to me visually.
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.
Of course it's my fault :-) Failing silently is never acceptable under any circumstances.
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.
Using passwords as single factor of authentication is complicated, inefficient, insecure; and for corporations, they are also expensive because of all the calls to the helpdesk they generate.
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!
> "Speaking of usernames, i've run into more than one bank that requires a digit in your username. A digit. In. Your. Username."
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.
I do not consider a username to be a secret information. But even if it was secret, having complex username just make thing complicated. And when it is too complicated, your users tend not to use your service at all.
I started e-banking with UBS in Switzerland around 10 years ago (it's were I live) and they provided me with a card, and a little card reader with a key pad. To log in, I have to enter and 8 digit account code (not my account number though - something random but consistent). It then gives me a random code. I type my secret pin number into the card reader and enter the given code. It gives me back a response with number and letter characters (all capitol letters) that I enter into the web page to complete the log-in.
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.
One of my banks limits passwords to 12 characters. I asked a customer service representative why, her response was "because it's hard enough to remember 12".
He would have gotten his point across better if it wasn't presented as an expletive-filled "yeah? fuck you!" rant, which seems like the cool thing to do, these days.
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.
I loathe that you're being downvoted for this. My first desire after reading this was to share it with my co-workers. Unfortunately, the article's format as a profanity-laced rant makes it completely inappropriate for that purpose. It's a shame that he so effectively limited his audience.
As to the bank issue, I think they "fixed" that in Belgium. Logging in is still an annoyance, but I atleast feel pretty safe with it.
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.
This has been a problem for a long time - which is why companies like Microsoft and IBM have been spending time on technologies like CardSpace, ADFS, the identity meta system from Kim Cameron, IDEMIX and U-Prove, and other stuff that tries but fails like Microsoft Live (erstwhile Passport), OpenID, and OAuth.
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.
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.
Hi there, I think password is working perfect. And we just need to figure out a way to remember all passwords into our brain in a unforgettable way.
Here is what I do:
Password for xxx:
First GF's birthday(yymmdd)+favorite city(2 letters, first letter CAP)+ high school student no.+last 3 letters of my all time favorite movie
this would result: 760925Lu201228can
And you can store the statement in your gmail. Only you will know the answer. Then you don't forget!
Also I have 3 level passwords.
High Medium Whatever
High: I will think of a password as I demonstrated above (at least 4 questions).
Medium: I will think of a password for just 2 questions.
Whatever: would be a stupid password but for accounts I don't care if it's hacked(stack overflow, github..etc)
Among all tools, maybe it's better to write your password and put in your pillow. and forget all the technical stuff.
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.
I use the PwdHash extension. It works great. You type the same password into every box; it in encrypts it using the domain name of the current web page as the key.
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.
I also use PwdHash. I don't know nay of my passwords by heart and also use the same seed password for everything. Whats great is you can use the extension for chrome or FF, theres a free iphone app and theres always pwdhash.com if you need a password.
I'm by no mean an expert in passwords/cyrpto and the like but it sounds to me that his idea of generating passwords from the service name and a master password is a good bad idea.
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.
You've still got to do it right. If I phish your twitter account and discover your password is "twitter-iloveyoujane", you can bet I'm going to see if "facebook-iloveyoujane" will get me into your facebook account...
And I'd be astounded if there weren't already automated tools that do this for every website in the alexa top 1000...
I'm not sure it's worth all the trouble to go out of the way and adopt a complicated password generation scheme. As long as your password isn't qwery, an attacker brute forcing it seems very unlikely for any competently implemented web app: most block you after n incorrect tries and sending HTTPS POST requests seem really slow. Dictionary attacks on the password hash is another problem, but salting the password should handle this problem.
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.
It's a shame that browser-based authentication mechanisms such as HTTP Digest/Basic Auth and Client certificates are so broken and underdeveloped. HTML5 has everything and a kitchen sink, but neglects to address this major shortcoming.
While the author has a point when users reuse their password for many accounts, he ignores the time required to test a password when using bruteforce attacks. The rant on banking passwords with strongly limiting constrains may be (is?) balanced by the time to test each password. The password could be reduced to a few numbers if it is assigned randomly by the bank and can't be changed by the user, and if something like a paying phone call is required to reset the password after three failed attemps. Make the password a serie of logos to click in a specific ordre and displayed randomly, and keyloggers become history.
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?
> ... password managers like LastPass ..., but let's think about this for a moment. I have the choice of either making my passwords so memorable and reused that i'm at a grave security risk, or of making them so secure that i need a computer program to store them for me. This is fucked up. This is fucking broken. This should not be allowed to go on.
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.
I remember reading an article about complex passwords vs what was basically called "offensive gibberish", I've actually taken a liking to this approach more recently than relying on a password manager. The whole goal is to make your password memorable while also making it long and complex enough to avoid cracking/brute forcing.
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.
I was very pleasantly surprised by the security question system used by Ally Bank recently. They let you enter your own security question.
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.
I know of a couple of websites that do this and the problem now is that I used the same question on multiple sites. I guess I could come up with a new one each time but that does actually take a bit of creativity..
Oh shit. Just yesterday I've ran into precisely same problem: I've tried to change all my passwords online into something like service_password_date. I decided to do this after googling my four favorite password md5 hashes (abc123, cba321, etc). It was there :)
So yea, only several services would allow to have password longer than 15 characters, and several even wouldn't allow to use anything else than numbers and letters. I was shocked. Skype won't even let you use their name in password, how's that fucked up...
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.
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.
Well, in general, I'd suggest something related to the service rather than the service itself. Computer algorithms generally aren't intuitive in the same way computers are.
Paypal -> $pr3f1x29# elh oh el I liek money u gieve
Steve Gibson calls this concept the "password haystack". The idea is that the clever hacker will do something like the following:
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".
> we're talking about "how to make really good passwords". I feel like this has been answered
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.
You could implement your own dictionary (in ELvish!) if you wanted. But, I just make them up. You can re-use the prefix as it's only purpose is to screw up "whole word" algorithms.
I've been using PassPack for a few years. It allows you to generate random passwords with your choice of # of characters and type. My default setting is 14 chars of a-z, A-Z, 0-9 and punctuation. Then if the site complains I scale back, no punctuation, less chars, etc.
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.
I've posted about SHA1_Pass here on HN before, but thought it relevant to this thread, so here it is again: http://16s.us/sha1_pass/
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."
For secure passwords, I strongly recommend the Password Hasher extension ( https://addons.mozilla.org/en-US/firefox/addon/password-hash... ), which allows you to use a different hash-based password for every site. It also allows different password lengths.
I generate different, easy to remember passwords for every site by using a random looking base string and slapping in a few characters derived from the domain. For example you could take the first and last letter of 'ycombinator' and use 'ut' as your changing characters (the letters to the right of 'yr' on the keyboard.)
Passwords are not ideal, but they seem to be the best compromise available. An alternative might be for everyone to carry around a USB dongle containing a private key, along with physical keys. There's always some tradeoff between security and convenience.
We've GOT to get public key cryptography in the hands of the masses. My current favorite strategy is to get them all using some distributed social network that uses PK and also integrates with everything, but I don't know how feasible it is.
been preaching the same since.. 1997?
When SRP came along, we though that tied to proper keychains we'd see the light at the end of the tunnel. but nope.
too many "pros" are too tied to die hard password auth ;-)
Your use of the phrase "even if" makes me think that you are saying that loading a form on a non-https page would be secure when that is emphatically not the case at all.
I know that http served https form target login is an anti-pattern.
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.
Fuck passwords is right! After having one of my re-usable passwords compromised through Mt. Gox's breach and (a small amount of) my bitcoins stolen from a different site, I have learned my lesson (BTW, the correct term for this type of event I think should be "I got Mt. Goxed.")
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.
At least partially because Chrome's extentions are just bits of JavaScript. For example the FF version throws up a dialog box when you want to log in. On Chrome it shows you a new tab that is mostly empty. Just feels less integrated I guess.
I like this guy's article and it makes good points. But dropping the capitalization of the pronoun "I" half way through a formal article that one publishes for a general readership looks really bad.
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.