<ocdtrekkie>
I should take this opportunity to switch to Github as my login provider.
<ocdtrekkie>
paulproteus: Wouldn't it be catchy if it was possible to push out an app for Sandstorm that did this and blog about it right away in the aftermath of the LastPass hack?
<paulproteus>
In theory yes, but I can't get super excited about racing to package something as security-sensitive as a password manager.
<ocdtrekkie>
I don't use password managers though. I find the practice silly.
<ocdtrekkie>
That's a valid point, paulproteus
<paulproteus>
What I _should_ do is create a GitWeb repo on alpha.sandstorm.io for my passwords that I store in ~/.password-store/.git gpg-encrypted to me.
<ocdtrekkie>
I think if you're using a password manager for something security-sensitive, you're doing it wrong.
<mcpherrin>
ocdtrekkie: Do you memorize all your passwords then?
<ocdtrekkie>
mcpherrin: I do.
<mcpherrin>
I find I have way too many :|
<paulproteus>
I think something like http://www.passwordstore.org/ is pretty reasonable fwiw. (Leaving aside the lack of https.)
<mcpherrin>
But I also use large, randomly-generated passwords.
<ocdtrekkie>
mcpherrin: I use mnemonics.
<paulproteus>
Whoa pass is by The Cgit Person!? Who knew.
<ocdtrekkie>
I also have memorized most of the Dewey Decimal System, from a practical standpoint, so clearly my ability to memorize sequences of letters and numbers is at least above average.
<mcpherrin>
I tried a few schemes like that for a while but in the end I'd still forget -- especially ones I use once a year or so (health insurance etc)
<paulproteus>
Or my db.debian.org password, grumble.
<ocdtrekkie>
Also, I argue that the need for all passwords you use to be unique is debateable, at best.
<ocdtrekkie>
There is a very justifiable time and place for unique passwords, and an equally justifiable time and place to use the same password on about 500 websites.
<mcpherrin>
ocdtrekkie: One service losing my password and being used on another is the #1 threat in my model.
<kentonv>
It looks to me like the lastpass compromise is not sufficient to get access to people's lastpass-stored passwords unless they had a weak master password
<ocdtrekkie>
kentonv: And didn't use 2FA.
<kentonv>
actually I don't think 2FA would help anything in this case
<kentonv>
err
<kentonv>
well 2FA on the target sites would
<kentonv>
2FA on lastpass would not
<kentonv>
not sure if lastpass even has 2FA
<ocdtrekkie>
It does.
<ocdtrekkie>
The only password hashes stolen were LastPass passwords, not passwords used on other sites.
<kentonv>
if that's true, then having 2FA on lastpass should help, yeah
<ocdtrekkie>
So, even if you got those, and managed to crack them, you'd still be stuck behind 2FA to get other passwords out of LastPass.
<ocdtrekkie>
But that being said, this sort of compromise probably shouldn't happen with the company that holds all your other passwords.
<kentonv>
well, lastpass bases many security claims on the fact that password vaults are decrypted client-side
<kentonv>
but presumably the key to the vault is just your password, _not_ 2FA
<kentonv>
otherwise you'd lose everything if you lost your phone
<kentonv>
lastpass does say that you lose everything if you forget your master password
<ocdtrekkie>
mcpherrin: Basically, every website that does not compromise me as a person does not have a unique password, as there is little need for it to.
<ocdtrekkie>
If I register on a web forum, it does not need a unique password, because big whoop if someone hacks it.
<kentonv>
I would tend to assume that if attackers got access to any of lastpass's stored data, they got all of it, even if lastpass says otherwise. Probably the (encrypted) vaults would have been in lower-security storage than the login info, after all.
<ocdtrekkie>
Universally using unique passwords is just a way to overcomplicate yourself to the point of compromising your own security by storing your password somewhere.
<kentonv>
ocdtrekkie: if you use a password manager, then using unique passwords on every site is easy
<ocdtrekkie>
kentonv: But your passwords are then stored somewhere.
<ocdtrekkie>
And hence, compromised.
<iangreenleaf>
ocdtrekkie: Your threat model is super weird.
<kentonv>
if they're encrypted by a master password, then they are not compromised
<kentonv>
unless the master password is compromised
<kentonv>
but you don't tell that one to anyone
<iangreenleaf>
Why would you trust a huge pool of sites with the same password, but not trust LastPass with a single password to store a unique password for each of those sites?
<ocdtrekkie>
But all of that data, kentonv, is on LastPass's servers. A company which, as far as I know, can't brag even Google's level of security.
<ocdtrekkie>
iangreenleaf: I never said I trusted a huge pool of sites.
<kentonv>
literally no one can brag Google's level of security
<ocdtrekkie>
I said I didn't bother to take a security concern with them.
<kentonv>
lastpass only stores _encrypted_ data, and they do not have the key
<ocdtrekkie>
kentonv: And when Google's login info gets compromised, I will be the one person not at all surprised.
<iangreenleaf>
You're trusting each one of those sties with your login credentials for every other one of those sites.
<ocdtrekkie>
iangreenleaf: Sure, but none of those sites is a security risk.
<ocdtrekkie>
Meanwhile, I concern myself with a much smaller pool of passwords that are important.
<iangreenleaf>
So use LastPass for all of those sites and just don't give it your bank password…
<ocdtrekkie>
Email accounts, banks, etc.
<ocdtrekkie>
Why bother with that at all though, iangreenleaf?
<kentonv>
it's easy to underestimate how much your security on some sites matters
<iangreenleaf>
Because it's inarguably safer than what you're advocating?
<ocdtrekkie>
I registered for an account on a site in order to download a cover of a video game so I could print it and stick it in the case because, you know, I got a game without the label once. Why bother securing that?
<kentonv>
because often attackers can bootstrap up from a random web forum through, say, social engineering
<ocdtrekkie>
iangreenleaf: Sure, but you're securing something that doesn't need to and shouldn't be secured.
<kentonv>
if it's literally "some site forced me to register to perform one transaction and I'll never go back", then maybe it doesn't matter. It's safer not to assume, though.
<iangreenleaf>
Yeah, if it works for you, great. But I don't think you should be advocating your method to anyone else.
<ocdtrekkie>
kentonv: I would hope nobody can social engineering out my Google password from a forum account.
<ocdtrekkie>
If so, we have a bigger problem, and it's not my forum password. o_o
<kentonv>
in any case, ocdtrekkie, I use a password generator. No data is stored anywhere, I only remember one master password, and I get a unique password on every site. What are your thoughts on that?
<ocdtrekkie>
Is the password reproducibly generated every time, as opposed to stored, via some algorithm?
<kentonv>
yes
<ocdtrekkie>
That's arguably pretty good.
<mcpherrin>
The problem I've run into with generating passwords per-site is that they often have wacky password restrictions
achernya has quit [Ping timeout: 244 seconds]
<mcpherrin>
Perhaps a public database of password rules could help with that problem.
<kentonv>
ocdtrekkie: OK, well, crytographically speaking, what lastpass does is no less secure than what I do, because they only store encrypted data on their server, which is not usable unless you know the master password, and knowing the master password also compromises the generator approach.
<iangreenleaf>
kentonv: heh, I was just puzzling over if your method offered any stronger security that lastpass
<kentonv>
mcpherrin: My generator makes sure to follow common rules like requiring a capital, a lower-case, and a digit. Only a tiny set of sites seem to have trouble with it.
<ocdtrekkie>
kentonv: I think there's a few more layers in Lastpass's system that could potentially be compromised.
<kentonv>
iangreenleaf: I consider my approach to have mainly availability benefits, not so much security.
<iangreenleaf>
Yeah, makes sense. It's Good Enough security either way, just depends which you consider more convenient.
<ocdtrekkie>
kentonv: Is this commonly distributed software, or do you roll your own?
<kentonv>
I also think it has a tinfoil hat benefit in that I wrote the code, not Lastpass, so I'm not trusting anyone. But in practice we all have to trust people to get work done.
NwS has quit [Ping timeout: 265 seconds]
<ocdtrekkie>
Nevermind.
<ocdtrekkie>
Question answered.
<kentonv>
it's just a few lines of shell script
<kentonv>
arguably I screwed up by using a fast hash rather than a password hash, but I'm saved by the fact that my master password is excessively long.
<ocdtrekkie>
While I don't end up writing a ton of my own code, I vastly prefer less layers of code to potentially have flaws.
<kentonv>
my method has low key agility, which arguably makes it inferior to lastpass.
<kentonv>
that is to say, I cannot change my master password without changing _all_ of my site passwords.
<ocdtrekkie>
However, barring having a keylogger on your system, your master password does not go anywhere and is not stored anywhere, which reduces the likelihood of it being compromised.
<ocdtrekkie>
zarvox: Why would existing apps need to be "switched" to vagrant-spk? I assumed the resulting output was largely identical.
<kentonv>
ocdtrekkie: your master password with lastpass never hits the lastpass servers. A salted-hashed version does. Meanwhile, technically, a salted-hashed version of my master password lands on every site I use, because that's exactly how I generate the per-site passwords.
<kentonv>
(or at least, that's what they claim; I haven't read their code)
<kentonv>
ocdtrekkie: zarvox wants to switch some of the apps we maintain to vagrant-spk for maintenance and testing reasons.
<kentonv>
or "dogfooding", I suppose
<zarvox>
ocdtrekkie: it'd be broadly "making sure you can go from Debian Jessie VM to working spk in a more automated fashion"
<ocdtrekkie>
I mean, what exactly is entailed in 'switching'? What's the difference between the Github repo of an spk built app and a vagrant-spk built app?
<zarvox>
a .sandstorm folder with a Vagrantfile, and explicit installation of any dependencies or build-dependencies in setup.sh and build.sh
<kentonv>
ocdtrekkie: from the end user's point of view, nothing
<kentonv>
(ideally)
<kentonv>
it matters to the app maintainer
<zarvox>
rather than a README explaining how to build the package, or checking in binaries, an agreed-upon well-known path with scripts that do those steps
<zarvox>
the goal is partly to get more uniformity in how things are packaged, and have fewer manual steps for someone who comes along later and wants to build the same package
<zarvox>
another future goal is to have buildbots, which requires there be no steps that need human intervention, and consistency in entry points/FS layouts/etc.
erikoeurch has quit [Ping timeout: 252 seconds]
<ocdtrekkie>
So an output SPK file from vagrant-spk should be (essentially) identical to one made with spk, except for some standardized filenames?
<paulproteus>
Ya
<zarvox>
Basically. Ultimately, vagrant-spk uses spk in a VM to accomplish its task.
posix4e has joined #sandstorm
<posix4e>
Should have moved from lastpass to gitlab + gpg on my own server years ago
<posix4e>
so much better
<posix4e>
Thanks sandstorm!
<paulproteus>
: D posix4e
<posix4e>
It's too bad there's no gpg tit for tat distributed backup system out there
<posix4e>
ideally everyone could just backup sandstorm to each other encrypted
<ocdtrekkie>
I'd rather just backup to my off-site system.
<paulproteus>
posix4e: You might like tahoe-lafs.org fwiw!
<paulproteus>
Having said that I don't use it and feel kind of like ocdtrekkie .
mort___ has joined #sandstorm
<paulproteus>
Yargh, email-based RPC.
<paulproteus>
I used to think this was a good idea.
<paulproteus>
(also does this reveal the existence of oasis!!???)
<paulproteus>
Anyway this is where I'm brainstorming a possible talk or two (!??) by Asheesh at Debconf.
<ocdtrekkie>
paulproteus: It was linked to in the meeting notes.
<ocdtrekkie>
So no data leak. :D
<paulproteus>
Yeah, I realized that before I hit enter (-:
<ocdtrekkie>
You guys need a snazzy migration script from Alpha for me.
<ocdtrekkie>
:P
<ocdtrekkie>
I wanna change login providers too though.
<paulproteus>
ocdtrekkie: I need that too!
<ocdtrekkie>
So is oasis considered at least as stable as the alpha server I've come to enjoy so much?
<paulproteus>
My hunch so far is "no"! I'll let kentonv be the one to really answer.
mort___ has joined #sandstorm
<ocdtrekkie>
I'm gonna have to figure out where all the alpha links I've given out to people are.
posix4e has left #sandstorm ["WeeChat 0.4.2"]
<paulproteus>
Yeah. Maybe we can have redirects or something at some point.
<ocdtrekkie>
Likely unreasonable suggestion: some sort of migration of actual database info from alpha to oasis so alpha can be a redirect and all the keys and grain IDs still match.
<paulproteus>
I for one like that idea.
<ocdtrekkie>
I assume all of the unique IDs would be fine, and the user identities should be identical anyways, but I don't know how many things in the database would actually just break horribly.