This is surprising to me. I'm INUNDATED with Homejoy ads all over the internet. I've never used them (which also might have been part of their problem). Perhaps you just live somewhere they don't provide service to yet? :)
I had heard of them but with most companies that spring up then wind down a little later they never expanded to where I live. I would have loved to try them though.
He never 'got a lawsuit.' Instead, he got some comments from the contact to whom he reported it that criticized his approach. It's not even clear just who this person was. It seems he had trouble locating a contact to report security issues to, so this may as well have just been a low level support rep who was in over his head and saying things he shouldn't have.
"The hardest part - responsible disclosure. Support guy honestly answered there’s absolutely no way to get in touch with technical department and he’s sorry I feel this way. Emailing InformationSecurityServices@starbucks.com on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.
> So far as I know (this is sort of my profession), there's no federal "burglars tools" law regarding malware.
To be fair, many "burglars tools" laws require possession of the tools WITH INTENT to perform a criminal action. The intent piece is key. Merely possessing lock picks is usually fine. But sulking around masked in bushes outside an office building with a pickset, rope, and an empty duffel bag might get you in trouble.
A good list of Lockpick laws collected and indexed state-by-state at http://toool.us/laws.html. You see that in most jurisdictions intent is required.
While malware laws are still much less mature, I would hope that similarly there'd be an intent requirement. Possessing malware for purposes of reverse engineering to develop protections is obviously important, and clearly an activity we would want to remain lawful (and hopefully unlicensed/regulated).
Conspiracy is probably the easier route to a conviction.
I get why they can't provide details. But a close read of that incident report doesn't answer whether they even know how it happened. Did I miss something?
With these types of incidents, you want to make sure you have the facts before you make claims. They are probably doing tons of investigation to figure out what actually happened. This could be difficult depending on the level of sophistication of the attackers.
If LastPass says "Attackers took everything" when the attackers only took a few non-identifiable pieces of info; it will be a huge non-recoverable media event about attackers taking everything even if it's not true.
If LastPass say "Attackers didn't do anything" but stole a lot of sensitive info, then it makes LastPass look incompetent.
This is really a situation where they need to understand the scope of the situation before making a detailed comment.
I would also appreciate more detail, but that shouldn't be their first priority.
They note that they discovered the breach on 'Friday' so I imagine they have an ongoing Incident Response right now. They may not have or be ready to share this information at this time, and that's fine. They might be working with law enforcement, further hardening systems, and continuing to confirm their findings to date to ensure they've mitigated the full impacts.
What's important now is conveying how users are impacted and what steps they should take to protect themselves; hopefully the rest comes in time.
Another pain point is the delay from Friday's discovery to Monday's disclosure. While it's better than the sometimes weeks other companies have taken, it screams of the discovery happening at 4pm on a Friday, and everybody then saying "bah fuck it, go home for the weekend, we'll work on it Monday". A security compromise like this should have been made known by Saturday at the latest, and worked on over the weekend. 3 days is a long time for leaked passwords to go unnoticed to users, regardless of the encryption scheme being used.
While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk.
If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one.
Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which you have no control seems inherently risky. Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database. Use a password manager, please, but keep it offline and don't aggregate it with loads of other people's databases.
This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.
But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it.
I agree with you that an offline password manager is better in theory. But the problem is that I am aware of no such service that is easy to use across numerous devices, so much so that none has struck me as a viable option given my patterns of usage. Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.
So the choice once more, for me, becomes cloud-based password manager or no password manager at all.
(Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
My compromise has been to come up with a password permutation scheme-- I have a long, secure, high-entropy password which I can modify/salt in a way that's predictable (to me) across sites, such that each site's credentials are unique. Obviously this works across all devices, because the scheme is in my head, and it's simple enough to remember. I don't use any password manager, because like OP, that seems like too much of an eggs-and-baskets risk for my taste.
A catastrophic compromise would require an attacker to see actual credentials (not just the hashes) across many sites, and on top of that reverse engineer my specific permutation scheme. This seems much less likely to me than a very public, high-profile centralized cloud service forgetting to cross a T somewhere and getting hacked.
Just how long have you kept this up? When I gave it a go, the sites which didn't accept the base+permutation approach stacked up quickly. Some mandated a length which was too short, some mandated a length which was too long, some required certain special characters, others forbade the same, some required multiple separate passwords (i.e. security questions or pins), some just gave me a password and didn't let me change it (i.e. a serial number), some mandated that I change the password regularly, etc, etc. Trivial modifications were an unsustainable approach. I gave up within a month when I realized that my "exceptions" file was essentially identical to a password database but with poorer compartmentalization against the most likely threats.
Besides, a simple permutation scheme does not provide good protection if the base password is leaked which is what happens half the time anyway.
I've found a length of password that covers probably 85-90 percent of my accounts, and is a good tradeoff between security and portability. Most sites accept special characters, and the ones that don't also tend to be the same ones that have retarded length restrictions. Ironically these tend to be banks, who should know better!
The small subset of sites that don't fit into the scheme get one from a pool of fixed passwords that I just remember-- so if I forget, I just try from the pool until I get in. Or reset, but that happens rarely enough that it's no big deal.
IMO there should be federal regulation about password handling which would render that problem moot: There should be no length restriction, no special character restriction, no storage in plaintext, and mandatory salting. It's arguably a national security issue.
I'd guess that a lot of those sites permit password reset via email verification, in which case a lot of your eggs are in one basket anyway. In fact, considering that SMTP is even less robust versus encryption downgrade attacks than HTTP, while also providing a patient target for DNS poisoning, this oft-forgotten basket is pretty fragile.
It'd be nice if those sites recognized that that security arrangement is massively improved with OpenID, which can piggyback on the authenticator's two factor scheme, server hardening, and whatnot.
I don't actually see the scenario where this becomes a problem.
If foo.com is compromised and their passwords decrypted, I find it unlikely that the attackers are going figure out your password scheme, go over to bar.com, and start trying out usernames that are similar to yours with the password scheme they think you have, while they are in possession of all the other foo.com passwords and usernames, some of whom probably have the exact same username and password on bar.com.
I've been using basically hunter2_foo for all unimportant passwords for some time and never had a problem.
The only thing I can think of is that if one person was on a mission to destroy my life and they managed to compromise a couple passwords to figure out the scheme, but I don't see that happening in a way that would not allow them to vacuum up a good number of passwords anyway.
He never said it was. It could be something like <Base Password><Third letter of URL><Fifth letter of slogan> etc.
Just because it's predictable to him does not mean it's predictable to all. There are ways of keeping predictability while still obscuring it from everyone else.
The goal of security is to make defeating the system too difficult to be worth it.
As such I'm not advocating security by obscurity, just security by "making the job of defeating all my accounts sufficiently involved to exclude me from a en-masse attack"; by far the biggest risk for cloud accounts.
Yeah that would be nice. I actually think browsers should have this as a feature.
But the problem is that not all websites accept long passwords. My bank wouldn't take longer than 8 characters and doesn't even have a second factor auth.
Office 365 wouldn't accept more than 16 characters. I think it was Paypal who wouldn't take more than 10.
Banks also lock the accounts after 3 failed attempts though. The short passwords are to avoid having to deal with phone calls that go something like, "Hello, I forgot my password."
> The problem with using any standard algorithm like that is that the algorithm becomes your password.
That's not true at all. The press released linked in this thread, for example, is very open that they use 100,000 rounds of PBKDF2-SHA256 to encrypt their passwords. That's a very standard algorithm. The security it provides is not its obscurity, but rather that the only way to check against an output hash is the naive brute force method which takes a long time - impractically long for attackers to try to brute force.
Nobody's saying the scheme is perfect, the claim is that it compares well to a centralized password service.
In the situation where someone uses the GP's scheme, to get multiple cleartext passwords attackers have to bypass security on multiple networks to obtain the databases and spend significant computation time reversing hashed passwords. And they have to do it in a time window in which the user hasn't changed their base password or hash.
For a centralized password service, the attacker has to do... pretty the same things, but for only one service! I'd also imagine the situation with regards to cleartext recovery might even be a little easier given that the passwords contained in that database have to be encrypted in a recoverable manner rather than merely hashed. And time window isn't an issue; recovery is going to be simultaneous.
Oh, and in first situation, the attacker still has some limited added security through whatever obscurity their site-specific hashing function brings to the table. If it's something one can do in their head, it's probably not anything that can deflect a clever/determined attacker that got to this point, but it's something.
The flaw in your scheme lies in the fact that "it's simple enough to remember" ... this would imply that if one were to target you they could likely correlate your credentials across multiple leaked PW databases and guess at your scheme. That of coarse has plenty of assumptions...
Yes, a motivated attacker could figure it out. But before they could do so, they would need my password in plaintext for multiple unrelated accounts of mine, which is hard, requires the attacker to target me specifically, and by that point what is lastpass really going to do for me anyway?
By far the most likely way my gmail account would be hacked is that foo.com's database is leaked/cracked, and the hackers spam the credentials for foo.com at hundreds of other sites and see what sticks. My scheme defeats that. And it's one point of failure versus several.
Depends how simple. Obviously "add the domain name to the end of the password" is too simple. But there are other ideas that are equally easy to remember or regenerate.
On the other hand, in the even of your untimely demise, your friends/family may end up in a bit of a pickle without access to some of your accounts. Granted, this is of less concern if you're single and without kids.
I use the same scheme but on top of it I hash it so even if site saves my password in plain text, it doesn't reveal my scheme.
I use a portion of hash for sites which have maxlength constraint otherwise full hash.
1Password can sync your passwords through WiFi [1] without going through some cloud service like Dropbox. This is the main reason I use 1Password, and it so far has met my needs. Caveat is apparently it can only sync with a single computer.
Unfortunately I can't use 1Password at work because it doesn't have a browser client, and I can't install anything I like on my computer (corporate). Sticking to Dashlane for now.
Technically, a 1Password vault contains a "1Password.html" file that essentially loads up a browser interface to your vault. This may or may not meet your needs, depending mostly on whether or not you're cool with carrying around a thumb drive with your password vault on it.
> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
I don't know if it meets but your needs, but I love PasswordMaker (http://passwordmaker.org). There is no need for sync'ing, because the password is generated from a master password and configureable per-site data (by default, the web-site address; but you can add more data sources if you don't like that). It has an extension for Firefox that auto-completes passwords (configureably, remembering the master password per session so that you don't ever have to type it); there are widgets for Windows and Mac OS; there are Android and iOS apps; and, always, there is the fallback web page, which you can use anywhere that you have a web browser.
EDIT: Since I am trying to indulge in quite a bit of advocacy here, I want to make it clear that I am in no way affiliated with the project. I just stumbled on it a long time ago, and have been delighted with the way that it fills my needs.
I tried to use something similar a long time ago (SuperGenPass). The problem I had with it was that often times the password would not meet the password requirements of the site. Sometimes it's too long, sometimes there weren't enough numbers or symbols. I couldn't use it if I'd have to remember that it didn't work for particular sites (after all, the whole point is not having to remember information for each site). How does passwordmaker fair with that issue?
PasswordMaker allows you to tune the length and character set. You have to remember your site's password requirements, which is not so easy to do (usually they are only made available when you try, and fail, to change your password; in particular, only when you are logged in); but, in practice, I've found that using the default settings, and then using restricted settings (shorter length and A-Za-z0-9 character set) if that fails, works on every site I've ever used. This means that, if you are willing to endure the occasional inconvenience of having to re-enter a password, you don't have to remember anything per-site.
I hate any website that imposes a specific password format on me. I have a fondness for vaguely pronounceable passwords and I tend to use all-lower case for anything I have to enter on a mobile device.
So - reject my 16-character all-lower case password because there's no numbers or punctuation in it and you know better than me? Grrrrrrrrr.
That means one compromised password - your master password - compromises all your sites. That's the kind of risk I can't stomach.
LastPass is a huge target, yes - but (if we trust them) the data is only decrypted client side, so they have no access to it. Which means the only viable exploit is in the lastpass browser extension.
This is one of the things that scares me. If an attacker had access to dump their credential digests, could they also have modified the site to silently log credentials upon entry?
From their statements so far, it doesn't seem that happened, but it seems likely that it could.
It's a whole different cup of tea though, this compromise required the attacker(s) to go in, download data and get out. Your scenario would also require the attacker to have changed their site and go unnoticed for any significant amount of time.
If that was the case I'm sure Lastpass would've found out and reported as such.
> That means one compromised password - your master password - compromises all your sites.
I agree, but it's hard to see how it could be compromised, since it is never entered anywhere public-facing. You can, but need not, have the Firefox extension store it, but only in memory. It is also possible to use the PasswordMaker website (once loaded) without an Internet connection, in case you are worried about it leaking data.
I wrote WebPass ( http://webpass.rkeene.org/ ) for a similar reason. It's extensible with domains having password requirements and does syncing (of parameters for passwords, never actual passwords -- since they are generated). The UI is bare, but it's open source (and aside from the syncing, done entirely client side).
The sync'ing is done with a FIFO, two clients connect with the same key and they each get what the other one POST'd, no data is logged on my side.
Not only do I see this issue groby_b rasies as a huge one but I'm not sure how this is supposed to work for sites that have various password requirements. Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.
> Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.
> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.
Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.
I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.
For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.
> So the choice once more, for me, becomes cloud-based password manager or no password manager at all.
If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.
> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.
I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.
> For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.
You also don't need to use one solution for every use-case. I use an online password manager (LastPass + 2FA) for relatively high-use, low-value credentials (things like web forums and online shopping sites). For higher-value credentials (investment accounts, banking, email), I use an offline password manager on trusted machines and site-specific 2FA when available.
That's been a good trade off between convenience and security for me.
Seconding multiple solutions. I use LastPass to deal with the volume of credentials required, storing most but not all sites. I memorize the most important sites (bank, primary e-mail), never putting them in a password manager.
A solution I have found that (I think) is relatively secure. Setup a keepass database that requires the use of an unlock password and key file. Sync the database to Google Drive but never sync the key file! Only store the keyfile on a locally ecrypted thumb drive or only stored locally on the devices (preferably encrypted) that you need to access keepass from.
In random time/day intervals reset your key file and keepass password.
The key to this method "working" which should be "secure" barring total ownage by a state actor or well funded individual is to never sync the key file and database to the same service. Additionally, sync up a "false flag" key file if you want some additional level of obscurity.
tl;dr:
1) Setup Keepass database to require password and key file to unlock.
2) Sync database to cloud service but never the key file.
3) In random time intervals (t=60+days) Randomly change both the password and generate a new key file for your database.
4) Keep your key file on an encrypted drive or on the device (preferably encrypted) that needs access to Keepass.
I'm concerned (but not qualified to judge) that changing your password and keyfile may not be as beneficial as it appears.
A password for an encryption key is very different to a password for a server. Once you change your password on a server, there's little harm in publishing it -- it can't be used any more. But the key is a file that may still exist (see also Wikileaks' key being published by David Leigh).
Consider: your database exists as a file. If someone is able to gain access to a copy, that copy remains valid as long as at least one password within it remains unchanged. So you need a strong key, because it's subject to offline bruteforcing. Now they get a second copy of your database, with a different password. If any of your passwords are ever published or cracked, your database is exposed. If you have to change your password regularly, it's going to be tempting to make it weaker, or to store it somewhere less securely. If you're using key files, they only need to get one of your files. It seems to me that the more key material you need to secure, the more difficult it's going to be?
The key it seems to me is by using both a master password and a key file. If a site gets cracked and they find your site specific password that won't help them determine your keepass database master password &/or generated key file that you only store offline and never sync to the cloud.
In order to open the database you need both the correct master password and the correct keyfile. If the attacker doesn't have both, they should not be able to get into the database.
I'm also no qualified to judge, but I would say it's important that in addition to rotating the password and key file used to encrypt the password database, one also rotates the all the passwords in the database regularly. This way, if someone obtains a copy of your database, they have a limited time before all the passwords in the database become useless.
I do something very similar to this, but I sync the key file to a second service (both services have 2FA logins). Keeping it off "the cloud" entirely is indeed safer from a security perspective, but think about how many copies of your key file you have, and what would have to happen to destroy all of them. If you've just got the key file locally on e.g. your laptop and maybe a smartphone, it doesn't take much more than a petty theft to cause you to lose access to every service in the database (in which situation of course you'd paradoxically want access to those services right away!).
> I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.
That makes sense. What would be really nice -- and what I had in mind -- would be some sort of device where the passwords were stored to which my other devices could easily connect to to access the passwords, sort of like a wireless dongle. (Though, really, even the wireless part is negotiable. I'd be happy to plug something in as well so long as it was easy to carry with me and supported the right connectors.)
Seems like a Kickstarter campaign waiting to happen.
If you're using a reasonably trustworthy password manager with a strong master password, your biggest risk is data loss, not mass password compromise. Syncing to multiple devices and cloud backups dramatically reduce that risk while only marginally increasing that of compromise.
I'd make it so that under some very specific and hard to attack circumstances, it would be possible to make a backup of the keyring stored on a device.
Possibly only directly to another device, or maybe dump an encrypted blob to file or straight to paper (bitcoin printable wallet style).
That creates the risk of someone duplicating your thing, but you could have a 'number of times/date of most recent backup' entry obvious in your token UI, and hope people notice abnormal ones.
Protecting from a Chris Tarnovsky[1] level attacker who is probing your silicon is probably beyond the scope of a cheap consumer unit.
The best way I (IANACryptographer) can immediately think of is that your hardware dongle generates an very large internal (never leaves the device) pgp keypair. It can be allowed to back up your internal password database only when encrypted by that key, so it is literally useless except on that single physical device. You could then enroll the pubkeys of your other devices as backups onto it, and the backups would then be multisigned where any one of the associated keys has the ability to decrypt.
The password blob can then be stored jsut about anywhere, but is only decryptable and useable when embedded into the hardware device.
http://finalkey.net/ looks like a step in teh right direction, although I'd prefer to see something a bit more compact, and ideally with an independent user interface.
Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.
There was a hardware bitcoin wallet not that long ago that was further down this road, I think maybe https://www.bitcointrezor.com/ ?
The biggest problems I can see for usability are:
* what can you do when you don't have it with you? - One answer would be some printable one-time tokens such as the fallback that google auth uses, that you can carry separately.
* Can it be backed up? In theory, the keys are in there permanently, and cannot be accessed by design. Having some Super Mega Master Password that allows a full copy to be made onto a second device that can be kept elsewhere might be sufficient.
* How to handle situations where you can't use USB/NFC for it to communicate. It would need a display to give you a code/your password to enter or something.
A smaller issue would be if you're planning on fully interoperating by generating and storing individual site/system credentials on there, it would have to handle the idiocies of various systems that impose password restrictions like special chars, numbers, maximum length, etc. If it's autotyping as a fake keyboard, would also need to deal with the 'retype your password' field somehow.
All in all, I think it's totally doable, but I'm not sure I'd trust a kickstarter-like project to get the details right, given the general (maybe just perceived) level competence of kickstarted projects. Crypto Is Hard. You can't really start having a 'stretch goal $10M - hire a real cryptographer to check we didn't twiddle our nonces' or something.
A decent and well-reviewed thing like this is probably somethign I'd buy though. I've just got a Yubikey to play around with, and need to start setting that up for SSH and other keys to my more important accounts.
> Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.
Interesting. I had seen that a while back I think, but totally forgot when writing my comment just now. It's not quite 100% what I was thinking, but it's closer than anything else.
U2f (Universal 2nd Factor) is a standard to have a 2nd factor authentication usb device that uses a different secret for each website/resource. The only problem is that a version 2.0 is being discussed and you can't be sure that today's hardware will work with it.
1. Think of a 'stock phrase' that is simple for me to remember but likely to be unique, such as "angry dogs never jump for joy".
2. Write a simple program to generate 4 words at random, so it might generate "led show joke via" or "dean rock ranch ocean".
3. Generate a password by concatenating first letters of the stock phrase, the first two letters of the site name and the 4 random words. So the password for foo.com would be "adnjfjfo led show joke via" and the password for bar.com would be "adnjfjba dean rock ranch ocean".
4. As I generate the password I write down the site name and the 4 random words on a piece of paper which I keep in my wallet. So in our example I would write the following on the piece of paper: "foo.com=led show joke via; bar.com=dean rock ranch ocean"
The approach is very secure because the owner of foo.com would have no way to discover my password for bar.com. And a thief who steals my wallet will not be able to access either site.
Here's what I have found after several years of using this system:
A) After a few months of use I often find myself memorising the 4 random words for the more commonly used sites, so I often don't need to refer to the piece of paper in my wallet when logging in.
B) Many sites limit the length of the password - in these cases I generate 6 random characters in Step 3 instead of 4 random words.
C) For sites where security is not so important I skip the four random words. So my password for foo.com would be "adnjfjfo"; for bar.com it would be "adnjfjba". This avoids me having to use the paper in my wallet, but still ensures that the password for each site is distinct.
I do something similar in concept. I start off with a base password with numbers, letters, and symbols (to fit most website requirements). Then, I generate 2 random words based on the website name (based on the syllables). For instance, Gmail -> GM -> Green Mollusk or Amazon -> AM -> Aromatic Mitten. I find that it helps with remembering them naturally since the random words form a mnemonic on their own. The solution space is still large enough that knowing the rule should still be secure in real-world applications.
The difference is that a password manager must be able to decrypt a password in order for it to be used, while ideally websites only store one-way hashed passwords which if stolen aren't always useful at gaining access to other sites.
Sure, it's not free but well worth it to me in this case. I also chose not to sync using Dropbox but wifi sync and BTsync instead. So, no copy ends up in the cloud but cross-platform passwords with mostly minimal pain.
This reinforces the general problem that strings of characters are bad candidates for authentication. Users generally fit into two categories: those who will use the same password for everything, and those who won't. The latter half is the more technically savvy - which means they were likely to take the appropriate steps, read the appropriate news, and protect themselves against most classes of attacks. In short: the people who are likely the most vulnerable are also the ones that are least equipped to do anything about it.
It's a general problem with username/passwords as authentication and I think this is an interesting space for new start ups and service providers. Even with standards like FIDO, companies will want to be able to integrate it easily into their systems. The faster we can just kill passwords, the better.
>> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
I'd like to chime in with another suggestion for a storage solution that I haven't seen mentioned yet: syncthing ( https://syncthing.net/ ) makes for a very good alternative to Dropbox, letting you synchronize your data across your devices but without relying on a third party service to do so. I use it to sync my KeepassX database across Linux, Windows and Android devices.
Disclaimer: I'm not affiliated in any way with syncthing, I'm just a happy user.
I use a password manager along with Syncthing[0] which seems to be the compromise you are looking for. This setup works well as long as your devices are decently often on a wifi that allows local device discovery (since syncthing needs either that or static IPs) and it also keeps your password vault offline (i.e no cloud involved).
I dunno, I did. I used the same password everywhere, and then I got a password manager and started generating passwords. Granted, it may have been the case that it was my desire for stronger passwords that drove me to use a password manager, and not vice versa. I honestly don't remember.
> But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it.
Correct me if I'm wrong, I read this as if you're equating hacking a frequented website (and password) as hijacking a % of someone's accounts, if they use the pw there.
Random websites don't know about the other accounts you own, let alone the user ID and password them (if that same pw cracked is workable on the other service).
LastPass, or any cloud password service, has to store the relation between the service, your username for it, along with the password. That is global ownage.
Find my password on some irrelevant site, you may not even be able to link it back to me. If so, that doesn't mean you know which services I'm signed up to, let alone my user ID or password.
You understand that all the passwords/data are encrypted client side and only the encrypted blob is stored in the cloud?
This is exactly what users of Keepass et al espouse when they talk of having their 'locally encrypted database' and syncing it over dropbox etc.
You, at least, are identifying the benefit of physical security, but if we are to place any trust at all in encryption then we must accept such a scheme (local encryption, cloud sync) as being robust, if correctly implemented.
Under this scheme, obtaining the encrypted blob (which hasn't happened in this case) would still not be a cause for alarm, if we are to trust the strength of the encryption scheme.
There comes a point that you must trust 'something'. That choice for me is in encryption.
yeah... the synchronization for these services should be zero-knowledge. though maybe not the best idea, my vault should remain secure even if available publicly, right?
sync is a must have feature for many, myself included.
Encryption is as good as it's independent proofs. Even then, the proofs are only as good as the attention it gets from qualified, quality cryptographers. And again, only when used in a library that can independently prove it's algorithm and implementation is sound - open source.
You're stating truisms really. And you trust OTP (quite rightly) - ergo you trust encryption. My personal trust point is properly implemented AES-256 with a slow hashing function.
Correct. I wanted to qualify that you can't just 'trust encryption'. You must know what you're trusting, top to bottom; otherwise I would say that the trust is misplaced.
high (email, banking): Just memorize a unique password for each
medium (sites that might have my credit card info): Lastpass + salt, which I memorize and manually insert (last pass doesn't have it)
low (everything else, e.g. hacker news): I trust lastpass (w/ 2f) for these sites.
I feel that this strikes a good balance between security and convenience for me, without putting too much trust in the central store. I don't think LastPass is the weak point in this system (I am).
Super interesting to hear I'm not alone. I'm finding it works extraordinarily well, and even in situations where my Lastpass details are compromised (like today), it's not necessarily a disaster, just an inconvenience. But in return, almost complete peace of mind and liberation from passwords.
I understand your take on the problem, but one of the features of those services is that they are precisely online: I can get my passwords on my phone, tablet, desktop, laptop, abroad or at work. If my password manager is offline, it's safer, but it's also a poorer experience.
Maybe if there was a way to deploy our own personal password manager server on a dedicated server that would help the "one big target" issue.
You could roll out your own. But I personally trust the specialized team at Lastpass to monitor and look for these sorts of breaches a lot more than I trust myself.
That coupled with convenience makes it so I'm going to stick with an online password manager.
Even under a worst case scenario, I could change my major passwords fast enough with lastpass that I wouldn't be worried about loosing my online presence to anyone. It'd be a pain, but I'm confident that the LastPass team would keep me informed if that was necessary.
If you are using "off the shelf" software, then that means i have something to scan for, and a vulnerability in the software means that i have tons of targets. Most of which won't be as secure as LastPass servers might be, and probably won't update immediately.
Only if the software itself has a vulnerability - and it isn't that hard to secure a website or server that can't be accessed at all without a password, as opposed to one that needs to provide some level of service to anyone. Centralized services are also at risk of generic attacks such as convincing the hosting service/domain registrar/a company employee/etc. that you're authorized to change things, while pulling this off for many independently hosted site instances is considerably more difficult.
I think if lastpass just allowed use of an out-of-channel external file as an additional encryption layer (as keepass can) then you should be able to worry about keeping that external file secure rather than worry about what's in the cloud.
STRIP (https://www.zetetic.net/strip/) is a mature offline password manager that has been around since the late 1990s, available on iOS, Android, Windows and OSX. It uses the open-source encryption extension to SQLite, https://github.com/sqlcipher/sqlcipher, developed by the same company.
STRIP supports mobile-desktop synchronization over local wifi or remote cloud (Dropbox & Gdrive).
"When initialized with a passphrase SQLCipher derives the key data using PBKDF2 (e.g. OpenSSL’s PKCS5_PBKDF2_HMAC_SHA1 on some platforms.) Each database is initialized with a unique random salt in the first 16 bytes of the file. This salt is used for key derivation and it ensures that even if two databases are created using the same password, they will not have the same encryption key."
The LastPass database is encrypted client side too. Only the encrypted blob is synced to the cloud. Are people under the impression the passwords are stored up in the cloud in a for accessible to LastPass or otherwise unencrypted?
Only if you want to use that approach for syncing; you can also sync strip with local files, then delegating cross-device accessibility to network share, btsync, or something else.
Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database.
Couldn't you frame that same basic belief around any large 'nearly-monolithic' web service, like Google, Apple, or Facebook?
I agree, passwords are a risky business (you're storing security tokens for other people for chrisakes), but the power that access to someones Facebook or Google account is pretty equivalent - people run their worlds on those services.
By the way, I happen to agree with your stance. We rely on singular entities far too much on the net.
Yes, and I'd consider Google, Apple, and Facebook huge targets with major compromise risk as well. People tell me Google security is absolutely without equal, but when it's hacked, I, for one, will be unsurprised.
With cloud services hacks, there is no "if"s, only "when"s.
>This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.
I wish this was true, in fact with at least 3 devices I use daily, having an offline password manager means I need to type in manually "difficult" passwords on 2 (n-1) devices (at least that's assuming how password managers and username-password auth work today). Call me lazy but that's already above threshold for me, I'd rather use same password everywhere than do that. Am I missing something?
I've taken to using Keepass which is an encrypted, open source offline password manager, plus Dropbox for sync between all of my devices. While I can't control the security of Dropbox, I can at least control the level of encryption on my Keepass database. Keypass lets you use a "key file" (in addition or instead of a password) which you could copy to each of your devices once, which would make for a very secure password database at-rest.
It's still not perfect but I think it's a better than LastPass or 1Password. And if you have a more secure file sync (maybe AeroFS?) you could use that instead.
You can also use another encryption mechanism like GPG or something akin to TrueCrypt's (not sure how people feel about using TrueCrypt 7.1a these days) encrypted hidden containers to hold your KeePass database on your cloud storage, which itself would also be encrypted and need a key file.
This way you have three or four separate, strong barriers of entry to your KeePass database.
Not sure I'm with you on the "responding well" part. Why blog about it before even notifying your customers? And Joe's whole post seems fairly low-key given that this was a security breach and security is their entire business.
In the comments, they indicate that they're in the process of sending out emails to users. Sending lots of emails takes some amount of time; hopefully those are arriving in inboxes now.
It's low key given the impacts as they understand them now, but seems reasonable unless there's more to it than it currently known. We'll see how things develop in the coming days - just being forthcoming days after it was detected and providing guidance on how to respond is commendable though.
I use Keepassx and the only thing I use the cloud for is to store the password file which is encrypted by either a pass phrase or key file. LastPass always struck me as a dumb thing to use.
The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised.
Great so maybe you can't attack the stolen hashes (at least not all of them) but you can use this information for social engineering which narrows things down.
In my case, you'd have to break into SpiderOak and steal the passwords.kdb file and attack the hash, but at least that would only attack my passwords; you wouldn't have a target-rich environment.
Well not exactly. A few key ones I have memorized, and a few throw away ones I rotate between for when a site requires an account and I'll never be back. But my rare use passwords for important things are physically recorded in a locked notebook. Anyone who could get access to that could've just installed a keylogger into my computer.
My problem with a password manager in general is that once your computer is compromised, all of your passwords are compromised.
People may laugh, but for many people that's a huge step up. I've tried explaining password managers to family members, and I've failed. The usability just isn't there for many classes of user, and as noted elsewhere in this thread losing access to that database is catastrophic.
Getting them to use unique passwords per-site, even if those passwords are written down and stored in their desk drawer, can be an improvement.
I'm far less worried about someone breaking into my (grand)?parent's house and stealing their password diary then compromises their bank account than I am someone popping some random site and re-using the compromised password.
Now for enterprise credentials where the (physically) stored credential and the service to which it's applicable have a closer proximity there's a higher change of this kind of meatspace targeting. But then, the 'common local admin password across all domain-joined machines' problem persists too.
I'm just not facing any meatspace targeting with my current businesses. Security is about considering reasonable defenses against potential threats. For me a virus on my computer is a far more likely threat.
I couldn't agree more with your first point, but rather than recommend a local password manager, I recommend using a password algorithm of sorts. For instance, start with a password base (8 chars), a site specific "salt" (could be the domain or something simple like "email"), and a small per-site password or a pin (4 digits). With this, you can easily remember 1 password base for all your accounts, a convention for the "salt" (you don't have to remember each salt if you have a strong convention), and the only site specific info you'll need to remember is a 4 digit pin, which should be different per site. If you can remember a really small password or 4-digit pin, this method affords you all the protection you need. I use this method, but my passwords are 20-30 chars in length, because I'm paranoid.
Whenever the cloud fails to live up to its popular reputation as bulletproof and resilient, I cannot resist suggesting that the "cloud" as it exists today distracts us from alternative forms of computing that I feel would be superior. I've routinely proposed a theoretical I call personal application omnipresence or PAO [1], wherein user applications run on a personal application server and are made available to all devices via multiple views (in a manner similar to responsive web design).
Ultimately, I think a principle failure of modern computing is our collective inability to deliver secure, private networks (what we currently call "VPNs") in a form that is easily digestible by laypeople—or even semi-technical people, for that matter. With today's mess, configuring a VPN properly takes an enormous amount of attention to detail. VPN technologies are mired with a proprietary and confusing lexicon alongside a continent-sized minefield of potential configuration errors. Of all the R&D being sunk into the cloud, I am not aware of significant R&D investment in making personal private networks that are trustworthy and easily configured.
The inability to give individuals and families omnipresent private networks makes their multi-device lifestyles an all-too-convenient target for the facile omnipresence of today's plain cloud. The plain cloud offers omnipresence while forcing acquiescence of privacy, self-control, and even knowledge of how your data and information about your actions is being used.
It also centralizes sensitive data into especially juicy targets like Lastpass.
I'm not suggesting a distributed model is definitely more secure, but a plurality of implementation approaches, perimeter firewalls, and the tiny size of individual networks makes each target less interesting.
For the time being, I use a Keepass database on a file server I operate that I reach via an IPSec VPN from all of my devices. I am not a network professional, so my IPSec VPN may have been configured improperly, but I've tried to follow best practices. What I really want—to reiterate—is a high-quality, simple (not stupid but feature-constrained) private network that our proverbial parents could use. That is always on, from all devices I use, providing a secure channel to communicate with my data on my file server anywhere.
What I have, however, is the monster that is IPSec which forces me to think about concepts like SA lifetime, IKE, Key Groups, and certificates.
I use LastPass and KeePass extensively in the setup you outline.
Why do people use LastPass? Convenience, and you aren't really gaining any extra security (except through obscurity) when using those other services.
LastPass encrypts and decrypts client side, their cloud only synchronises the encrypted blob. This is what is happening in the KeePass + Cloud service scenario too.
You gain a little security through obscurity as you'd probably need to be attacked as an individual, but mass breaches are not unknown (Dropbox for example) and at that point you have no more security than LastPass.
KeePass does have the keyfile feature, which is a particularly nice version of two-factor authentication, but LastPass offers various options - including One Time Passwords (Sesame), YubiKey and even good old fashioned offline paper grid method (arguably more secure as you have a an air-gapped authentication method).
LastPass has fantastic apps and plugins that make using unique high entropy random strings for your online accounts absolutely painless. The plugins are better and more widely available than the KeePass versions.
I've said it in another comment, but it comes down to trust in the encryption method. If the method is properly implemented then the overall scheme is secure (save for other attacks like keyloggers which both would be susceptible to).
My problem with LastPass is that the Android app is not for free (ok to me) but I find the price too high (I haven't compared with others and Spain economy is right now pure shit, just my situation).
That's the only reason I'm gradually moving to localy stored Keeper.
The use of LastPass on mobile is part of the Premium suite which is $12 a year. I'm just a normal user (though I seem to be commenting a lot on this particular story I know!) and I think it's a fair offering.
Therein lies the rub, I don't think it is - the main plugins aren't anyway. There is an open source CLI version though [1].
So it's on trust.
I trust them to have correctly implemented it based on the logic that their entire business' existence is build on the security of the platform.
If it fails, they fail, so I trust them to have put the work in and to do continual monitoring.
I have to trust KeePass too, I don't have the skill to audit it myself and the fact it's Open-Source is no guarantee of security (Heartbleed anyone?) so it's all about where your trust point/compromise lies.
A centralized store is however unavoidable if you want to share and manage passwords inside an organization.
Although I share you discomfort, looking at it rationally I prefer to trust a specialized service, who's very existence and reputation depends on it, more than the alternatives.
The other alternative for sharing is stuff like 1Password over Dropbox, which is imho the worst of both worlds.
Why is 1Password over Dropbox the "worst of both worlds"? Seems like it's potentially safer, because it's encrypted with your passphrase and also your dropbox credentials. Sure, the NSA can probably get it, but J Random Hacker can't.
I'm not even convinced the NSA can get it. There are no side-channels to exploit here (which we know the NSA is good at) and cooperation from online services won't work either. The protocols used to encrypt this are fairly simple and well-understood and we should not assume that the NSA is capable of breaking the underlying (strong) primitives.
I'm not sure how encryption will stand up when you have a set of all deltas from V1... Vn of the encrypted file.
From my admittedly small knowledge of encryption I would assume that such a set of data could be used to greatly decrease the size of the search-space for the decryption key.
There are a few people experts who post here, anyone care to comment?
1Password actually stores new data in new files, presumably to make synchronisation work properly. For example, I have approximately 600 such files in my Dropbox. Interestingly, some metadata such as the login URL and the creation date is not encrypted, so it would be possible to build a list of the sites I have stored passwords for.
Formally, if your cipher would weaken in a way that makes practical attacks possible as more data is encrypted, it would be considered broken. Furthermore, it is possible to work around this by rotating keys and just encrypting the keys in a master file. 1Password definitely uses encryption keys that are fully independent from your master password, although I don't know if they periodically use new keys for new data.
- Dropbox files at rest are encrypted using 256-bit Advanced Encryption Standard (AES).
- Dropbox uses Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to protect data in transit between Dropbox apps and our servers; it's designed to create a secure tunnel protected by 128-bit or higher Advanced Encryption Standard (AES) encryption.
But don't they provide the "I forgot my password" option?? Doesn't that mean tjey have enough info to decrypt your data whenever thy want to, let you change your password, and encrypt it again with that new one???
Looks like the same problem to me in the fact that any Dropbox worker can take anything you upload.
Moreover, Condoleza Rice hired??! Wtf.
1Password only stores encrypted files in Dropbox. The encryption is done offline. Assuming the encryption is done properly, it is difficult to conceive of a way to attack it even assuming that Dropbox is compromised.
Actually that's how LastPass works (they move around an AES-256 encrypted database, and decrypt it on the client/browser).
The problem LastPass has, is that they re-use the same master password for two distinct things:
- Authenticating to login to your account.
- Encrypt your password database.
So in situations like this the loss of the authentication hash is relevant. I'd prefer to have a different password for the account than the database, but they don't offer that as far as I know.
In general I am broadly happy with LastPass's security. But it could be a little better for power users.
I find this design kind of baffling. Why go through the trouble of storing data encrypted only to snatch defeat from the jaws of victory by demanding that the client provide a secret derived from the encryption key just to log in?
I finally managed to convince my mother to start using LastPass recently; if I'd had to convince her to use two "master" passwords-- one for the encryption key, one for the service-- I'm fairly sure she'd still be using Google Contacts to store her secrets. :-\
Exactly. Why is why I entirely understand LastPass's reasoning for not doing that by default. But it would be a nice "advanced user" option (like 2F and all the other toys hidden in the account settings advanced tab).
I suppose they need to ensure that the person logging into the site, or interacting with the site via the browser extension, actually created the encrypted archive. Without a passphrase-derived authentication token (which they say is something like pbkdf2(encryption_key + passphrase), where encryption_key itself is pbkdf2(email + passphrase)), how could they ensure that?
Without that connection, if they had a totally separate secret S for web logins, anyone with S (and your 2-factor token if you have it enabled) could change your server-stored archive with no knowledge of how to decrypt it. Wouldn't that be a denial of service attack, if the next time you login to lastpass your local encrypted password archive is overwritten? You'd then have to rely on whatever other backup solution you (hopefully) use, to get an old local copy of the encrypted password archive.
That's true, but you have a local copy by default. I'm not sure what happens if the local and the server copy get radically out of sync - I don't know if it would purge your local copy or not.
Long-time Hacker News readers will be familiar with Matasano Security, and will expect to see us post in this thread. This month, there will not be a post from Matasano Security. Effective today, there will no longer be a Matasano Security. Instead, we're officially rebranding as NCC Group.
In late 2012, Matasano was acquired by NCC Group joining iSEC Partners and later Intrepidus Group. Since that time, we've been working together, cross staffing projects and benefiting from each other’s expertise. It's been a slow, steady process of increasing cohesion. We've reached the point where we need to assume a single identity, that of NCC Group.
Being a part of this process as it unfolds reminds me a bit of watching the Voltron cartoon series as a child in the '80s. The show featured pilots each commanding their own robot lions. Robot lions are fierce, powerful beings. But when they came together they'd form Voltron - a giant humanoid robot with the lions compromising each of it's parts. I like to think this is what's happening at NCC Group. What were previously separate companies each well accomplished in computer security are becoming a single even more formidable entity. "Form arms and body! And, I'll form the head!"
So, what does this have to do with hiring?
Growing a larger company requires a larger number of individuals. We still need candidates with the same skills as always; programming, reverse engineering, protocol analysis, web application building/breaking, adversarial thinking. We need people who understand technology and can identify flaws in how it's implemented. We need those who can look at a security weakness, and accurately gauge it's relative risk to the organization. And we need folks who can communicate that risk to multiple audiences, in varying levels of detail.
There's no better time than now to join us. Our integration effort has opened up opportunity within the company to focus on areas of specialization, advance skills, and take on ever more complex projects and challenges. If you've always wanted to be part of something new, but found yourself averse to the risk of early stage start ups, joining us now might be a way to do both. We're stable but we're evolving and changing, and our employees will shape what we become.
Please, bear with us on the sites above. We've migrated a boatload of content, and it's likely there will be some website wrinkles. We'll iron them out as soon as we can (mostly we'll just keep breaking interesting software).
I've been a fan of Matasano's work ever since I heard of it, and seeing all three companies unify together as NCC Group makes a lot of sense. Best of luck with everything, not that you'll need luck. :)
> Any interview process that requires a substantial time investment by the candidate pre-interview is broken.
I disagree, but accept that this depends largely on the desired outcomes. If the candidates goal is to spray-and-pray by applying at dozens of companies and hoping one makes them an offer they can accept, I'll grant that requiring more time may be a hindrance. If, however, the candidate's goal is to learn something, improve their skills, and demonstrate to the potential employer that they're capable of doing this on a short time cycle, they may welcome the opportunity, and many have.
> Why would I spend some time learning the security niche just for one interview? I could instead work on Android development, Python, Scala, or a whole bunch of other things. Those would be useful for many jobs, and not just 1-3 employers.
Because you want to work in security generally, and for us specifically? I fully accept that not everyone shares career goals which align with our needs, and encourage them to pursue other avenues. If you're dream in life is to be a broadway actor, we're unlikely to be able to help. That doesn't make this goal less important to you or valuable to the world at large, it just differs from what we do and offer.
That said, if you think that security skills (and web app security specifically, which is the typical path for those learning for the interview) are relevant only to "1-3 employers" I fear you drastically underestimate the size of the market both within security consultancies and enterprises that have a security team (or just appreciate security-minded developers).
> Why is putting in a lot of time researching security for your interview a better use of my time than learning more widely applicable skills?
It may not be. There's a lot of paths to self improvement, and their suitability to a specific individual will vary, depending on that individuals goals, desires, and learning style. I don't think anyone is trying to prescribe 'the one true path to self improvement' but rather one that we've found to work, and one that we help our candidates advanced down.
> What if I put in all the time, pass the pre-screening, and then when I meet you, it turns out you aren't the type of people I'd want to work with?
Then we shake hands and each go our own ways, hopefully having learned something about each other and ourselves in the process. Maybe we've made contacts that'll be mutually valuable in the future whether it be for future employment, a business relationship, or simply someone to chat with at some developer meetup, conference, etc. and bounce ideas off of. Choosing not to continue a relationship is a perfectly viable outcome of any interview process.
The security of computer systems has increasingly become an everyday concern. The news all too often brings word of yet another compromise, exposing financial information, personal details, or simply salacious pictures. Whatever the impact, it's clear the technology industry has a problem, and there are few easy solutions.
Some seek legislation to impose harsher penalties on the responsible parties. This ignores the fact that many of those responsible are outside the jurisdictions which seek to punish them. In some cases, they may have tacit approval of their own government, or even be operating on their government's behalf. Others turn to established security products looking for antivirus and network filtering technologies to add protection. This is an also an imperfect solution. It places the defender in a reactive posture, responding only to those threats which have been previously detected, and for which countermeasures have been developed. There's no perfect solutions.
At Matasano, we believe the best way to combat security weaknesses is at their source; by discovering and remediating software vulnerabilities before others leverage them for ill effect. Our clients see the value in this approach. We're engaged to work on some of the most interesting and important software on the planet. Aside from identifying vulnerabilities, we help our clients identify the root cause. Through this, they can adjust processes to reduce the likelihood of similar problems in the future, while increasing their ability to identify and correct them. The goal is more resilient software.
We've assessed hot startup web applications, low level device firmware, mobile platforms, and everything in between. With this breadth, we have need for employees skilled in frameworks like Node, Rails, Django, and Spring. We need people comfortable with x86 and ARM assembly, reverse engineering, and binary protocol analysis. If you're skilled in a programming language with the letter 'C' in it, that's desirable. Newer safer languages like Rust and Golang are in demand. In short if you share our focus on helping secure our software ecosystem one piece at a time and want a chance to do something about it, we should talk.
Next month, you'll notice a change in these posts. Since being acquired by NCC Group in 2012, Matasano has been working increasingly closely with our peers at iSEC Partners and Intrepidus Group. The time has come to formalize this, by adopting a common name; next month I'll be posting under that name.
SSL means something very specific; something that people should no longer be deploying. The article notably uses the term 'Non-secure HTTP' which at this point in time means HTTPS leveraging TLS (probably at least 1.2) but leaves some room for future interpretation as newer versions or entirely different standards arise.
No one is advocating for 'SSL' here, and continuing to use the term 'SSL' or 'SSL/TLS' when we really mean 'TLS' further confuses the situation.
It's not that specific. You could even negotiate a downgrade with a TLS server to use SSL. The first 3 versions of the protocol were named SSL and the later ones were named TLS but they're not really different.
The differences are significant when it comes to the security of the underlying protocol, and the downgrade is why it's important you refuse to support SSL entirely. SSL of any version (v2 or v3.. the v1 you refer to was never publicly in use) comes with security problems that are resolved in TLS.
I won't bore you with the details, they're well explained at http://disablessl3.com/ among other places. All major browsers have ended support for SSL, and more secure alternatives have been available for years.
It's not a high risk; attacks require scenarios that may not be common, but it remains true that there's no reason to deploy SSL today.
TLS 1.0 was also vulnerable to BEAST. I'm assuming that pointing to TLS 1.0 as the "minimum" is temporary. Over time, we will decide that the cutoff should be TLS 1.1 and we'll deprecate TLS 1.0. At that point, everything you're saying about SSL will be true of TLS 1.0. It's really just a difference in version number.
Yes, it likely will. That's probably why the article mentions a deprecation of "Non-Secure HTTP" rather than prescribing a specific TLS version. It's the sort of language that will stand the test of time as newer protocols become deprecated. The comments here, however, largely encourage "SSL" which is poor advice.
BEAST can be mitigated through ciphersuite selections and other measures. This makes it somewhat different than POODLE which is a protocol design flaw for which no reliable mitigation exists.
Suggesting folks not deploy SSLv3 is hardly a controversial statement. It's not just a difference in version number, it's a difference in protocol specification and name. When we say 'Use SSL' a well intentioned reader may follow that guidance and implement SSLv3, or worse disable support for TLS. Words mean things.
Then I realize, that may have been part of the problem.