Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Wed, Feb 13, 2019 at 4:34 PM Mark David Dumlao wrote: > > On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman wrote: > > > > If you instead let the user code their own algorithm, then while this > > increases complexity, it also makes it easy for users to shoot > > themselves in the feet with an insecure algorithm. > > > > And on second point, you can completely automate simply running > lesspass, whereas to automate cracking an unknown algorithm you would > have to automate writing arbitrary programs, which is in theory > reducible to the halting problem. TLDR: you probably can't. Only if the algorithm the user chooses is secure. If they pick something equivalent to ROT13 then the attacker's problem becomes easier. That was my point, and users aren't necessarily good at picking secure algorithms. Now, if they just copy/paste one off the website, then they become open to attacks that check the commonly used algorithms. > > The problem with "as-needed" is that you have to remember which > > accounts use which master password. That sounds simple until you have > > 100 different accounts. > > In the algorithmic approach, you don't have to change your master > password per iteration. Your algorithm can take iterations into > account to use the same secret to generate an Nth iteration. For > instance, using iteration numbers as part of a site-specific ID. Of course, but my point is that if you ever DO have to change the master password it is a mess. Maybe you have to change it because somebody beat it out of you with a hose. Or maybe you accidentally typed it into the wrong window. Or maybe somebody stole it with a sniffer. Or whatever. My point is that if it fails then it is more painful to recover. If you lose your master password on a database-backed solution and the database isn't compromised, then you just change your password. If the database is compromised then you also have to change all your site passwords, but as you change them the database maintains state and you can forget the old master password the moment it is changed. It is just a pro/con of the approach - individuals can judge the overall merits. -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman wrote: > > On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao wrote: > > > > On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman wrote: > > > I just stumbled on lesspass which seems to be such a tool for > > > algorithmic password generation (lesspass.com). > > > > Great tool. Good to know there are those that think alike. One > > important point though is that in my "version", the user has to > > completely know a secure algorithm (which is where all the security > > comes from), with a managed tool this is only feasible for technical > > users (or at least technical past a certain level). A version of > > lesspass that allows users to view and customize the secret-generation > > algorithm would be much more secure. > > Maybe. Here is the problem with this: > > If you just give the user a choice of one of several secure algorithms > to use, then basically all you're doing is adding a few more bits of > entropy to the mix. You also have to deal with vulnerabilities in any > algorithm your software uses, and not just the one you picked. > > If you instead let the user code their own algorithm, then while this > increases complexity, it also makes it easy for users to shoot > themselves in the feet with an insecure algorithm. > > I think it would make more sense for users to focus on more robust > master keys than to rely on security by obscurity with an algorithm > that doesn't benefit from peer review. Changing (or rather customizing) algorithms is not security by obscurity. While it may be true that at the end of the day you're adding bits of entropy, the fact is the freeform nature of design implies the number of bits of entropy you are adding could very easily exceed any humane password. And on second point, you can completely automate simply running lesspass, whereas to automate cracking an unknown algorithm you would have to automate writing arbitrary programs, which is in theory reducible to the halting problem. TLDR: you probably can't. > While any master password should be secure, the algorithmic approaches > suffer more, IMO. With something like Keepass or Lastpass you need > both the database and the master password to do an attack. Now, with > lastpass anybody with the master password can obtain the database from > the cloud, but they're going to throttle attacks or lock the account > after so many failures, and you have nothing to crack offline. > Lastpass would be vulnerable to intruders stealing the database of > course, which then reduces the difficulty of an attack to the same as > something like Lesspass. That's technically correct, which is why I would suggest a custom-designed algorithm as opposed to something like lesspass. With lesspass all the security directly goes to your secret, so the pressure to make the secret ridiculous is huge. With your own algorithm, the algorithm itself adds entropy between your secret and the generated password. Consider: - to crack a lesspass secret, you can bruteforce the lesspass secret and check if they produce a valid output. On any success, you're 99.99x% certain to have cracked the original lesspass secret, which will instantly work on other sites. - to crack an arbitrary algorithm, it is insufficient to bruteforce an input secret because by itsef it does not produce an output secret. You would also have to bruteforce different transformation algorithms that map from the input secret to the output secret. Even if you end up producing a valid password, you cannot guarantee that thje guessed algorithm works on other accounts, because it might simply be a collision, which is indistinguishable from the algorithm being wrong due to missing some site-specific rules. > > > > > > 4. I'm not sure how straightforward it would be to change > > > passwords/etc. If you have 100 sites, you'd have to remember what > > > password you used for what site, or change them all at once. Again, > > > the stateless approach has its downsides as passwords are not > > > stateless from the standpoint of the remote sites. > > > > Actually the generation approach is massively simpler since the > > passwords themselves don't matter. If you don't like your secret, are > > not sure which iteration a site is, are not sure if a site used an old > > or new secret, etc, you can trigger a password reset on most services > > and force it to use the current generated password. You can update any > > passwords on an as-needed basis to always use the current generated > > iteration. > > The problem with "as-needed" is that you have to remember which > accounts use which master password. That sounds simple until you have > 100 different accounts. The point of an approach like this is to reduce the number of secrets, ideally, to only a handful, in practice only to one. Thus you don't need to remember which account uses which master password because just like keepass there is just one. I have over 100 different accounts (software
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao wrote: > > On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman wrote: > > I just stumbled on lesspass which seems to be such a tool for > > algorithmic password generation (lesspass.com). > > Great tool. Good to know there are those that think alike. One > important point though is that in my "version", the user has to > completely know a secure algorithm (which is where all the security > comes from), with a managed tool this is only feasible for technical > users (or at least technical past a certain level). A version of > lesspass that allows users to view and customize the secret-generation > algorithm would be much more secure. Maybe. Here is the problem with this: If you just give the user a choice of one of several secure algorithms to use, then basically all you're doing is adding a few more bits of entropy to the mix. You also have to deal with vulnerabilities in any algorithm your software uses, and not just the one you picked. If you instead let the user code their own algorithm, then while this increases complexity, it also makes it easy for users to shoot themselves in the feet with an insecure algorithm. I think it would make more sense for users to focus on more robust master keys than to rely on security by obscurity with an algorithm that doesn't benefit from peer review. > > 2. The solution does allow incremental counters for sites, but of > > course that is basically state and it looks like they have a way to > > sync this somewhere, but of course that means having a cloud sync > > infrastructure and that info could get compromised (doesn't include > > the passwords themselves). > > Also not an issue for me in practice. In practice you also remembr > which sites forced you to change passwords, since they're pretty much > the only ones in that class. Sure, assuming you don't regularly change your passwords everywhere. I'm not sure that this is as important with manager-generated passwords, but it is a consideration. > Likewise, > your keepass / lesspass secrets should probably be some insane > paranoid level secret that themselves don't come from keepass / > lesspass and their alternatives. While any master password should be secure, the algorithmic approaches suffer more, IMO. With something like Keepass or Lastpass you need both the database and the master password to do an attack. Now, with lastpass anybody with the master password can obtain the database from the cloud, but they're going to throttle attacks or lock the account after so many failures, and you have nothing to crack offline. Lastpass would be vulnerable to intruders stealing the database of course, which then reduces the difficulty of an attack to the same as something like Lesspass. > > > 4. I'm not sure how straightforward it would be to change > > passwords/etc. If you have 100 sites, you'd have to remember what > > password you used for what site, or change them all at once. Again, > > the stateless approach has its downsides as passwords are not > > stateless from the standpoint of the remote sites. > > Actually the generation approach is massively simpler since the > passwords themselves don't matter. If you don't like your secret, are > not sure which iteration a site is, are not sure if a site used an old > or new secret, etc, you can trigger a password reset on most services > and force it to use the current generated password. You can update any > passwords on an as-needed basis to always use the current generated > iteration. The problem with "as-needed" is that you have to remember which accounts use which master password. That sounds simple until you have 100 different accounts. My password manager has a huge number of accounts in it. Granted, some of those are more disposable than others, but keep in mind that everything from the local burger chain to your bank has a password these days. Either that, or it supports something even worse like Facebook authentication. I'm all for SSO, but not ones locked into a single provider, and especially not Facebook. > > Password incrementing is an issue for any algorithmic solution - you > > need to be able to remember which password version is in use on what > > site. > > If you're talking about remembering the iteration counter for a > particular site, well, yes you have to store state somewhere. But > consider: > 1 very strong secret + remember that these 3 or 4 sites are on iteration X > > is a LOT less headspace than > 4+ independent strong secrets Sure, but I'm mostly comparing altorithmic password managers to database-based ones. In neither case are you remembering hundreds of passwords. > > and I'm pretty sure most people have logins on more than 4 sites. > > If literally the only state you need to know about a site is the Nth > iteration, I wouldn't mind cloud providers knowing that because they > can't do anything about that number. > It still means having a need to sync state, that
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman wrote: > > > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: > > > > > >> My own solution is actually very simple. I have a "secret algorithm" > > >> that incorporates several secrets with a predictable way to generate a > > >> site-specific secret. The end result is a 100% predictable way to > > >> generate unique passwords for every site that are cryptographically > > >> secure from each other (you cannot derive > > >> one from the other) which can be generated by any device using the > > >> appropriate tools. > I just stumbled on lesspass which seems to be such a tool for > algorithmic password generation (lesspass.com). Great tool. Good to know there are those that think alike. One important point though is that in my "version", the user has to completely know a secure algorithm (which is where all the security comes from), with a managed tool this is only feasible for technical users (or at least technical past a certain level). A version of lesspass that allows users to view and customize the secret-generation algorithm would be much more secure. Or another way to put it might be: if an attacker knows that you're using lesspass, then the only encryption they have to break is that on your master password, so your security is only as strong as your master password. On the other hand, if an attacker knows that I am using an algorithm-generating technique, they need to break both the master secret AND the algorithm, which could have vastly more entropy than the master secret itself. > > Some thoughts regarding this approach: > > 1. Remembering the right "site name" for every site might be tricky - > sites change names/URLs and you won't have any database to search. In my personal practice, not a problem. In practice you always remember the old site name for any common enough site. If you don't, you reset the password to the new site name. > 2. The solution does allow incremental counters for sites, but of > course that is basically state and it looks like they have a way to > sync this somewhere, but of course that means having a cloud sync > infrastructure and that info could get compromised (doesn't include > the passwords themselves). Also not an issue for me in practice. In practice you also remembr which sites forced you to change passwords, since they're pretty much the only ones in that class. > 3. Master password complexity probably matters more than for > something like Lastpass/KeepassX. With traditional password managers > you need the database plus you need to crack the master password (or > get it some other way). With a purely algorithmic approach you can > probably guess at all the parameters other than the master password, > so anybody can try to crack you without stealing any data at all, This is an issue for lesspass, because the only secret is the master password. This is not an issue for algorithmic approaches in general, because the algorithm is part of the secret. Every which way that you choose to encode the intermediary steps in my example above is also part of the secret, because none of those can be guessed from the resulting password. As an example, encoding "madum...@gmail.com" as the site-specific identifier would give a completely different password than "gmail:madumlao" or "madumlao@gmail" or "madumlao+gmail", etc. And that hasn't yet counted any peppering which influences intermediary hashes. That being said, any system that depends on a master password had better be goddamned secure. In fact, my email account - which is a resetting point for basically all services - is exempt from my password algorithm and uses some ridiculously long secret. Likewise, your keepass / lesspass secrets should probably be some insane paranoid level secret that themselves don't come from keepass / lesspass and their alternatives. > 4. I'm not sure how straightforward it would be to change > passwords/etc. If you have 100 sites, you'd have to remember what > password you used for what site, or change them all at once. Again, > the stateless approach has its downsides as passwords are not > stateless from the standpoint of the remote sites. Actually the generation approach is massively simpler since the passwords themselves don't matter. If you don't like your secret, are not sure which iteration a site is, are not sure if a site used an old or new secret, etc, you can trigger a password reset on most services and force it to use the current generated password. You can update any passwords on an as-needed basis to always use the current generated iteration. > If you do increment passwords, well, now you just introduced state > back in, and the "stateless" solution isn't really so. > > Password incrementing is an issue for any algorithmic solution - you > need to be able to remember which password version is in use on what > site. If you're talking about remembering the iteration counter for a particular site, well,
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Fri, Feb 8, 2019 at 9:26 AM Kai Peter wrote: > > On 2019-02-05 22:17, Neil Bothwick wrote: > > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: > > > >> My own solution is actually very simple. I have a "secret algorithm" > >> that incorporates several secrets with a predictable way to generate a > >> site-specific secret. The end result is a 100% predictable way to > >> generate unique passwords for every site that are cryptographically > >> secure from each other (you cannot derive > >> one from the other) which can be generated by any device using the > >> appropriate tools. > > > > The was a tool in portage this did this. I tried it but it did not work > > in the real world because you couldn't set a rule for generated > > passwords > > that matched the requirements of all sites, for example some require a > > non-alphanumeric character while other sites only allow alphanumerics. > > > > I can remember what the tools was called, although I'm pretty sure it > > was written in Python. I'd be interested to know how you get around the > > conflicting restrictions as this seems a good way to do things. > > By using an existing tool you have to live with its restrictions always. > But who says that it could not be done? At least Mark's solution will > (maybe) not work for everybody (yet), but he did think about an issue > and found a way/solution which sounds really reasonable. > I just stumbled on lesspass which seems to be such a tool for algorithmic password generation (lesspass.com). Some thoughts regarding this approach: 1. Remembering the right "site name" for every site might be tricky - sites change names/URLs and you won't have any database to search. 2. The solution does allow incremental counters for sites, but of course that is basically state and it looks like they have a way to sync this somewhere, but of course that means having a cloud sync infrastructure and that info could get compromised (doesn't include the passwords themselves). 3. Master password complexity probably matters more than for something like Lastpass/KeepassX. With traditional password managers you need the database plus you need to crack the master password (or get it some other way). With a purely algorithmic approach you can probably guess at all the parameters other than the master password, so anybody can try to crack you without stealing any data at all, assuming they think you're using the algorithm. It sounds like the hashing system they're using is considered secure, but it is obviously only as good as the master password. 4. I'm not sure how straightforward it would be to change passwords/etc. If you have 100 sites, you'd have to remember what password you used for what site, or change them all at once. Again, the stateless approach has its downsides as passwords are not stateless from the standpoint of the remote sites. The big upside to stateless is that if you never increment passwords then as long as you remember your master password you always have access to your password everywhere, with nothing to back up. If you do increment passwords, well, now you just introduced state back in, and the "stateless" solution isn't really so. Password incrementing is an issue for any algorithmic solution - you need to be able to remember which password version is in use on what site. -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Sat, Feb 09, 2019 at 04:42:42AM -0600, Dale wrote: > > It seems you just put yours on a stick as plain text. If you trust your > safe, that should be fine. Since I have mine on my system, I encrypt > it. It may be easier to do it your way tho. At least easier for > whoever comes after me. I do the same thing, except mine are printed off and in the safe. IMO it boils down to what you're trying to defend against; if someone cracks your safe passwords are probably the last thing to worry about. I'd imagine by getting into someone's safe you could get enough documents (birth certificates, passports, etc.) to be able to get through to customer service and change passwords anyways. Of course all my passwords that are stored on my computer are encrypted since only I need to use those :D Alec
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Neil Bothwick wrote: > On Fri, 8 Feb 2019 18:19:26 -0600, Dale wrote: > >> I suspect that anyone trying to hack us Linux users, users of this list >> especially, would have a rough road ahead of them. Based on replies >> here, some have some pretty good methods of coming up with a password. >> Let us hope none of us dies instantly and takes the passwords with us. >> o_O I put mine in a fire safe. Just in case. > Does LastPass have an export option? With KeePassXC, I can export all my > passwords to a CSV file that I save to a USB stick I keep in my safe. > > Yes it does. I export mine when I do major changes, usually when I do financial sites. It exports it as plain text. I then copy and paste it into a text file and encrypt it with KGpg. At that point, you still need the password to decrypt it, and I guess this computer tho it may be doable on another system with the keys. As I mentioned before, there's a lot I don't know about this encryption stuff still. I may get me a tiny USB stick and put the master password, keys and such on it. I'm sure you know more about this than I do, what all do I need in case it has to be done on another system? In other words, what all would I need to copy over to the USB stick? It seems you just put yours on a stick as plain text. If you trust your safe, that should be fine. Since I have mine on my system, I encrypt it. It may be easier to do it your way tho. At least easier for whoever comes after me. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Fri, 8 Feb 2019 18:19:26 -0600, Dale wrote: > I suspect that anyone trying to hack us Linux users, users of this list > especially, would have a rough road ahead of them. Based on replies > here, some have some pretty good methods of coming up with a password. > Let us hope none of us dies instantly and takes the passwords with us. > o_O I put mine in a fire safe. Just in case. Does LastPass have an export option? With KeePassXC, I can export all my passwords to a CSV file that I save to a USB stick I keep in my safe. -- Neil Bothwick Downloading - A quick way of catching a virus from anywhere in the world. pgpyGNqrguIWP.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Neil Bothwick wrote: > On Fri, 08 Feb 2019 15:26:22 +0100, Kai Peter wrote: > >>> The was a tool in portage this did this. I tried it but it did not >>> work in the real world because you couldn't set a rule for generated >>> passwords >>> that matched the requirements of all sites, for example some require a >>> non-alphanumeric character while other sites only allow alphanumerics. >>> >>> I can remember what the tools was called, although I'm pretty sure it >>> was written in Python. I'd be interested to know how you get around >>> the conflicting restrictions as this seems a good way to do things. >> By using an existing tool you have to live with its restrictions >> always. But who says that it could not be done? > It wasn't so much a restriction in the tool as the sites, which have > conflicting requirements for passwords - especially the ones that have a > MAXIMUM password length. > > This is something I've ran into on several occasions using LastPass' generation tool. Some sites allow the symbols, letters above the number keys, but don't allow one or more specific ones. A couple examples, the "!" key is a common one not allowed. Others that are sometimes excluded are the "$" and "*" symbols. So I end up telling LastPass to generate passwords until it gets one without any of those characters or I turn off the symbols all together. Of course, turning those off makes a password easier to crack/hack. I did run up on one site recently that allowed any character, all symbols included, and could be as long as 60 characters. I think spaces was the only thing on the keyboard not allowed. Thing is, it wouldn't accept anything longer than 28 or so for me. I started out at 40 and kept dropping down a few digits until I hit the one it would accept. If it had accepted a random password that long with symbols included, I would think hackers would have to attack something besides the password. That is one long password. I've seen paragraphs shorter than that. According to a couple of the test sites, it would take trillions of years to crack a 40 digit password much less 60. Pretty hard thing to get past. What surprises me, a couple sites that I would like to have longer passwords on, won't accept anything longer than a couple dozen characters. I wish all financial sites would take 60 or so like the other one I use. I'm not sure why they limit it to that number. Common software limit maybe? This is one thing about having so many different password tools and each person picking what they like. It makes it harder to figure out how passwords are generated and tracked. Each tool has its own methods. It's sort of like the password strength sites. I didn't rely on one site. I used several plus some common sense as well. If all sites think a password will take thousands of years or more to crack, it is likely a good password. Then apply some common sense to confirm it of course. I ended up with a password that was easier to type and very strong, even stronger than what I started with. The odds of someone just guessing it is virtually zero. The things it is based on is not something anyone other than me would likely consider for creating a password. It's not pets, family names, date of births or anything like that. Heck, even if someone was sitting in my chair, they would be clueless. Even people who know me best would never be able to figure out what it is based on much less how I put it in the password or which ones. Thing is, I think I'll be able to remember it easy enough. I suspect that anyone trying to hack us Linux users, users of this list especially, would have a rough road ahead of them. Based on replies here, some have some pretty good methods of coming up with a password. Let us hope none of us dies instantly and takes the passwords with us. o_O I put mine in a fire safe. Just in case. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Fri, 08 Feb 2019 15:26:22 +0100, Kai Peter wrote: > > The was a tool in portage this did this. I tried it but it did not > > work in the real world because you couldn't set a rule for generated > > passwords > > that matched the requirements of all sites, for example some require a > > non-alphanumeric character while other sites only allow alphanumerics. > > > > I can remember what the tools was called, although I'm pretty sure it > > was written in Python. I'd be interested to know how you get around > > the conflicting restrictions as this seems a good way to do things. > > By using an existing tool you have to live with its restrictions > always. But who says that it could not be done? It wasn't so much a restriction in the tool as the sites, which have conflicting requirements for passwords - especially the ones that have a MAXIMUM password length. -- Neil Bothwick Despite the cost of living, have you noticed how it remains so popular? pgplKaP0xdS3t.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On 2019-02-05 22:17, Neil Bothwick wrote: On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: My own solution is actually very simple. I have a "secret algorithm" that incorporates several secrets with a predictable way to generate a site-specific secret. The end result is a 100% predictable way to generate unique passwords for every site that are cryptographically secure from each other (you cannot derive one from the other) which can be generated by any device using the appropriate tools. The was a tool in portage this did this. I tried it but it did not work in the real world because you couldn't set a rule for generated passwords that matched the requirements of all sites, for example some require a non-alphanumeric character while other sites only allow alphanumerics. I can remember what the tools was called, although I'm pretty sure it was written in Python. I'd be interested to know how you get around the conflicting restrictions as this seems a good way to do things. By using an existing tool you have to live with its restrictions always. But who says that it could not be done? At least Mark's solution will (maybe) not work for everybody (yet), but he did think about an issue and found a way/solution which sounds really reasonable. -- Sent with eQmail-1.11 beta - a fork of djb's famous qmail
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Wed, Feb 6, 2019 at 5:18 AM Neil Bothwick wrote: > > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: > > > My own solution is actually very simple. I have a "secret algorithm" > > that incorporates several secrets with a predictable way to generate a > > site-specific secret. The end result is a 100% predictable way to > > generate unique passwords for every site that are cryptographically > > secure from each other (you cannot derive > > one from the other) which can be generated by any device using the > > appropriate tools. > > The was a tool in portage this did this. I tried it but it did not work > in the real world because you couldn't set a rule for generated passwords > that matched the requirements of all sites, for example some require a > non-alphanumeric character while other sites only allow alphanumerics. > > I can remember what the tools was called, although I'm pretty sure it > was written in Python. I'd be interested to know how you get around the > conflicting restrictions as this seems a good way to do things. > Well the original idea is to reduce dependency on specific tools, such that the algorithm is the secret, and the passwords are just byproducts of the secret. You will still need tools to do any hashing, but those are generic tools you can acquire anywhere. So for example, the "password123" equivalent secret algorithm might be: 1) global pepper: "password" 3) site-specific pepper: pepper plus number = vowels in domain name 2) site-specific ID: pepper dot domain name dot username 4) hashing algorithm: md5sum + base64, take first 8 Example application: madum...@gmail.com 1) site-specific pepper: pepper3 (3 vowels in domain name: google) 2) site-specific ID: pepper3.google.madumlao 3) site-specific hash: (2) -> md5sum -> base64 -> first8 -> NGI3MTQz 4) combined with global pepper: password.NGI3MTQz 5) hashed with global pepper: (4) -> md5sum -> base64 -> first8 -> MWJjZjg2 password: MWJjZjg2 Example application: madum...@yahoo.com 1) site-specific pepper: pepper3 (3 vowels in domain name: yahoo) 2) site-specific ID: pepper3.yahoo.madumlao 3) site-specific hash: (2) -> md5sum -> base64 -> first8 -> ZDQzZGM5 4) combined with global pepper: password.ZDQzZGM5 5) hashed with global pepper: (4) -> md5sum -> base64 -> first8 -> ZjUwMTI2 password: ZjUwMTI2 The procedure takes up a little more headspace than 1 password, but definitely less headspace than a dozen cryptographically secure passwords. You can change the hashing algorithm, peppering rule, ID rule, number of characters, etc to your tastes. You can add iteration rules for the nth password change anywhere in the procedure, and add constraint rules for sites that have certain password limitations (the caveat is that you have to remember which sites have password changes and constraints). For me really all that matters is that the building blocks are widely available and the end result incorporates data loss that makes it impossible to recover the original secrets. "Obviously" do not use this algorithm as-is. The algorithm, not the password, is the secret, so using this algorithm as is is the equivalent of using any example of a crypto secure password (correct horse battery stapler) as a password. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: > My own solution is actually very simple. I have a "secret algorithm" > that incorporates several secrets with a predictable way to generate a > site-specific secret. The end result is a 100% predictable way to > generate unique passwords for every site that are cryptographically > secure from each other (you cannot derive > one from the other) which can be generated by any device using the > appropriate tools. The was a tool in portage this did this. I tried it but it did not work in the real world because you couldn't set a rule for generated passwords that matched the requirements of all sites, for example some require a non-alphanumeric character while other sites only allow alphanumerics. I can remember what the tools was called, although I'm pretty sure it was written in Python. I'd be interested to know how you get around the conflicting restrictions as this seems a good way to do things. -- Neil Bothwick MIPS: Meaningless Indication of Processor Speed pgpfxOzY7wyil.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Tue, Feb 5, 2019 at 3:39 AM Jack wrote: > The problem I have with many of these suggestions is that I have > multiple devices (two desktops, two laptops, tablet, android phone) I > use sufficiently often that I either need to be able to remember the > passwords or have some way of easily accessing them when I'm not > sitting at my main desktop. Other than using a password manager (which > I do not currently have) how to others deal with this? > > Jack Haven't posted here in a long while. I personally do not trust password managers for (1) the same reason you gave above and (2) typically the way around it is they store your passwords in the cloud which is all sorts of facepalm from a security perspective. My own solution is actually very simple. I have a "secret algorithm" that incorporates several secrets with a predictable way to generate a site-specific secret. The end result is a 100% predictable way to generate unique passwords for every site that are cryptographically secure from each other (you cannot derive one from the other) which can be generated by any device using the appropriate tools. There is also a protocol for password shifting in case any single password is revealed. The long and short of it is that you can combine secure passwords with hashing techniques, site-specific data, and truncation / peppering in a predetermined way that is easy for you to remember but guarantees that the original secret data is irrecoverable. Then all you need is the hashing program on, say, your phone, and you will always be able to generate the site-specific password when needed. In effect the algorithm is your secret, the site-specific password is just a side effect of that secret. -- This email is:[ ] actionable [x] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Rich Freeman wrote: > On Tue, Feb 5, 2019 at 2:34 AM Dale wrote: >> Rich Freeman wrote: >>> On Mon, Feb 4, 2019 at 5:12 PM Dale wrote: Neil Bothwick wrote: > On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > >>> One reason I use LastPass, it is mobile. I can go to someone else's >>> computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, >>> logoff and it is like I was never there. >> As much as I like Lastpass I would never do that. It isn't magic - it >> is javascript. If there is a compromise on your computer, then your >> password database will be compromised. This is true of other >> solutions like KeePassX and so on - if something roots your box then >> it will be compromised. I might point out, LastPass encrypts the password before sticking it in a file. It isn't visible or plain text. Even getting the file would still require some tools and cracking to get the password itself. >>> That assumes you're attacking the password file directly. >>> >>> If you're using lastpass on a compromised system then there are many >>> ways that can be used to bypass the encryptions. They could sniff >>> your master password when you key it in, or read it directly from the >>> browser's memory. These things are protected from sandboxed code in >>> your browser, but not from processes running outside the browser >>> (unless again you're using a non-conventional privilege system like >>> selinux/android/etc). >> One could argue the same thing with any password tool out there tho, >> right? > Of course. This is by no means specific to Lastpass. I wasn't > reacting to your use of Lastpass (I use it myself). I was reacting to > your statement that you can go to someone else's computer and use > lastpass on that computer and then log off and it is as if you were > never there. What I meant was, they couldn't use it without knowing my password. Sure, I may leave something, like LastPass installed but disabled, on their computer but no one can use it without it being logged in. Once I logout and close the browser, that pretty much ends the session. Most sites I visit are not set to remember me anyway and some don't allow it. I also logout before leaving a site especially when I'm on a computer other than mine. So, once I logout, they can't login as me without my password. We sort of went in different directions. If I really wanted to, I could use some bootable media like Knoppix. I think it comes with Firefox already installed. I could boot that, install LastPass, do my thing, reboot into the OS and not have to worry about anything they have installed at all. I do keep copies of those around and try to update every once in a while. I certainly keep sysrescue up to date. I don't think it has a browser tho. It may but I'm not sure. >> Given I only install things from >> trusted sources, the odds of that happening are likely very small. > Not if you go typing your Lastpass master password into computers > owned by people who aren't as careful as you are... > > If you do want the benefits of a password manager on an untrusted > computer then you might want to look into the hardware/USB-based > solutions, or alternatives like U2F and so on. > > Now, you're still vulnerable to MITM attacks and so on against the > sites you're actually logging into, but your credentials for other > sites would not be at risk since they stay on the hardware device, > which is going to be hardened against USB attacks (well, at least you > hope it would be). If you're using conventional passwords then of > course something could still sniff that password since it has to pass > through the untrusted computer. If you're using OTPs or U2F/etc then > you may still be vulnerable to some cookie-based attacks and MITM and > so on, but if you log off at the end of your session that at least > limits their duration. > > Personally I would like to switch to a hardware-based solution, but > they have their own set of downsides: > > 1. Less convenience - you have to physically have the device on you > (I don't carry my keys around in the hosue/etc), and plug it in when > you want to use it. > 2. Recovery options aren't always great. Often these devices don't > really have their own recovery solution, and you're stuck following > the recovery options on each individual site. Many of these are > pretty lousy. > 3. Often no support for multiple hardware devices (and keeping them > in sync). Again you're stuck with what individual sites allow, and > many sites don't let you have multiple hardware tokens registered. > 4. Lack of convenience features like auto-changing passwords. Some > software-based solutions have this. Though, to be honest, I rarely > trust these because if something goes wrong I could lose account > access and this can be difficult or impossible to recover from in many > situations. > > A big advantage (and disadvantage) of the
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Tue, Feb 5, 2019 at 2:34 AM Dale wrote: > > Rich Freeman wrote: > > On Mon, Feb 4, 2019 at 5:12 PM Dale wrote: > >> Neil Bothwick wrote: > >>> On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > >>> > > One reason I use LastPass, it is mobile. I can go to someone else's > > computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > > logoff and it is like I was never there. > As much as I like Lastpass I would never do that. It isn't magic - it > is javascript. If there is a compromise on your computer, then your > password database will be compromised. This is true of other > solutions like KeePassX and so on - if something roots your box then > it will be compromised. > > > >> I might point out, LastPass encrypts the password before sticking it in > >> a file. It isn't visible or plain text. Even getting the file would > >> still require some tools and cracking to get the password itself. > > That assumes you're attacking the password file directly. > > > > If you're using lastpass on a compromised system then there are many > > ways that can be used to bypass the encryptions. They could sniff > > your master password when you key it in, or read it directly from the > > browser's memory. These things are protected from sandboxed code in > > your browser, but not from processes running outside the browser > > (unless again you're using a non-conventional privilege system like > > selinux/android/etc). > > One could argue the same thing with any password tool out there tho, > right? Of course. This is by no means specific to Lastpass. I wasn't reacting to your use of Lastpass (I use it myself). I was reacting to your statement that you can go to someone else's computer and use lastpass on that computer and then log off and it is as if you were never there. > Given I only install things from > trusted sources, the odds of that happening are likely very small. Not if you go typing your Lastpass master password into computers owned by people who aren't as careful as you are... If you do want the benefits of a password manager on an untrusted computer then you might want to look into the hardware/USB-based solutions, or alternatives like U2F and so on. Now, you're still vulnerable to MITM attacks and so on against the sites you're actually logging into, but your credentials for other sites would not be at risk since they stay on the hardware device, which is going to be hardened against USB attacks (well, at least you hope it would be). If you're using conventional passwords then of course something could still sniff that password since it has to pass through the untrusted computer. If you're using OTPs or U2F/etc then you may still be vulnerable to some cookie-based attacks and MITM and so on, but if you log off at the end of your session that at least limits their duration. Personally I would like to switch to a hardware-based solution, but they have their own set of downsides: 1. Less convenience - you have to physically have the device on you (I don't carry my keys around in the hosue/etc), and plug it in when you want to use it. 2. Recovery options aren't always great. Often these devices don't really have their own recovery solution, and you're stuck following the recovery options on each individual site. Many of these are pretty lousy. 3. Often no support for multiple hardware devices (and keeping them in sync). Again you're stuck with what individual sites allow, and many sites don't let you have multiple hardware tokens registered. 4. Lack of convenience features like auto-changing passwords. Some software-based solutions have this. Though, to be honest, I rarely trust these because if something goes wrong I could lose account access and this can be difficult or impossible to recover from in many situations. A big advantage (and disadvantage) of the software-based solutions is that they're just data files and you can back them up trivially. Really though a lot of this boils down to the fact that PKI is a hard problem without a trusted and convenient mediator, and this largely doesn't exist in the world of free online services. -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Mick wrote: > On Tuesday, 5 February 2019 07:55:41 GMT Dale wrote: >> Mick wrote: >>> https://en.wikipedia.org/wiki/LastPass#Security_issues >>> >> From what I read, no users had their passwords compromised in those. > I read it differently. LastPass didn't know if any passwds were compromised > (or wouldn't tell you). As a precaution they asked users to change their > master passwd, while they changed their server's salt. In addition, there > were XSS vulnerabilities later on, which is probably to be expected with > JavaScript and similar technologies. > I recall the email vaguely. It said there was nothing that showed the passwords were compromised. I did change passwords for things like my bank etc but left the others alone. Of course, I change those passwords on a fairly regular basis anyway. Thing is, when it comes to financial stuff, I don't leave as much to chance. I found the email notice. Here is a bit of it: "No encrypted user vault data was taken, however other data, including email addresses and password reminders, was compromised." So, the encrypted stuff such as passwords was not compromised. They only got email addys and such which isn't a big deal. >> As >> I pointed out earlier, the passwords are already encrypted when they are >> sent to LastPass. If I called LastPass, could prove I am who I claim to >> be and asked them for a password to a site, they couldn't give it to me >> because it is encrypted when it leaves my machine. > I don't know exactly how the LastPass architecture is configured, other than > it relies on device based encryption activated with JavaScript, but anomalies > they observed in incoming and outgoing traffic on the 2011 incident indicate > someone was interfering with their data streams. Given Diffie-Hellman could > be compromised (e.g. as per Logjam) by precomputing some of the most commonly > used primes in factoring large integers, it may be someone was undertaking > comparative analysis to deduce ciphers and what not. If the server salt was > obtained, then one layer of encryption was compromised. > > All this is juxtaposition and my hypothesizing does not mean LastPass is not > useful, or not secure. It just means its design is not as secure as locally > run simpler encryption mechanisms, which do not leave your PC and are not > stored somewhere else. > > The greater surface area a security system exposes, the higher likelihood > someone will take a punt at cracking it. A browser, sandboxed or not, has > far > too many moving parts and exposed flanks to keep crackers and state actors > busy. I expect with advances in AI this effort will accelerate > logarithmically. This is why I don't use the built in password manager in Firefox. Firefox most likely concentrates on the browser since its main job is being a browser. A password tool is a little lower on the list I would think. However, LastPass and other password tools, it is their main function to be password tools that are secure but can still work with the browser as well. > >> As I pointed out to Rich, I don't expect these tools to be 100%. There >> is no perfect password tool or a perfect way to manage them either. No >> matter what you do, someone can come along and poke a hole in it. If >> you use a tool, the tool is hackable. If you use the same password that >> is 40 characters long for several dozen sites, then the site can be >> hacked and they have the password for those other sites as well. The >> list could go on for ages but it doesn't really change anything. We do >> the best we can and then hope it is enough. Using tools is in my >> opinion better than not using a tool at all. At the least, they will >> have a hard time breaking into a site directly without my password. It >> beats the alternative which is cutting off the computer and unplugging >> it. :-( > Yes, well said. A disconnected and switched off PC is probably quite secure, > but what use is this to anybody. LOL! The effectiveness of PC security is > challenged on a daily basis and you eventually have to arrive at a personal > trade-off between security and usability. > This is what I run into with this new password project. I want one that is easy for me to remember, easy to type and such but I also want it to where some script kiddy can't crack it in like 10 seconds while laughing his/her fool head off at me. The decision to use a tool like LastPass, or any other tool for that matter, also means a trade off. Anything we use will expose us to something. That said, not using one exposes us to something else, even if it is just bad ways to deal with passwords. Using one password on several sites is one thing that jumps to my mind. We just have to try to be reasonable about it. One thing about this, I'm putting more effort into one password than most do for every password they have. Now to play with the strength meters some more. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Tuesday, 5 February 2019 07:55:41 GMT Dale wrote: > Mick wrote: > > https://en.wikipedia.org/wiki/LastPass#Security_issues > > > From what I read, no users had their passwords compromised in those. I read it differently. LastPass didn't know if any passwds were compromised (or wouldn't tell you). As a precaution they asked users to change their master passwd, while they changed their server's salt. In addition, there were XSS vulnerabilities later on, which is probably to be expected with JavaScript and similar technologies. > As > I pointed out earlier, the passwords are already encrypted when they are > sent to LastPass. If I called LastPass, could prove I am who I claim to > be and asked them for a password to a site, they couldn't give it to me > because it is encrypted when it leaves my machine. I don't know exactly how the LastPass architecture is configured, other than it relies on device based encryption activated with JavaScript, but anomalies they observed in incoming and outgoing traffic on the 2011 incident indicate someone was interfering with their data streams. Given Diffie-Hellman could be compromised (e.g. as per Logjam) by precomputing some of the most commonly used primes in factoring large integers, it may be someone was undertaking comparative analysis to deduce ciphers and what not. If the server salt was obtained, then one layer of encryption was compromised. All this is juxtaposition and my hypothesizing does not mean LastPass is not useful, or not secure. It just means its design is not as secure as locally run simpler encryption mechanisms, which do not leave your PC and are not stored somewhere else. The greater surface area a security system exposes, the higher likelihood someone will take a punt at cracking it. A browser, sandboxed or not, has far too many moving parts and exposed flanks to keep crackers and state actors busy. I expect with advances in AI this effort will accelerate logarithmically. > As I pointed out to Rich, I don't expect these tools to be 100%. There > is no perfect password tool or a perfect way to manage them either. No > matter what you do, someone can come along and poke a hole in it. If > you use a tool, the tool is hackable. If you use the same password that > is 40 characters long for several dozen sites, then the site can be > hacked and they have the password for those other sites as well. The > list could go on for ages but it doesn't really change anything. We do > the best we can and then hope it is enough. Using tools is in my > opinion better than not using a tool at all. At the least, they will > have a hard time breaking into a site directly without my password. It > beats the alternative which is cutting off the computer and unplugging > it. :-( Yes, well said. A disconnected and switched off PC is probably quite secure, but what use is this to anybody. LOL! The effectiveness of PC security is challenged on a daily basis and you eventually have to arrive at a personal trade-off between security and usability. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Tuesday, 5 February 2019 08:41:28 GMT Neil Bothwick wrote:
> On Mon, 04 Feb 2019 23:26:52 +, Mick wrote:
> > You could use gpg/openssl to encrypt a number of files, which would
> > contain your different website/application passwds.
>
> pass does exactly that
>
> * app-admin/pass
> Available versions: 1.7.3 ** {X dmenu emacs fish-completion +git
> importers zsh-completion ELIBC="Darwin"} Homepage:
> https://www.passwordstore.org/
> Description: Stores, retrieves, generates, and synchronizes passwords
> securely
What do you know?! Someone else thought of it too. :-)
Thanks Neil, this looks interesting and seems way more advanced than my simple
one-liner.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, 04 Feb 2019 23:26:52 +, Mick wrote:
> You could use gpg/openssl to encrypt a number of files, which would
> contain your different website/application passwds.
pass does exactly that
* app-admin/pass
Available versions: 1.7.3 ** {X dmenu emacs fish-completion +git
importers zsh-completion ELIBC="Darwin"}
Homepage: https://www.passwordstore.org/
Description: Stores, retrieves, generates, and synchronizes passwords
securely
--
Neil Bothwick
"There are some ideas so idiotic that only an intellectual could believe
them" George Orwell
pgp3m_v20rIeD.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Mick wrote: > On Monday, 4 February 2019 22:12:16 GMT Dale wrote: >> Neil Bothwick wrote: >>> On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > One reason I use LastPass, it is mobile. I can go to someone else's > computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > logoff and it is like I was never there. As much as I like Lastpass I would never do that. It isn't magic - it is javascript. If there is a compromise on your computer, then your password database will be compromised. This is true of other solutions like KeePassX and so on - if something roots your box then it will be compromised. >>> I don't see what root has to do with it. If someone gains access to your >>> box, they can copy the database file and then take their time trying to >>> crack the password, but you don't need to be root to do that. >> I might point out, LastPass encrypts the password before sticking it in >> a file. It isn't visible or plain text. Even getting the file would >> still require some tools and cracking to get the password itself. >> Cracking the master password would likely be much easier and doesn't >> even require access to the box itself, Linux or windoze. Also, LastPass >> only stores the encrypted password on its servers. Even if LastPass is >> hacked, the passwords are still encrypted. It's one reason LastPass >> shouldn't have to worry about getting court orders to turn over >> passwords. It doesn't really have them. I would suspect that cracking >> a encrypted password is as difficult as is just poking at a password >> until it is guessed. >> >> Even if a person is using a perfect tool, cracking a password is always >> going to be possible. The tougher the password, the harder it will be >> and the longer it will take. Still, it can be done. Using these tools >> just makes it harder. I'm not aware of a perfect password tool. I >> doubt one exists or ever will either. ;-) It's still good to pick one, >> use it and try to be as secure as one can. >> >> Dale >> >> :-) :-) > A solution like LastPass et al., using a browser's javascript to access it, > under a single master passwd, theoretically would have so many side-channel > attacks no one would be wasting time to brute force anything. > > https://en.wikipedia.org/wiki/LastPass#Security_issues > > You could use gpg/openssl to encrypt a number of files, which would contain > your different website/application passwds. For paranoid use cases you can > use asymmetric keys and store your private key out-of-band. Sure, it won't > be > as convenient as LastPass, but I expect it would be more secure and unlikely > to be compromised by XSS vulnerabilities. > >From what I read, no users had their passwords compromised in those. As I pointed out earlier, the passwords are already encrypted when they are sent to LastPass. If I called LastPass, could prove I am who I claim to be and asked them for a password to a site, they couldn't give it to me because it is encrypted when it leaves my machine. The only breach I recall is when they said that users email addresses were taken. There was once where they asked everyone to change their master password as a precaution several years ago. They had no info that showed anything was hacked but they wanted users to change them anyway. Since I get emails as a user, I've never received a email that said their service was hacked and that passwords were known to be taken decrypted. I do get emails when something needs to be changed or I changed something. As I pointed out to Rich, I don't expect these tools to be 100%. There is no perfect password tool or a perfect way to manage them either. No matter what you do, someone can come along and poke a hole in it. If you use a tool, the tool is hackable. If you use the same password that is 40 characters long for several dozen sites, then the site can be hacked and they have the password for those other sites as well. The list could go on for ages but it doesn't really change anything. We do the best we can and then hope it is enough. Using tools is in my opinion better than not using a tool at all. At the least, they will have a hard time breaking into a site directly without my password. It beats the alternative which is cutting off the computer and unplugging it. :-( Still can't get cracklib to work right. < scratches head > Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Rich Freeman wrote: > On Mon, Feb 4, 2019 at 5:12 PM Dale wrote: >> Neil Bothwick wrote: >>> On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: >>> > One reason I use LastPass, it is mobile. I can go to someone else's > computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > logoff and it is like I was never there. As much as I like Lastpass I would never do that. It isn't magic - it is javascript. If there is a compromise on your computer, then your password database will be compromised. This is true of other solutions like KeePassX and so on - if something roots your box then it will be compromised. >>> I don't see what root has to do with it. If someone gains access to your >>> box, they can copy the database file and then take their time trying to >>> crack the password, but you don't need to be root to do that. > Correct, it just needs access to the user's data or browser process, > which could mean running as root, or that user. > >> I might point out, LastPass encrypts the password before sticking it in >> a file. It isn't visible or plain text. Even getting the file would >> still require some tools and cracking to get the password itself. > That assumes you're attacking the password file directly. > > If you're using lastpass on a compromised system then there are many > ways that can be used to bypass the encryptions. They could sniff > your master password when you key it in, or read it directly from the > browser's memory. These things are protected from sandboxed code in > your browser, but not from processes running outside the browser > (unless again you're using a non-conventional privilege system like > selinux/android/etc). > One could argue the same thing with any password tool out there tho, right? After all, at some point, all password tools have to decrypt the password even if it is only in memory. At that point, it can be 'sniffed' out. Thing is, if my system or any system I use is compromised, I'll have the same issue no matter what I do or what tool I use. Even if I use the password tool included in Firefox or any other browser, wouldn't I run into the same problem? Wouldn't I run into some other security problem if I used no password tool at all and just typed in the same password for say 20 or 30 different sites? The solution is, be reasonably secure. Nothing is 100% secure unless it is turned off completely, maybe not even then. I'm sure even selinux has its security issues as well. It is after all a OS that runs a lot of code and only needs one flaw in it. As I've pointed out before on different topics, if a person gets physical access or control of a machine and is able to install things on it, it doesn't really matter what one does unless they can detect it somehow before ever using anything. Given I only install things from trusted sources, the odds of that happening are likely very small. Even my neighbors don't install much of anything because they mostly use it to access financial sites and to check their email. They are a older pair so they don't use it like even someone my age does. Still, if I did have to use it in a situation, such as ordering computer parts to rebuild, I'd likely change my more important passwords just to be sure ASAP. I already do that regularly anyway especially for my financial sites. That's another thing LastPass tracks, how long a password has been in use for a site. It reminds me of that sort of thing. While I'm trying to come up with a good password, I don't expect it to cover every possible case. While I use LastPass, I don't expect it to be a perfect solution. I wouldn't expect it of any other tool either. Thing is, LastPass does what I need and is likely as secure as other tools that can do the same things. I get that one can be hacked as you describe but once a person is able to do what you describe, it really doesn't matter what tool I use. Even a simple keylogger can do the job if I use no password tool at all. I'm just trying to be reasonably secure. If everyone or even most everyone would do the same, those little script kiddys would have to work much harder. That's one thing I read about while googling for ways to come up with passwords. Over half the people using passwords use some really awful ones. Some use the same one for a lot of sites as well. Something we both know is bad. If everyone would put in even a tenth of the effort I am, the internet would be a much safer place. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Monday, 4 February 2019 22:12:16 GMT Dale wrote: > Neil Bothwick wrote: > > On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > >>> One reason I use LastPass, it is mobile. I can go to someone else's > >>> computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > >>> logoff and it is like I was never there. > >> > >> As much as I like Lastpass I would never do that. It isn't magic - it > >> is javascript. If there is a compromise on your computer, then your > >> password database will be compromised. This is true of other > >> solutions like KeePassX and so on - if something roots your box then > >> it will be compromised. > > > > I don't see what root has to do with it. If someone gains access to your > > box, they can copy the database file and then take their time trying to > > crack the password, but you don't need to be root to do that. > > I might point out, LastPass encrypts the password before sticking it in > a file. It isn't visible or plain text. Even getting the file would > still require some tools and cracking to get the password itself. > Cracking the master password would likely be much easier and doesn't > even require access to the box itself, Linux or windoze. Also, LastPass > only stores the encrypted password on its servers. Even if LastPass is > hacked, the passwords are still encrypted. It's one reason LastPass > shouldn't have to worry about getting court orders to turn over > passwords. It doesn't really have them. I would suspect that cracking > a encrypted password is as difficult as is just poking at a password > until it is guessed. > > Even if a person is using a perfect tool, cracking a password is always > going to be possible. The tougher the password, the harder it will be > and the longer it will take. Still, it can be done. Using these tools > just makes it harder. I'm not aware of a perfect password tool. I > doubt one exists or ever will either. ;-) It's still good to pick one, > use it and try to be as secure as one can. > > Dale > > :-) :-) A solution like LastPass et al., using a browser's javascript to access it, under a single master passwd, theoretically would have so many side-channel attacks no one would be wasting time to brute force anything. https://en.wikipedia.org/wiki/LastPass#Security_issues You could use gpg/openssl to encrypt a number of files, which would contain your different website/application passwds. For paranoid use cases you can use asymmetric keys and store your private key out-of-band. Sure, it won't be as convenient as LastPass, but I expect it would be more secure and unlikely to be compromised by XSS vulnerabilities. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, Feb 4, 2019 at 5:12 PM Dale wrote: > > Neil Bothwick wrote: > > On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > > > >>> One reason I use LastPass, it is mobile. I can go to someone else's > >>> computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > >>> logoff and it is like I was never there. > >> As much as I like Lastpass I would never do that. It isn't magic - it > >> is javascript. If there is a compromise on your computer, then your > >> password database will be compromised. This is true of other > >> solutions like KeePassX and so on - if something roots your box then > >> it will be compromised. > > I don't see what root has to do with it. If someone gains access to your > > box, they can copy the database file and then take their time trying to > > crack the password, but you don't need to be root to do that. Correct, it just needs access to the user's data or browser process, which could mean running as root, or that user. > > I might point out, LastPass encrypts the password before sticking it in > a file. It isn't visible or plain text. Even getting the file would > still require some tools and cracking to get the password itself. That assumes you're attacking the password file directly. If you're using lastpass on a compromised system then there are many ways that can be used to bypass the encryptions. They could sniff your master password when you key it in, or read it directly from the browser's memory. These things are protected from sandboxed code in your browser, but not from processes running outside the browser (unless again you're using a non-conventional privilege system like selinux/android/etc). -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Neil Bothwick wrote: > On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > >>> One reason I use LastPass, it is mobile. I can go to someone else's >>> computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, >>> logoff and it is like I was never there. >> As much as I like Lastpass I would never do that. It isn't magic - it >> is javascript. If there is a compromise on your computer, then your >> password database will be compromised. This is true of other >> solutions like KeePassX and so on - if something roots your box then >> it will be compromised. > I don't see what root has to do with it. If someone gains access to your > box, they can copy the database file and then take their time trying to > crack the password, but you don't need to be root to do that. > > I might point out, LastPass encrypts the password before sticking it in a file. It isn't visible or plain text. Even getting the file would still require some tools and cracking to get the password itself. Cracking the master password would likely be much easier and doesn't even require access to the box itself, Linux or windoze. Also, LastPass only stores the encrypted password on its servers. Even if LastPass is hacked, the passwords are still encrypted. It's one reason LastPass shouldn't have to worry about getting court orders to turn over passwords. It doesn't really have them. I would suspect that cracking a encrypted password is as difficult as is just poking at a password until it is guessed. Even if a person is using a perfect tool, cracking a password is always going to be possible. The tougher the password, the harder it will be and the longer it will take. Still, it can be done. Using these tools just makes it harder. I'm not aware of a perfect password tool. I doubt one exists or ever will either. ;-) It's still good to pick one, use it and try to be as secure as one can. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Rich Freeman wrote: > On Mon, Feb 4, 2019 at 3:09 PM Dale wrote: >> I'm not sure if one can convert that to NSA time or not. o_O The >> password contains upper/lower case letters, couple symbols from up top >> of the number keys and several numbers. None of which anyone would be >> able to guess in any way. They have nothing to do with that list of >> things not to use, birthdays etc. If a person was trying to just guess >> it, even a best friend who knows me extremely well, they would not be >> able to guess it much less the order of it. The only bad thing, it >> isn't to easy to type. Of course, a really good password usually isn't >> so . . . > And do you use that password on only a single site? > > If you use it on more than one, then as soon as one of those sites is > compromised it will sniff your password and then your password can be > used on all the others without any cpu cycles wasted on brute-forcing > it at all. > > That is the weakness of random passwords. Unless you use some kind of > password manager you won't actually use a unique password on each site > due to difficulty with memorization... > Right now, I'm coming up with a master password for LastPass and maybe a new set of keys. I may use something different for my keys to your point. My encryption thingy broke on Seamonkey, the keys are broken somehow. I googled, tried some stuff but can't figure out how to fix them so I revoked the things and am going to start fresh. Heck, only one person ever uses them anyway. lol Once I get logged into LastPass, I generate unique passwords with it for each site. Depending on the site, I try to generate as long and use as many characters as the site will allow. If it allows the symbols on top of the number keys, I enable them. If it doesn't, I cut that off. If it allows 20 characters, I set it to generate 20. It's not like I have to remember it or even type it in either. I may as well be as secure and random as possible. The master password is the current project tho. Way back, I used to have three passwords. One fairly secure one for financial type sites, one somewhat decent one for stuff like social sites and one I could care less about. None of them would be easy to guess but the complexity changed. Nowadays, I wouldn't even dream of doing like that. Far to many script kiddys out there trying to steal stuff. That doesn't even mention the pros and what they do. You are right tho, reusing passwords is a really bad idea. It makes it dead simple to hack everything else. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, 4 Feb 2019 15:59:02 -0500, Rich Freeman wrote: > > One reason I use LastPass, it is mobile. I can go to someone else's > > computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > > logoff and it is like I was never there. > > As much as I like Lastpass I would never do that. It isn't magic - it > is javascript. If there is a compromise on your computer, then your > password database will be compromised. This is true of other > solutions like KeePassX and so on - if something roots your box then > it will be compromised. I don't see what root has to do with it. If someone gains access to your box, they can copy the database file and then take their time trying to crack the password, but you don't need to be root to do that. -- Neil Bothwick ... "I'm simply not a nice girl", she whispered tartly. pgp1mQVWkPX2n.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, Feb 4, 2019 at 3:49 PM Dale wrote: > > One reason I use LastPass, it is mobile. I can go to someone else's > computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, > logoff and it is like I was never there. As much as I like Lastpass I would never do that. It isn't magic - it is javascript. If there is a compromise on your computer, then your password database will be compromised. This is true of other solutions like KeePassX and so on - if something roots your box then it will be compromised. If you were talking about something like a Chromebook that is still locked down and you're using guest mode or logging in under a separate user account from anybody else, then you're probably fairly safe against that. However, if you're just looking into a generic windows box or a shared linux account then there isn't going to be much protection if something has compromised the system. At that point you're vulnerable to all kinds of attacks, from theft of the password manager database, to just skimming the accounts you're using. This won't stop sniffing of individual passwords, but you could at least protect your overall database by looking up the password on a secure device (your phone or whatever) and rekeying it on the untrusted device. Then while that password is still vulnerable your password database never touches that box. -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, 04 Feb 2019 14:38:38 -0500, Jack wrote: > The problem I have with many of these suggestions is that I have > multiple devices (two desktops, two laptops, tablet, android phone) I > use sufficiently often that I either need to be able to remember the > passwords or have some way of easily accessing them when I'm not > sitting at my main desktop. Other than using a password manager > (which I do not currently have) how to others deal with this? If you don't want to use an online passwrd manager like LastPass, you could use a local solution. I use KeePassX, which is available for Linux and Android (and some minority OSes). It stores the passwords in an encrypted database file, protected by a master password. As it's a single file it is easy enough to keep this synchronised between devices. I initially did this with DropBox but soon switched to Syncthing. It's just another file to keep synchronised between devices, so use whatever method you already use for that purpose. -- Neil Bothwick You are about to give someone a piece of your mind, something you can ill afford... pgp1GLfKnCDax.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Coming up with a password that is very strong.
Nikos Chantziaras wrote: > On 04/02/2019 07:47, Dale wrote: >> How do you, especially those who admin systems that are always being >> hacked at, generate strong passwords that meet the above? I've googled >> and found some ideas but if I use the same method, well, how many others >> are using that same method, if you know what I mean. ;-) Just looking >> for ideas. > > I don't use a password manager. For website logins, I just use the > password manager in the browser (Firefox), which does not use a master > password :-P I just assume my own system is not going to be compromised. > > For the websites I use, I generate a unique password per site using > this command: > > $ pwmake 128 > > This generates a password using 128 bits of entropy from /dev/urandom. > You need dev-libs/libpwquality being installed (it's a dep of > something important, I think, so should be installed on most systems > already.) > > For remote systems I administer through SSH, I don't use passwords. I > use a public/private key pair to log in (4096 bits.) My private key is > protected with a strong password though, but it's easy to remember > since it doesn't need to change. Something like: > > ilp@4*r > > Which is short for: > > I like pizza and macaroni for dinner at four star restaurants. > > > One reason I use LastPass, it is mobile. I can go to someone else's computer, use LastPass to say make use of Paypal, Newegg, Ebay etc, logoff and it is like I was never there. Also, if my computer were to die a sudden death, power supply goes bonkers and burns everything in it up including hard drives, my passwords are still safe but available. When I get a new rig built, I can install LastPass, put in my email and password then go on like nothing ever happened. I can also use a neighbors computer to order the parts for a new rig as well. I just use LastPass on their computer. I could do that even if my backups were out of date as well. I also like that it generates passwords that are dang near impossible to crack. It also doesn't have to be anything I can remember either. This is a few examples of what it generates. *k0Dx^RiNPHOocIg 5wfy^HHgwZ3 NnWM9DwCrVYyVryS3Aa9 Now I admit, I sometimes see one that pops up that I don't like the looks of and I click for a new one. Just like the last one in the list. It has two of the same letter at the beginning. One upper and one lower but still the same. I'd skip that one. Still, good luck guessing it easily. Cracking it is always possible but it makes it difficult. Also, I sometimes have to leave off the other characters since some websites don't allow those. My bank for example doesn't allow a couple of them. I think "*" and "$" is a no go. It does reject it when you try to enter it tho. If I were to ever get me a smart phone, LastPass works on those too. I still like my Razr tho. It makes phone calls and allows me to text. It does what I need. It also takes the place of a watch as well. ;-) I get why some may just use Firefox or other browsers password tool but thing is, if you don't have a backup of it and something happens, you could be working a while to get those passwords going again. If I recall correctly, I have to go to the bank, present ID and such to do a complete reset of my bank password. I know it was that way several years ago because I had to do it once. Those keys do work for things that support it. I don't think any site I use has that ability tho. If it does, I don't know about it. Maybe one day tho. Dale :-) :-)
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On Mon, Feb 4, 2019 at 3:09 PM Dale wrote: > > I'm not sure if one can convert that to NSA time or not. o_O The > password contains upper/lower case letters, couple symbols from up top > of the number keys and several numbers. None of which anyone would be > able to guess in any way. They have nothing to do with that list of > things not to use, birthdays etc. If a person was trying to just guess > it, even a best friend who knows me extremely well, they would not be > able to guess it much less the order of it. The only bad thing, it > isn't to easy to type. Of course, a really good password usually isn't > so . . . And do you use that password on only a single site? If you use it on more than one, then as soon as one of those sites is compromised it will sniff your password and then your password can be used on all the others without any cpu cycles wasted on brute-forcing it at all. That is the weakness of random passwords. Unless you use some kind of password manager you won't actually use a unique password on each site due to difficulty with memorization... -- Rich
Re: [gentoo-user] Re: Coming up with a password that is very strong.
On 2019.02.04 06:10, Nikos Chantziaras wrote: On 04/02/2019 07:47, Dale wrote: How do you, especially those who admin systems that are always being hacked at, generate strong passwords that meet the above? I've googled and found some ideas but if I use the same method, well, how many others are using that same method, if you know what I mean. ;-) Just looking for ideas. I don't use a password manager. For website logins, I just use the password manager in the browser (Firefox), which does not use a master password :-P I just assume my own system is not going to be compromised. For the websites I use, I generate a unique password per site using this command: $ pwmake 128 This generates a password using 128 bits of entropy from /dev/urandom. You need dev-libs/libpwquality being installed (it's a dep of something important, I think, so should be installed on most systems already.) For remote systems I administer through SSH, I don't use passwords. I use a public/private key pair to log in (4096 bits.) My private key is protected with a strong password though, but it's easy to remember since it doesn't need to change. Something like: ilp@4*r Which is short for: I like pizza and macaroni for dinner at four star restaurants. The problem I have with many of these suggestions is that I have multiple devices (two desktops, two laptops, tablet, android phone) I use sufficiently often that I either need to be able to remember the passwords or have some way of easily accessing them when I'm not sitting at my main desktop. Other than using a password manager (which I do not currently have) how to others deal with this? Jack
