> This is not a good suggestion on their part, and has long been proven ineffective:
Agreed; that is bad advice.
I tell people: If you think of a trick then the attackers, who have expertise and think about these issues all the time, have thought of it long ago and have written it into their password-cracking software. That applies to visual substitutions (such as GoToMyPC recommended), phonetic substitutions (e.g., AmeriKa), patterns on your keyboard, etc.
In a more technical sense, that applies to tricks that can be defeated with an algorithm and affordable computing resources.
But if the trick you are using results in sufficient entropy, it shouldn't matter that the enemy has thought of it too. I'm still a fan of linking common words together as this results in easily-memorized passwords with very high entropy. "Catrunningfishhostagelaptop" is a good password these days. it is easily remember but also difficult to brute force even if you know the trick by which it was constructed.
(And yes, by putting it out there I realize it is now a bad password.)
The way to compute the amount of possible brute-force combinations:
For a normal 5 letter (alpha-numeric only) password:
36 factorial, which is (36 * 36 * 36 * 36 * 36) = 60 million possible combinations.
However, for a 5-word password, the calculation is as follows:
Assuming the number of possible words in the English language is 1.025109 million, then:
1,025,109 factorial, which is (1,025,109 * 1,025,109 * 1,025,109 * 1,025,109 * 1,025,109) = A really big number.
So, granted, the amount of possible words is much smaller than that. But the attacker can't know that for sure. To put the number above in scale, just 69 factorial is equivalent to 1.711224524 * 10^98.
I agree with your general point, but I have just a couple of mathematical points:
> For a normal 5 letter (alpha-numeric only) password:
> 36
With the "normal" recommendation of numbers, uppercase and lowercase letters, and punctuation, it's up around 100.
> factorial
The calculation is X^Y, where X is the number of possibilities per element, and Y is the number of elements (letters or words in these examples). So using only only lowercase letters (26) in an 8 character password would be 26^8. It's not factorial because you can reuse characters (e.g., your password could be X92m-sXp/)
> the amount of possible words is much smaller than that. But the attacker can't know that for sure
They will search the more likely words first. I read someplace that 10,000 words covers most people's vocabulary. That's still 100 times better than numbers + uppercase + lowercase + punctuation.
>"The calculation is X^Y, where X is the number of possibilities per element, and Y is the number of elements (letters or words in these examples). So using only only lowercase letters (26) in an 8 character password would be 26^8. It's not factorial because you can reuse characters (e.g., your password could be X92m-sXp/)"
You're absolutely right, not sure why I got ahead of myself with using factorial so incorrectly.
You were probably thinking about the fact that picking, in order, 5 elements taken from a set of 1000 elements yields (1000 factorial) / (995 factorial) possible combinations.
You're making the incorrect assumption that all letters are equally likely, and all English words are equally likely.
I'd guess the words used in that password fall into the top 10k words, easily. No need to check words like pediatrician, when the password contains the word cat.
Technically true perhaps, but from my experience the word selection is always way narrower than that, like usually from maybe the 2000-5000 most common words.
It's big enough to matter. 2000^5 ~= 60^9 so it's as strong as a 9 random character password which is usually regarded as strong enough, and far better than a typical 1 word with 3 or 4 special characters mixed in.
Five or six words is a huge amount of entropy. In reality there are other rules in my example than just using words. It starts with a capital letter and includes a conjugated verb (running) both of which increase complexity considerably. And it of a random length, having taken its length from my selection of words rather than from any fixed policy. Few services accept random lengths but imho all should.
There is a great scene in DoctorWho where a door password is a series of concepts (spoken mentally) that one thinks about in a particular order. Fiction, but the person writing that scene knew a thing or two about password complexity.
> It starts with a capital letter and includes a conjugated verb (running) both of which increase complexity considerably.
They reduce complexity: It reduces the number of possibilities on the first character, and the attacker knows that one word must be a (conjugated? present participle?) verb yet, when otherwise it could be anything.
That might not be true for an enemy who has access to some of your other passwords already, but assuming it is I still don't see how the strategy above increases complexity. At best, the complexity remains the same.
The question is whether people are all going to pull words from a very small pool or form sentences to cut the search space (adjective noun adverb verb noun). A search space of 2000^5 (2000 most common words without punctuation) is still about 20 times larger than 80^8 (upper/lower/number/symbols)
The number of possible letters is much, much smaller than the number of possible dictionary words. The latter would take many orders of magnitude longer to brute force, which would make it unfeasible.
Are there any good sources on what sort of generative trickery a good cracking tool will use?
I've noticed that the OSX Keychain 'memorable' password suggestions are almost always /(\w+\d+[[::punc::]]+\w+)/, which is enough of a pattern to probably make an explicit generator for which will match much faster than a naive brute-force.
Note that what you're really looking for is the amount of entropy in the encoding. So for many 'memorable' encodings, the password does need to be longer vs. an alphanumeric+symbols password, but still encodes the same number of bits of entropy.
Diceware[1] is a nice example of how such a system works, and how you can generate a strong 'memorable' password by hand (and dice ;-). In short, there's a dictionary of short words, letter combinations, and numbers that form the "symbols" of the generated password. A random input (here, rolls of dice) are used to select a series of symbols. You could just as well create your own table and generate the password from that, but if you've got enough randomness as input then it doesn't so much matter what encoding you use. In fact, the general assumption is that you should assume your attacker knows your encoding.
> Are there any good sources on what sort of generative trickery a good cracking tool will use?
Two answers:
1) It's not worth trying to keep up with, unless that's your specialty. There are people who spend days thinking up attacks; how much time will you need to spend to keep up with them?
Far more time-effective than trying to anticipate all the specific attacks is to use provably secure defenses: Passwords that are mathematically too expensive to brute force, and which cannot be guessed by other means (e.g., by knowing personal information about you). That shifts the weak link from your password to the security of your OS, network, and applications, which probably have a couple of holes in them.
This is what I tell people about the + notation in their email addresses. Spammers know what it's for, and can easily strip it out if they wish to conceal their address source.
Yeah, really. They also don't say another important thing, which is never use the same password in two different places. Maybe they think nobody will listen, but after seeing that other dumb advice, I don't have much faith.
It's sad that this is a service instead of just free software. Did that never evolve to be user friendly enough? Do ISPs not let you run your own web server anymore? Maybe it's because of changing IP addresses and domain names? The cost of this service seems to be slightly more than the cost of maintaining your own domain name.
> It's sad that this is a service instead of just free software. Did that never evolve to be user friendly enough? Do ISPs not let you run your own web server anymore?
Very few users can run their own web servers. We used to deploy GoToMyPC for users; it was reliable, performed well, platform independent (including mobile), and secure. I expect it still is.
When the new OS or other new tech came out, GoToMyPC handled any compatibility issues; we didn't have to worry. No matter what the user's remote computer was, it worked (as long as there was an Internet connection). The security was good too: End-to-end encryption, optional one time pads, and even details like blanking the screen of the host machine so that someone in the room with the host couldn't monitor what the user was doing.
We stopped using it because we didn't need it any more, but we were happy customers for many years until that point.
One time pads are rarely useful: The key is as big as the data, so you need a secure channel to transmit the key. If you had that channel, why not just transmit the data over it?
Your mistake here is failing to consider that sharing an entropy pool does not (and in fact should not, it must be shared out-of-band anyway) need to be real time. Fundamentally, OTPs involve leveraging physical security and fleeting points of physical contact to create a pre-shared perfectly secure future communication channel. Ie., two people meet up an exchange a USB stick (or HDD), then consume the entropy pool over time. These days that could mean trivially having a pool of hundreds of gigabytes to terabytes, which equates to tens of thousands of hours of high quality voice communications, ludicrous amounts of plain text, etc, and that's assuming direct consumption. If instead it's used just for symmetrical session keys then from a human perspective it'll last forever (can burn through thousands of 512-bit keys an hour for an entire lifetime and still be fine).
The issues with OTP include that it doesn't provide authentication, it doesn't scale, pure point-to-point, etc., and that in the end the benefits it offers just don't matter in general right now vs the costs and disadvantages. There's no reason in general not just use a decent pre-shared self-gen cert, PKI or WoT key system instead. OTP applies best to any organization that can already handle physical security. Basically, if an organization moves weapons, money, or drugs around securely then it could move entropy too, so governments, militaries, banks, organized crime and the like. But for anyone to bother all existing crypto would have to be utterly broken, otherwise it's superior to just use standard crypto.
The primary issue is that through misuse it degrades almost instantly from unbreakable to "little better than ROT13". And, it still appears secure to the hapless user.
>The primary issue is that through misuse it degrades almost instantly from unbreakable to "little better than ROT13". And, it still appears secure to the hapless user.
Please explain how this does not apply identically to every form of encryption, particularly as we have directly seen vulnerability after vulnerability. That implementation matters goes without saying in these discussions, but if you want to go there then in that respect OTP is fundamentally much simpler and easier to get right then public-key crypto. Generating decent random noise, storing it in an ordered way, then deleting it automatically after use are comparatively straight forward operations to automate. Using each bit is just a matter of an XOR operation and that's it.
So I disagree with you that technical challenges are in any way even remotely the "primary issue" when it comes to OTP. If there was a need for it it'd be rapidly adopted. But outside of certain very niche scenarios, maybe, there simply isn't any need for it, nor will there be in the foreseeable future.
If I use the same AES key to encrypt two messages my communications are still mostly secure. Specifically, there's no known way to recover the key and attack all my other messages.
Versus if I use the same OTP twice my security is automatically shot and any other communication with the OTP is now also as good as leaked. Worse, context can then let much more of the key material be leaked than just the shared portion.
Even if used correctly, you've first got to create the OTP. Any mistake in generating your OTP means you can have a predictable pad and not know it. If you're trying to gather strong entropy you can know your lava lamps (/ geiger counter / etc) sources are random and be brought down by a bad camera driver.
Also, any methods to strengthen your OTP (ie, hash multiple streams together) are the very tools that you're avoiding by using an OTP. If you trust them you should just use them.
> Any good reason why this wouldn't be the default?
It costs time and effort for the users, not only to execute it but to learn it, troubleshoot problems, etc. It would drive many users away; in a business environment especially, that time and effort are rare and precious.
In the example of wanting to access a computer in your home, you can implement this fairly easily using entirely free software with VNC-over-SSH, but it's depending on having a public IP address and open port on your home NAT/router.
One of the main reasons that things like gotomypc and teamviewer have been successful in the market is the huge number of people who don't know how to/don't care to take the time to set up an SSH tunneled setup, and want something to "just work" through NAT.
My setup looks something like this, with public/private key SSH auth. Copied and pasted from my notes, hostnames and IP addresses redacted:
-------
I have a static /30 and forward port 445 on the external side of my home router, through the NAT to port 22 on the workstation PC in my rfc1918 IP space.
workstationhostname.domainname.org normally has vnc session listening on port 5901 localhost only, spawned with:
vnc4server -geometry 1920x1200 -localhost
This is for use with an SSH tunnel coming from hostname.ofmy.static.slash30.org:445 through NAT to workstationname.rfc1918.ip.address port 22
To access from the outside world, on the client, do the following:
ssh -v -L 5901:localhost:5901 -N -f -l myusername -p 445 hostname.ofmy.static.slash30.org
use client system's vnc client software to connect to 127.0.0.1:5901
To access from inside the LAN, on the client, do the following:
ssh -v -L 5901:localhost:5901 -N -f -l myusername -p 22 workstationname.rfc1918.ip.address
use client system's vnc client software to connect to 127.0.0.1:5901
If you're on a Windows system this is even easier.
Go to System -> Remote Desktop Connections and check the box to enable incoming connections.
On your router, forward port 3389 to the machine you want to access.
On any client device running Windows (linux/mac can use FreeRDP, for which there are numerous wrappers) connect to your home's Public IP, and log in with your computer's usual username and password.
For the average home user this is all the setup that's needed, and it doesn't involve handing over your computer's security to a third-party company that is now a giant target for these sorts of attacks. :)
I think the big advantage that LogMeIn and GoToMyPC have in the casual realm though is their simplicity. In particular, they entirely dodge the need for the user to know anything technical at all, including port forwarding on the router, which is the bigger technical hurdle here. You just install their program and it does the rest for you. Port forwarding seems like child's play to you or me, but they have a huge market in folks who didn't even know you could log into your router and change settings. Or that even know what a router is, despite owning one.
Ransomware have spread via exploitable, unupdated versions of RDP, which is worrying. Better to listen on another port of RDP must be exposed to the Internet.
Thanks. So it sounds like port forwarding is the major barrier. That and having to remember your IP address and update it every time it changes.
I wonder if IPVv6 would help here? Would we expect to get a static IP address for a device that can stay the same even when we're connected to different networks or via mobile data and wifi? That would mean even different network interfaces in the device would need to share the same address so I guess it still won't happen.
which leaves your computer open to the internet by a simple login and password on the default rdp port 3389. Not nearly as good as SSH public/private key auth where the SSH private key also has its own passphrase on it.
I run my own web server with a residential ISP and they don't seem to mind. But in places like an office or with really crappy ISPs you just don't have a public IP. I've searched for services that just let you forward out a few ports over SSH but these don't seem to exist. Right now, to get to my laptop I have a raspberry pi "jump box" that sits on the book shelf and my laptop connects to it over SSH and forwards out port 80 and 22 so I can get to it from pretty much any network.
In addition to the services mentioned in sibling comments, it's not difficult to outfit a VPS for this purpose. This is a pretty helpful starting point: https://gist.github.com/gdamjan/4586758
Is it still the case that for most ISPs the uplink is much slower than the downlink speed? That was one reason running anything other than limited-use servers from your home wasn't feasible.
What you're saying is more drastic then what they wrote here. If you used the same password somewhere else, then you're going to have change all those passwords.
> Because I'm human and can't maintain 30+ passwords?
The original question was about GoToMyPC providing more details so someone could "estimate the risk".
If you're already reusing passwords, that becomes rather easy: Your risk is dominated by the fact that you reuse passwords across services. No amount of details from GoToMyPC is going to affect that very much--whether you even used their service or not.
Seriously, just start using a password manager. It's not that much effort, even just for the peace of mind that you're finally setting passwords with the desired strength that you already know is necessary, but couldn't afford to maintain / memorize.
The hardest part for me was trying to decide which one to use :) I settled on KeePassX, because it's free and open source, has an Android app, doesn't store your stuff on their servers (just one encrypted database-file you can safely keep synced between devices via whatever method/cloud storage you prefer). I've been keeping an eye on the pro's and cons between various password manager options, and as far as I've seen the biggest downside to KeepassX was that one security researcher didn't like the user interface (it's fine, IMO) whereas the others either keep your stuff on a server somewhere, are not open source, or both.
Yes, someone could compromise your password manager password and then they'd have everything, but at least there's an additional step there. It's not going to protect you against nation-state level meddling with your life, but it will protect you from "random blog got hacked", which is slightly more likely for most of us.
Generally, I remember my login passwords, password manager password, and Google passwords (for email), and then put everything else into the password manager. I have no idea what my HN password is and don't care.
Would be nice if they told us how they hashed it or if they hashed it at all. If the passwords are bcrypt then it wouldn't matter if an attacker got that hash.
For example, if the attacker has hijacked the login form, and I haven't logged in years, then I'm not at risk. Details like this can help us make intelligent decisions. It's one thing if they stored in passwords in clear text, another - if they used MD5, and a third thing - if they used SHA1, bcrypt, etc.
We have to know! Piecemealing this shows they are clueless!
A unique password, 2FA, AND a unique email address.
I use https://lastpass.com/ for generating passwords. $12/year and works on Linux & Android. Would prefer open source, but nothing else comes close. I tend to generate 32 char passwords with a mix of upper, lower, number, and special. Only a few websites insist on shorter passwords - or have character restrictions.
It does make logging in to some frequently used sites a bit of a pain (looking at you PayPal!) but I think it is worth it.
On to unique email addresses. I do this for two reasons.
1. Allows me to easily see where an email has come from & filter if necessary. I can tell if your company has leaked / lost / sold my address.
2. If I have reused a password, a database leak doesn't compromise other sites. An attacker doesn't know the login details for LinkedIn based on my GoToMyPC email.
I tend to use something like lnkdn@ mydomain / gtmypc@ ... / twttr@ ... - but if your mail provider lets you use a catch-all, it can be anything you like.
One word of warning - it really confuses people when you give the email over the phone! I usually say "I'm creating a unique email address for you so that the message doesn't go into spam. Ok? sound of me hitting random keys It's yourcompany@ ...."
KeePassX (https://www.keepassx.org/) is free and open source password manager. Having never tried LastPass I can't vouch that it's feature compatible, but it covers all my needs.
I did look at KeePassX - but it doesn't seem to have reliable autofill in Chrome & Firefox (where I use 99% of my passwords). It also means I have to manually synchronise the database between phone, PC, etc.
I just keep the keepass.db file in a cloud storage folder that is synced across devices. Works perfectly and because of the encryption it hardly even matters that cloud storage is (currently) on a US server.
The "perform autotype" option in KeepassX Linux seems to work well enough for me in Firefox, Chromium and most applications (it basically seems to send <user><TAB><password><ENTER> which usually does the trick--and afaik it has some settings you can tweak when it doesnt, but I never bothered with those).
But if Lastpass works for you, that's cool. Getting to use a password manager in the first place is the most important step, IMHO.
> I did look at KeePassX - but it doesn't seem to have reliable autofill in Chrome & Firefox
It does have browser integration, for both Chrome - ChromeIPass extension, and Firefox - KeeFox extension. Both extension work via KeePassHttp plugin. Works well on Arch Linux.
I meant KeePass http://keepass.info/ writing about browser integration (in my case I run it on mono), not the KeePassX. KeePassX is a very simple app in comparison with KeePass, so I prefer KeePass over KeePassX.
Now invoking it by saying genpw would generate a pseudorandom string of 16 characters length. You could specify the length by passing a parameter to it, e.g. genpw 8.
O...K... but where do you store them? How do you sync them between devices? How do you auto fill them in the browser? How do you change them when a service is compromised? How do you securely share them with other users?
LastPass does all of that. And I don't even have to drop into the terminal.
I feel like it's almost certain that Lastpass is owned, as are other popular online password stores.
No security is perfect; all you can do is make it more expensive than it's worth to the attacker.
How much would it be worth to have all the passwords to every account of every Lastpass user? Does Lastpass really have the resources and skill to protect something that valuable? Is it even possible?
Well as long as you 'feel' that way, it must be true.
Lastpass (supposedly) stores the encrypted password vault, never the decrypted. Decryption occurs on the users end. You would need to either have a keylogger on the target users machine to grab their master password, or compromise the software. Neither is impossible, but both are a little harder than simply break in and access Lastpass's storage.
I say supposedly because I do not know of any 3rd party verification.
> You would need to either have a keylogger on the target users machine to grab their master password, or compromise the software. Neither is impossible, but both are a little harder than simply break in and access Lastpass's storage.
That reasoning only holds if it's in fact significantly harder to compromise the software than it is to "simply break in and access Lastpass's storage". If you believe that might be possible, then the security of your password vault basically depends on the differential difficulty compared to "simply break in and compromise the login form / browser extension / update channel to make it do <whatever>".
My point is not that this would be easy, rather that if someone went as far to break in and grab the storage[0], given the sheer value of the data, the barrier to go a step further and compromise the software isn't big enough to make me go "okay well that's all right then, that might happen, but this surely won't".
The biggest difference in risk between those two scenarios is that yes some cybercriminal that is "just poking around" might easier stumble upon access and just grab the vault than to set up a compromised login form and wait--not so much more difficult but just more effort.
[0] which I agree is fair to trust Lastpass to have properly encrypted, cause if you can't trust the people you pay $12/year to keep your most sensitive data secure, then who can you trust?
I didn't make that claim; why add that attitude to an otherwise pleasant conversation?
When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Yes you did make that claim. You said that you feel there is a high likelihood that lastpass is compromised. You have no evidence or proof of this, just a gut feeling presented as some sort of fact or 'just asking questions.'
"I feel like it's almost certain that Lastpass is owned"
I use LastPass, but I'm still fearful about it. It's such a rich target, and all a hacker would really have to do is to intercept when you put your decryption key in and send it off to their own server. Then they'd have access to all your accounts. They'd have to put that backdoor into the extension, but the point is, it's doable, and most people wouldn't have any way of knowing that it happened.
"LastPass says they never receive my Master Password. Don’t I send it to the LastPass servers when I log in?
No, when you login to LastPass, two things are generated from your Master Password using our code discussed previously before anything is sent to the server: the password hash and the decryption key. This is all done locally.
The password hash is sent to our servers to verify you. Once verified, we send back your encrypted Vault. We are only sent your hash, not your Master Password.
The decryption key, which NEVER leaves your computer, is then used to decrypt your Vault once it comes back."
The point was "all a hacker would really have to do is to intercept when you put your decryption key in and send it off to their own server" (emphasis added).
However this is more about keeping the Lastpass software secure than it is about keeping the encrypted user vaults secure. The documentation you quoted really obscures this by use of the passive voice, casting the end-user somehow as an active agent deliberately doing all the encryption/hashing and sending, implying that they are in full control :) Try this on for a change:
"LastPass says they never receive my Master Password. Doesn't the LastPass Software send it to the LastPass servers when I log in?
No, when you login to LastPass, the LastPass Software generates two things when you give it your Master Password, before the LastPass Software sends anything to the server: the password hash and the decryption key. The LastPass Software does all this locally.
The LastPass Software sends your password hash to our servers to verify you. Once verified, our server sends back your encrypted Vault. The LastPass Software only sends your hash to our server, not your Master Password that you just entered into the LastPass Software.
The LastPass Software then uses this decryption key, which should NEVER leave your computer, to decrypt your Vault once it comes back."
-
The above is IMHO a much better way to word the same documentation, since it doesn't try to gloss over a rather important part of the attack surface. It's not really fair to on the one hand congratulate a user for being security-aware enough to use a password manager, but then ignore this part. Good security software documentation should proudly present the last few exposed parts of the attack surface, especially if they are minor ones, so that a user can assess the limits of their trust--there are always limits, no sense in pretending there aren't, and it's better to know them so that the user gets to decide what they're okay with.
I am switching away from unique mail addresses … I used a mix of catch-all and plus characters:
The former reduces the efficiency of your spam filter, the later is not (fully) supported by many websites. AirBnB for example allowed me to set an mail address with a plus character, however, login did not work anymore, so I was locked out and had to create a new account … AirBnB support refused to change my mail address since they apparently did not get the plus character 'trick'.
In my experience adding the domain of the recipient often leads to problems.
Rep: "Can you verify your email address?"
Me: "er, em-verizon@example.com"
Rep: "Hey, I didn't know you worked for Verizon!"
Me: "no..."
And now the call gets excruciatingly slow and unfriendly because the rep thinks I'm trying to hack something.
Also, more than one web forum has silently binned me until I removed the domain from my email address. Had one where I could post for a few days, then the admin deleted me and sent that email address a crazy anti-spam rant thinking I was a bot.
I still like using unique email addresses but I make sure they're obscure.
I use the domain backwards e.g. nozirev@mydomain.com.Customer service agents don't notice, and it's easy for me to tell where the email was supposed to have originated.
Yep, I highly recommend LastPass as well. The password generation, sync, platform support, and browser extension features are great. It's fairly easy to setup exclusion filters for not remembering passwords, as well as controlling if matching works on the first level domain (*.domain.com) or exact host.. The former generally works well for most sites, but the latter is essential for my own domains (where I have multiple different services, accounts for testing, etc).
I've been using a catch all domain for at least 15 years. One thing I learned early is to use a subdomain, which avoids getting dictionary spam attacks.
For the last many years, I just forward it to a gmail account, where there is a corresponding filter to label it into an "accounts" group. I get essentially zero spam to this.
Also, I've had multiple times where it confused reps as well. It's kind of funny when it happens, but also sad that having "theircompany@sub.my domain.com" makes them go "oh, did you used to work here or something?".
What provider do you use that allows for catch-all? I really like GMail but the lack of support is really annoying, and a lot of sites & dump leaks are beginning to ignore the "+word" notation for email addresses.
If a lot of people start doing this thing, then it will be trivial for an attacker to figure out name+service1@domain can be changed to name+service2@domain
"service1" could be generated randomly as well, and stored along with the password in a password manager.
Another nice property of this suffix is that one can identify who gave away their email address / which site it was scraped from when receiving spam; not sure where I have seen this written down originally.
I think when spammers see a "+" they just strip everything after it down, i.e. me+spam@example.org -> me@example.org. Not to say many sites just don't accept "+" (or, worse, cease to accept such addresses).
Unique, non-guessable, machine-generated addresses are the way to go (do with emails just like password managers do with passwords), but no common person can use those, because they'll need a domain and self-hosted MDA.
Then I could just make my rand(service1) chars larger. No point in adding it to email address at all. Email leak (privacy) is an issue that this could help with but I do not see any benefit in terms of securing my account
How do you generate new emails? Say, I see a new websites I need a new email? What do you do? Is there a chrome extension that can do it with one click?
My personal domain is set to forward all email to my Gmail. Since Google is my registrar, it's expectedly simple to configure this. I haven't setup outbound addresses; services rarely need email sent to them, and replying from my Gmail hasn't caused me any problems yet.
Yeah but doesn't prevent the attack. Username is still in the email address. Ideally I'd like <domain>+<nonce>@gmail.com that forwards all to my email.
I use the excellent 1Password, syncing over WiFi with my phone as the source of truth for my vault. 2FA enabled for everything that supports it and backup codes stored physically. Works great and password managers are one of the few times when something is both more convenient and more secure.
Also, use 2FA wherever available. Google Authenticator is good enough.
Store your backup codes somewhere safe (your keepass db, for example. Although that goes a bit counter to the point of 2FA, if someone cracks your keepass db, you're pretty screwed regardless).
This is not a problem with 1Password, which syncs TOTP keys as part of your secure keychain, making it easy to use multiple devices, or even just your desktop.
Not only do you get the same issue with SMS authentication (have to set it up again when you get a new number), but on top of it SMS auth is not as readily available and has proprietary requirements (namely, you have to have a mobile number with text support, it has to be available at your current location, it may cost money, the auth service has to support whichever country code you're under, ...).
Also, as other people mentioned, it's technically possible to back up your initial seed.
SMS auth is a disgrace, when we have 2fa standards.
Using KeePassX/LastPass/1Password is a bit problematic. They become a single point of failure. Someone can get my master password (https://github.com/cxxr/lostpass) or can pwn LastPass. To improved that my passwords becomes <last_pass_gen_pass> + <random_nonce_that_i_know_how_to_generate_in_my_head> + <helper_password>
I divided accounts into tiers:
Tier0: The most important account: Macbook, Gmail, Github
Tier1: Still important, but not as much as Tier0: Youtube
Tier2: I don't really care.
Tier3: Testing accounts for local dev server: Single simple password like qwerty1234.
I just need to remember 5 passwords(Gmail, Macbook, Github, LastPass, helper password). I think this strategy gives a nice balance between connivance and security.
It's not a terrible idea, but it does fall apart if you need to change one of the passwords (say, because you were using this strategy for a number of services including gotomypc). Now you need to have multiple master passwords, or you need to increment the service name (gotomypc2?), and then you're remembering the increment as well as the service and master password.
It's a cute trick, but I don't think it really scales well for the number of accounts we tend to have these days, and the frequency with which passwords must be changed due to hacks, password aging policies, validation ("must have 1 punctuation character"), etc.
As for entropy, it's limited by the master password, and whatever obscurity the hashing and service name provide. If you have a short master password, you're not getting the as much uniqueness as you might think by looking at the length of the hash output.
In addition, I try use different E-Mail adresses whenever I sign up, a catchall makes sure they end up in the same inbox. This might not stop a sophisticated targeted attack, but it should throw off a lot of automated runs since the email they got is seemingly not used at another service. A litte obscurity to strengthen the rest of my security ;)
No, only once to decrypt the lastpass database. You can even set to only ask every 30 days, however I feel that this defeats the security features a little
I use https://www.passwordstore.org/ to generate passwords which are then encrypted using my GPG keys. My passwords directory is a git repo which I sync to GitHub. Since I don't possess a Yubikey or similar, I've stored a copy of my secret key in Protonmail.
KeePassX and Syncthing over WiFi. No browser add-ons. I decided to give it a try after the LastPass acquisition to see how feasible it was, and haven't looked back really. It helps that I'm mostly on Android mobile devices. KeePass2Android is what I use on the phone.
I use a password safe file (https://pwsafe.org/) which I then store randomly generated passwords per site and have a strong password on the safe itself.
I like this as a solution as it's not dependent on any third parties like cloud services, its pretty portable and I have a unique password per site, so I'm not really that bothered when the inevitable breaches happen.
Downside to this approach is that I have to have a device which has the password safe to hand to use it (there are clients for Windows/Linux/Mac/iOS/Android), I'm responsible for managing the file and if I lose the file + passphrase I'm stuffed :)
I have a "things I don't care about password" that's long, easy to type, and easy to remember. It's about 20 characters, which is sufficient for most services that don't have two-factor authentication, but annoying because some archaic systems STILL have a maximum password limit for ridiculous reasons that suggest one-way hashes are not being used.
Wherever two-factor is available, it's turned on. Usually through my phone, which has its own passcode and won't display text messages on my screen. I'm curious as to how secure this really is, but I suspect this is reasonably difficult enough to hack that someone would have to be targeting me specifically to be able to reliably pull my SMS token out of the air and match it up to my login before I used it within a few seconds and invalidated it. If someone decides to target me specifically, I have bigger problems.
For my email, my banking sites, and all the things that I really would rather someone else please not log into, I have a unique password. This is still long and easy to type; the only advantage of these passwords is that I am sure to not share them in any modified form anywhere else on the internet, which protects against these sorts of cross-site password theft attacks. (Even for my shared password I have a pattern that makes it uniqueish, but that pattern is simple enough that a human could probably reverse engineer it.)
The only real exception to this strategy is things that can be password-less, though that carries its own weirdness. All of my remotely-accessible SSH servers use private key authentication and have passwords enabled for sudo, but don't allow SSHing in using that password. (So they are effectively single-factor for login and userland access, which can still do a lot of damage but requires a computationally difficult key, and two-factor for root access.) This carries its own issues; I have to keep my private key files somewhere, and even if I use multiple keys for each machine I log in from, all it takes is one rogue login to hose my server. I either put all my eggs into one basket by using some sort of encrypted store, or I spread out my attack surface, increasing its complexity, and decreasing the chance that I'll have successfully patched all the holes up. I also don't like that there's no way I could reasonably memorize a private key, so the option of NOT storing it kind of doesn't exist. At best I can try to protect the key in some way.
I only use Apple on a daily basis, so I use the inbuilt iCloud Keychain which syncs my passwords across Apple devices. I use the built in password generator to generate secure passwords that are unique for each website. For the times I do log in to a PC, I can call up my passwords on my iPhone to type them in manually.
Random password, FastMail email alias, fake but plausible name and date or birth, all dumped in to 1Password.
Would love to find a credit card which allowed me to offer up fake billing details - obviously the CC provider would need to know who I was, but there's no reason who I'm paying needs to.
I simply use keepassx with the database being synced between all my devices (Linux, Windows, Android) via Syncthing. I also have a scrambled printout in my bank safe (30€/year) that I update every couple of months.
They don't really say it has been hacked, just that being a target of an advanced password attack.
It might mean attackers are using password lists from previous leaks (linkedin), so they decided to force a pass reset to everyone. Or maybe they got hacked. Who knows, not very clear.
As has been proven many times before, "very sophisticated", "advanced", "highly complex" etc. actually generally means "our staff was humiliatingly negligent" in some regard. i.e. they were spearphished and the attacker pulled a password database from their internal network. It seems very odd that they resorted to resetting all passwords instead of just affected or potentially affected accounts as Github did recently.
Well since its a botnet that is trying to login with lots of different passwords and lots of different accounts its fairly obvious what the attack vector is. That's also why its safer to force a password reset than to just continue to reset passwords after they get compromised.
It doesn't sound like they have been hacked directly. This looks like the same things as TeamViewer where hackers are using password lists from other breaches to attempt to compromise the high value remote desktop targets.
There are two things that are rapidly becoming negligent not to offer:
- 2FA (mobile, yubikey, duo)
- basic monitoring and notification when login patterns change
These are both relatively simple and effective. You needn't force 2FA, but please offer it.
A password I shared across a couple of test accounts for various services was compromised when one of the sites storing cleartext passwords was popped.
A Microsoft account was the winner of the day - they notified me that a login from $home followed by a login from Brazil looked suspicious, and they were correct. This is basic and often effective.
The best part about running a cybersecurity company: lots of easy, free marketing. It's a really good time to be in the industry. It is unfortunate that people are trusting companies to protect their information and it ends up being really hard to do properly. Every able-bodied security engineer really should get in the game since there's money to be made as well as good to be done.
In a way I'm glad they got hacked. They'll learn the lesson by losing customers and $$$$. I'm guessing there was someone who said they should invest in security but management decided to save money.
What worries me is that this product is owned by Citrix.
Our company uses other products by Citrix extensively like GoToMeeting, Citrix applications etc. And if those products get compromised, then it will be a huge enterprise level financial loss.
I used to work on the security team at Citrix. It's a very competent team that does proactive security auditing, threat modeling, pen testing and developer training as well as response.
However, the "Go To" products (until a year or two ago) were part of Citrix Online, which operated independently of the rest of Citrix.
So I don't see this as a reflection of the security of Citrix's core products.
Aren't these remote access solutions primarily on demand and therefore coupled to a one-time password generated each time it's started? Isn't Chrome's remote access otp only? Maybe it's time to ask friends/family to use that instead.
I mean, if I want permanent remote access, then I'd set up a reasonably secure VPN solution that also required client side certificates, without the use of a trusted intermediary/proxy.
Interactive access to remote servers seems also to get less important with push/pull of configuration/deployment recipes and immutable deployment.
Teamviewer, for example, has a few use-scenarios, one of which is the unattended access, which is what appeared to be compromised. Essentially there was an always-on agent process running on the target machine that you could access with a Teamviewer account you set up; said account could manage any number of PCs that had always-on unattended access.
Teamviewer also has a "Quick Support" option, in which the application spawns a computer ID number and a theoretically one-time use password. The complexity of the password could be set within the application. Their QuickSupport tool, meant for a one-off support session, generates a unique session ID (in the past they had a static computer ID and a semi-unique password generated per client) which can be given to a support rep with the full version of Teamviewer to access.
I have not yet followed up on the Teamviewer issue so I cannot say exactly what was compromised there, though last I remember Teamviewer was insistent their service had not been compromised, but that the unauthorized access was the result of reused passwords.
GoToMyPC appears to be the former, an agent you install with the intent of unattended access on a whim. While server access is certainly one use scenario, access to non-server PCs for whatever reason is also a major part of these. Barring a breach of the software accounts or incompetently designed security for the remote access tools, it's probably okay for most people. Unfortunately, it seems like a breach is exactly what happened here with GoToMyPC, though as has been noted in the discussion already, the details are extremely sparse.
It's our responsibility to not configure hard to secure and easy to exploit remote access on friend/family computers but use on demand solutions instead.
If you need always-on remote access, then it's a requirement to secure it properly, and I will argue there's no need for always-on remote access on friend/family machines. Those aren't usually online anyway, so there's no hurdle to know beforehand and exchange the access token.
That said, I don't understand why anyone would trust an intermediary with access to their computer. Do they have a contract in place to expect a certain level of support and security? If not, there's no explanation I can think of.
I'm so glad I dropped gotomypc and went with rdp gateway. Their customer service is subpar. I tried reporting bugs and no one ever got back to me. I contact them on Twitter and email. Chirps! One day I had it enough and completely cancelled the service. There are better alternatives out there.
While I have not set it up personally, it seems if you were to get it up and running for them and have a relatively easy to remember domain, it shouldn't be too hard.
However, not having used it for a prolonged period, I don't know what the time investment for maintenance will be.
Just wait until IFTTT gets hacked. That has to be a huge target. Think of all the other services and physical devices on the network they'd potentially have the keys/access to.
