Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


1Password's gone bad - recommendations? - Page 5
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

1Password's gone bad - recommendations?

1235

Comments

  • deadbeefdeadbeef Member
    edited March 2017

    @bsdguy said:

    @deadbeef said:

    @bsdguy said:
    So is having quite some quite good universities.

    Thats a racist remark -_-

    OK, I confess it, I'm a racist due to thinking that Indians are not stupid and uneducated.

    You are racist because you are implying that other countries don't have smart enough people to have some quite good universities.

    To make it worse I also think that 2 bathrooms, one for ladies and one for gents, is sufficient.

    Your propensity for considering the issues that are important to humanity can't be understated.

  • @jarland said:
    If you expect no vulnerabilities to ever appear in a service I'd say that's a bit naive. Thus the reason for only using it to store things that are not critical or career/life ending if compromised. People make mistakes and you can always count on them to do it time and time again.

    Don't throw the baby out with the bath water I guess is what I'm saying. If you're going to use a service for storing some passwords, use one that you're sure will have fast response times to issues, not one that has never been found vulnerable. Having never been found vulnerable means three things to me:

    1. Not popular enough to be attacked.
    2. Not highly staffed due to lack of popularity.
    3. Potential false sense of perfection in its devs as a result of not being targeted.

    Youre correct, but thats one of the reasons why I, personally, choose to use Keepass (with 2FA)+ my own file sync. It still is probable that Keepass has bugs that could compromise my database at some point, but at least my database is less likely to be accessed by a second party (due to being hosted only on my own devices+server). Obviously there are ways problems can appear, but yeah, smaller target and all that jazz. In the end, I dont need to be safe from the CIA/FSB/GCHQ.

    I hated the browser integration of Keepass btw, until I found Keefox. Its one of the single largest reasons why I would never switch away from Firefox for a longer period of time. I would recommend giving it a whirl. (if youre interested in Keepass browser integration)

    Thanked by 1jar
  • @MagicalTrain said:
    I hated the browser integration of Keepass btw, until I found Keefox.

    Never ever trust your password hive to the browser. Browsers have a really huge attack surface are an active target for people/institutions that know what they're doing.

    Thanked by 2MagicalTrain WSS
  • @deadbeef said:

    @MagicalTrain said:
    I hated the browser integration of Keepass btw, until I found Keefox.

    Never ever trust your password hive to the browser. Browsers have a really huge attack surface are an active target for people/institutions that know what they're doing.

    Youre technically correct. But then again, its a compromise between hating myself by not having integration and having to type shit all the time, correctly configuring keepass+keefox to how restrictive you want it to be (you can tell it to prompt you every time a password is requested for example) or not using password managers at all and have shitty passwords (cause who the fuck remembers the hundreds of good passwords one has).

    Thanked by 1deadbeef
  • WSSWSS Member
    edited March 2017

    @jarland said:
    If you expect no vulnerabilities to ever appear in a service I'd say that's a bit naive.

    Agreed.

    Don't throw the baby out with the bath water I guess is what I'm saying. If you're going to use a service for storing some passwords, use one that you're sure will have fast response times to issues, not one that has never been found vulnerable. Having never been found vulnerable means three things to me:

    1. Not popular enough to be attacked.
    2. Not highly staffed due to lack of popularity.
    3. Potential false sense of perfection in its devs as a result of not being targeted.

    The reason I said "Enough" is that they are/were boneheadedly simple "Oh fuck" issues, which were directly related (so far). One "Oh we did that wrong" that didn't lead to "Let's check the way we do the rest of our auth" immediately, well.. no thanks, I just don't trust them to be able to handle web services.

    Also, I spent about an hour making a Keepass v1 XML exporter that takes the CSV from LastPass. It's ugly, but it works. I have my crap imported into KeepassCX right now, but I still abhor Keepass and the way the localhost auth shit works with the browser plugins.

    I think the most annoying part was generating 16 bit UUIDs without worry of colliding.

    Thanked by 2jar MagicalTrain
  • @WSS said:
    Also, I spent about an hour making a Keepass v1 XML exporter that takes the CSV from LastPass. It's ugly, but it works. I have my crap imported into KeepassCX right now, but I still abhor Keepass and the way the localhost auth shit works with the browser plugins.

    Do give Keefox a quick try. It uses KeepassRPC instead of KeepassHTTP for the connection to Keepass (which btw means youll have to use Keepass main, instead of CX, because CX doesnt do RPC), but from what I hear, its marginally more secure than KeepassHTTP. (plus the stuff around it works a lot better than the other browser integrations Ive tried)

  • WSSWSS Member

    @MagicalTrain said:

    @WSS said:
    Also, I spent about an hour making a Keepass v1 XML exporter that takes the CSV from LastPass. It's ugly, but it works. I have my crap imported into KeepassCX right now, but I still abhor Keepass and the way the localhost auth shit works with the browser plugins.

    Do give Keefox a quick try. It uses KeepassRPC instead of KeepassHTTP for the connection to Keepass (which btw means youll have to use Keepass main, instead of CX, because CX doesnt do RPC), but from what I hear, its marginally more secure than KeepassHTTP. (plus the stuff around it works a lot better than the other browser integrations Ive tried)

    Thanks for this, but I don't generally use Windows, or Firefox. :)

  • @WSS Dont need Windows for Keepass main or Keefox, but if you dont use Firefox, thats obviously a hinderniss. :D

  • @jarland

    I'm not so sure. Look e.g. at the (in)famous google lollipop problem that exposed millions and millions of android devices. What was the problem? Entering a gigantic "password" broke the whole security system.

    Now, google is known to react quite quickly (or so is said) and google certainly is no minor player and does have plenty resources - yet they made a very stupid mistake only a newb or a clueless developer would make. Plainly speaking they ignored the holy law of input, namely "Never assume anything re. input! Always examine the whole domain of technically possible inputs!"

    One classical - and simple - method to avoid lollipop would have been something like

    if input'Length > 127 then -- reasonable example limit
       response.message := "Fuck you!";
       response.status := denied;
       return response;
    else -- ...
    

    a dead simple input length check.

    However, they (well, the developer in charge as well as the auditor) chose to commit one of two well known sins, namely the sin of "my input buffer size is X and nobody will ever use a passphrase that long" (the other sin being assuming "reasonable input properties").

    You choose: Either google has no proper understanding of security and put into a binding ruleset - or - I'm right in saying that it's virtually impossible to post facto make a code body of considerable size (like android) somehow secure.

    Also pay attention: The code quite probably compiled fine and was correct. Even static analyzers wouldn't have found anything to complain about - but it was not safe.

    Another major sin (to avoid saying "idiocy") is to check user input client side (javascript) and to not check it server side, because, you know, "it has already been checked".

  • +1 for LastPass

  • jarjar Patron Provider, Top Host, Veteran

    @bsdguy said:
    @jarland

    I'm not so sure. Look e.g. at the (in)famous google lollipop problem that exposed millions and millions of android devices. What was the problem? Entering a gigantic "password" broke the whole security system.

    Now, google is known to react quite quickly (or so is said) and google certainly is no minor player and does have plenty resources - yet they made a very stupid mistake only a newb or a clueless developer would make. Plainly speaking they ignored the holy law of input, namely "Never assume anything re. input! Always examine the whole domain of technically possible inputs!"

    One classical - and simple - method to avoid lollipop would have been something like

    if input'Length > 127 then -- reasonable example limit
       response.message := "Fuck you!";
       response.status := denied;
       return response;
    else -- ...
    

    a dead simple input length check.

    However, they (well, the developer in charge as well as the auditor) chose to commit one of two well known sins, namely the sin of "my input buffer size is X and nobody will ever use a passphrase that long" (the other sin being assuming "reasonable input properties").

    You choose: Either google has no proper understanding of security and put into a binding ruleset - or - I'm right in saying that it's virtually impossible to post facto make a code body of considerable size (like android) somehow secure.

    Also pay attention: The code quite probably compiled fine and was correct. Even static analyzers wouldn't have found anything to complain about - but it was not safe.

    Another major sin (to avoid saying "idiocy") is to check user input client side (javascript) and to not check it server side, because, you know, "it has already been checked".

    I think that goes well with what I'm saying. Expect vulnerabilities in everything. Nothing less is reasonable or realistic.

  • ricardoricardo Member
    edited March 2017

    jarland said: Expect vulnerabilities in everything

    Seems reasonable, not quite sure what you're getting at with the 1,2,3 list though as it sounds like security through obscurity.

    With a bit coercion it seems the consensus here is don't use online services at all, except for cat pics. Any software attached to the browser should be considered dangerous. Anything stored on a public network is a risk.

    Password may as well be younoknowthecodes$this_domain

    Good readings. Worth remembering that these services are meant as a convenience, hence the auto fill features and the like, with the least amount of thinking and action required. After all, most people use a computer as a tool, you know, to access services with a browser. Though, I'd suppose the primary customer of these services are the tech savvy.

    That in hand, it seems the thread has lost its point.

  • jarland said: If you're going to use a service for storing some passwords, use one that you're sure will have fast response times to issues, not one that has never been found vulnerable.

    I agree with you. At the same time when I read that these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe, I would move platforms just like @WSS did.

    bsdguy said: However, they (well, the developer in charge as well as the auditor) chose to commit one of two well known sins, namely the sin of "my input buffer size is X and nobody will ever use a passphrase that long" (the other sin being assuming "reasonable input properties").

    When I was learning programming I remember being taught to always assume the user is an idiot. Embracing that paradigm has worked out well for me. :)

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2017

    ricardo said: Seems reasonable, not quite sure what you're getting at with the 1,2,3 list though as it sounds like security through obscurity.

    That's the point, what I'm saying is that you shouldn't run away from a popular service for having vulnerabilities found in it to the appearance of greener pastures in a less popular service that probably has less staff to handle it when they do get attacked, and has only not been found to be vulnerable due to lack of interest in attacking it. It leads to a false sense of security.

    Of course, using a service in itself is something that is questionable at best, and should probably be kept only to things that are not of the highest value. But if you're going to use a service, use the one that is most likely to resolve vulnerabilities quickly rather than the one never found vulnerable. Because you should assume both are vulnerable in one way or another.

    If everyone were to flock to the next service with no vulnerability found, everyone will flock from vulnerability to vulnerability. At best, that's the same as staying put.

  • jarjar Patron Provider, Top Host, Veteran

    JustAMacUser said: I agree with you. At the same time when I read that these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe

    Surely they didn't just try to launch an exe file and go "oh doesn't work on Mac." I mean that'd just be silly.

  • WSSWSS Member
    edited March 2017

    @jarland said:

    JustAMacUser said: I agree with you. At the same time when I read that these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe

    Surely they didn't just try to launch an exe file and go "oh doesn't work on Mac." I mean that'd just be silly.

    That's precisely what they did. The payload doesn't work on the client they used so they assumed it wasn't valid (initially).

  • jarjar Patron Provider, Top Host, Veteran

    WSS said: That's precisely what they did.

    Well then I guess they're right, exe file doesn't execute on a Mac! :D

  • WSSWSS Member

    @jarland said:

    WSS said: That's precisely what they did.

    Well then I guess they're right, exe file doesn't execute on a Mac! :D

    [insert snide mac is an overpriced pc quote/derail here]

  • @jarland said:
    Surely they didn't just try to launch an exe file and go "oh doesn't work on Mac." I mean that'd just be silly.

    It was a comical read, but it looks like some posts have been removed.

    Of course, using a service in itself is something that is questionable at best, and should probably be kept only to things that are not of the highest value.

    That why we have the The Personal Internet Address & Password Log Book.

    Thanked by 2jar WSS
  • jarjar Patron Provider, Top Host, Veteran
    edited March 2017

    Btw, I recently did stop using autofill on passwords and browser extensions for passwords. It's really not so bad considering I don't tend to log out of websites constantly. I think everyone should give it a try before assuming it's the most annoying thing in the world. For someone it surely is. There will always be some things where convenience outweighs security. Like reddit, who cares if that password gets out.

  • WSSWSS Member

    @jarland said:
    Btw, I recently did stop using autofill on passwords and browser extensions for passwords. It's really not so bad considering I don't tend to log out of websites constantly.

    That's where the majority of these issues seem to come from- the helper functions, rather than the actual meat of the product (which is what @bsdguy was basically getting at in a very round-about way). That it's annoying to type the domain in search, and copy/paste the password yourself, well- that's where we have the issue of convenience vs security.

    Thanked by 1serverian
  • serverianserverian Member
    edited March 2017

    @jarland said:

    JustAMacUser said: I agree with you. At the same time when I read that these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe

    Surely they didn't just try to launch an exe file and go "oh doesn't work on Mac." I mean that'd just be silly.

    https://bugs.chromium.org/p/project-zero/issues/detail?id=1209#c4

    They also said they couldn't get my exploit to work, but I checked my apache access logs and they were using a Mac. Naturally, calc.exe will not appear on a Mac.

    Edit: I guess I've responded too quickly, seems @WSS already said that.

  • @MagicalTrain said:
    these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe

    Is this for real? :o

  • jarjar Patron Provider, Top Host, Veteran

    @deadbeef said:

    @MagicalTrain said:
    these guys tried to reproduce the exploit on a Mac without success, seeing full well calc.exe

    Is this for real? :o

    Ok it sounds like that might be an exaggeration. The person said they checked access logs and saw they were hit by a Mac and that they said it didn't work on that particular test. I think saying they tried to launch an exe on Mac and said it doesn't work might be a bit dishonest, but I'm also not spending a lot of time on this because, frankly, the amount I care is just under threshold ;)

    Thanked by 1deadbeef
  • WSSWSS Member

    There were more posts about this in the linked bugpost yesterday- but taviso seems happy with their fixes today for the continuing issue of stupidity.

    I'm not a fan of trying to build keepassxc under xbps- it's really being a bear having to manually rebuild the damn entire structure under a chroot on this old 5400rpm drive.

  • @BlaZe said:

    @bohdans said:
    I like the look of Enpass, but scared about using a closed source, Indian based, recent (~1yr) released app without any audit.

    Thats a racist remark -_-

    Sorry, that was not meant as racist, was meant as a generalisation of the industry.
    I wouldn't trust any password manager not audited, no matter the country of origin.

  • WSSWSS Member

    @bohdans said:

    @BlaZe said:

    @bohdans said:
    I like the look of Enpass, but scared about using a closed source, Indian based, recent (~1yr) released app without any audit.

    Thats a racist remark -_-

    Sorry, that was not meant as racist, was meant as a generalisation of the industry.
    I wouldn't trust any password manager not audited, no matter the country of origin.

    Thats a racist remark -_-

    God I fucking hate entitled millenials. Especially racist Indian millenials.

    Thanked by 1bohdans
  • bsdguybsdguy Member
    edited March 2017

    It might sound strange but how about simply using the browsers built-in "remember form data"? Sure, that's crappy but probably less crappy than adding crappy "security" add ons.
    It also escapes me why someone would refuse the browsers built in crap for storing and auto-filling passwords but being gladly ready to consider some crappy "security" add ons OK, which work on the same crappy browser.

    Or is the problem that remote storage is desired - in which case the problem is neither the browser nor an add-on but a leaking brain (Hint: smartphones are the least secure devices you own. So, anyone using them for anything even modestly sensitive might as well want to consider asking nsa to kindly store and safeguard ones passwords ...).

  • bsdguybsdguy Member
    edited March 2017

    @WSS said:

    God I fucking hate entitled millenials. Especially racist Indian millenials.

    Now I feel disturbed and want a safespace plus calming tea and cuddly dogs - or else I will turn into a lesbian transsexual that feels discriminated against. Yes that is a threat and yes, you'd better be frightened.

  • bsdguy said: I btw. honestly believe that at least some major browsers would would really honestly like to make their crap reasonably secure - but to do that one would need to start all over fresh (which quite probably nobody will do).

    Actually, Mozilla is doing exactly that with the Servo project, a browser engine written in Rust, a language created to prevent lots of common (exploitable) errors programmers make with C and C++. Even today, Firefox already includes some Servo components.

Sign In or Register to comment.