Security Issues with LastPass on Android(abhyudaya.dev) |
Security Issues with LastPass on Android(abhyudaya.dev) |
Why on earth not? It’s very easy for a computer to check the length of a string, and compare that to a number, there’s absolutely no reason and no excuse for deferring that to the user.
The end user should have every expectation that a generated password will conform to the minimum length setting, and other password settings that are exposed.
Failing to generate passwords that meet the promised criteria is a bug, and not something users should need to have “common sense awareness of”.
Password managers are increasingly mandated by organisations, and Lastpass is a very common recommendation. Even in the minority of technical users that use this kind of tool I expect small mistakes - like accidentally pasting a password in a URL. A good tool doesn't let you shoot yourself in the foot by escalting that to a non-obvious leak. The password length being wrong is 100% on the tool. Th weak master password and the duplicates are again, things the tool shouldn't do - it claims to give good quality security reports.
With respect to Lastpass specifically, I dislike the tool immensely. Ive had to use it a number of times and have always found its UX significantly buggy - included blatant failures like not saving passwords with no indication; coupled with the acquisition by LogMeIn and I'm incredibly distrustful.
1Password is fantastic, but expensive and closed source. Bitwarden is open source, but lacks certain auditing, team and sync features useful for enterprise. KeepassXC is excellent and open source, but with zero collaboration features is only suitable for self use.
Mainly driven by the combination of price increases, no improvements (and possibly getting worse) at things like the auto-fill buttons conflicting or not working with many apps I was using, the duplicate entries it would create, failure to match Android apps and web logins, and the constant battle to try to get it to work with several internal apps and test systems (same top-level domain, where I have a mix of unique and common logins) while also working on the web generally.
Bitwarden has per-domain selection of match type (full host, base domain, or regex), and a non-interfering UI. I can't think of a single thing LastPass does better.
The whole process took probably three minutes front-to-back. Lastpass lets you export your passwords in a CSV, which you then upload to any other service which automatically imports them. Very easy. If you're frustrated with lastpass I recommend the switch. Personally I chose Bitwarden because it's open source.
My only complaint about bitwarden is that folder management in the macos app is not great. Adding passwords to new folders requires writing in the entire directory path. And i have to memorize the entirety of it, writing it incorrectly leads it to create new directories with those badly spelled names.
Companies that use password managers are infinitely better off with one then without. My co-workers would repeat their passwords and make them incredibly simple and easy for anyone to break the it with basic social hacking. My old company had the lowest level of tech skills and the company contracted their IT work and had the stupidest password policy. You just had to change one digit. So the joke was people would just +1 their passwords and they would know how long they worked there.
Repeated passwords is something people do because we all have hundreds of passwords if they don't have a password manager. Even me and my paranoid ways had several because I had to use a system that was based on the url of what I using.
I second that opinion. I've worked in really large companies and I was blown away by the number of people who had {CompanyName}{number} as their password, where number is the amount of times the system required them to change their password. In a company with 6000 employees, we are talking 15-20% of all employees, including senior staff, engineers and manager with access to personal information of tens possibly hundreds of millions of people. This often falls into the category of "Nah, it's fine, I'm safe". And while there are circumstances in which you can feel secure in regards to your personal security at home and everything, we are talking large corporations with endless amounts of internal and external projects many are absolutely unaware of. Example: https://rtb-dsg.companyname.com which uses the company-wide ldap for authentication. Most people inside and outside the company have no idea what rtb-dsg is and it's better to keep it that way. So it's best to avoid taking chances.
It feels to me like we need someone with huge resources, like Microsoft/Gooogle/Apple... to buy them and apply their methods against this attack.
For example, where are the binaries built? Who controls the accounts used to upload the installers? Do they regularly pay security teams to try to find vulnerabilities?
To be clear, I'm not worried about the code, but I'm very worried about the downloadable binaries.
But you are right, securing the code base and the CI is a big part of making sure a software is secure.
Your consideration doesn't pay for dev time. No one cares about pushing free users or 'considering' users off the platform at monetization time. Shit or get off the pot.
That said, no one blames you for doing comparison shopping at monetization time either.
But rather than asking users to pay for newly developed premium functionality, they asked long term users to pay for things that they already had and had always been provided for free.
>Shit or get off the pot.
In this metaphor, they started charging people for using a previously freely accessible pot while they were in mid-shit.
f(domain, secret_word, secret_sentence, rules)
= UPPER(KEY_TO_RIGHT(domain[0:3])) + secret_word + secret_sentence[LENGTH(domain)] + LENGTH(domain) + PAD_TO_20("X")
So if my secret word were "bottleneck" and my secret sentence were "It is a truth universally acknowledged, that a single man in possession of a good fortune, must be in want of a wife." my algorithm generates the following passwords:
google.com:
f("google", "bottleneck", "It is a truth universally acknowledged, that a single man in possession of a good fortune, must be in want of a wife." , rules)
password = "HPPbottleneckacknowledged,6"
(note that "HPP" are the letters on the keyboard shifted right from "GOO")
microsoft.com:
f("microsoft", "bottleneck", "It is a truth universally acknowledged, that a single man in possession of a good fortune, must be in want of a wife." , rules)
password = "ZOVbottlenecksingle9"
The "rules" parameter is because some sites have length restrictions, symbol restrictions, and you may have to truncate the password or replace symbols. Also in "rules" is how many times you've changed a given password. I store the "rules" in a google doc.
Anyway, the nice thing about this system is that the algorithm is in your brain and you can use it to generate the password for a given service without relying on a password manager. So theoretically if I got stranded in Europe as a tourist and my phone got stolen, I'd still be able to get into my accounts (assuming 2FA isn't enabled...).
Password managers definitely generate more secure passwords, but my goal isn't to be the most secure, it's to strike a balance between the things I care about (and I care about being able to get into my accounts if I somehow lose access to my password manager).
Accept no substitutes.
"Multiple users can log into the same database with the same password" isn't multi-user support. It's important to keep several passwords synchronized between family members and very useful to be able to securely share individual passwords with friends on occasion. Without ACLs and user accounts, this is impossible.
There's no official mobile app, which means I have to trust some random developer or live without basic quality of life features such as autofill.
It doesn't support U2F, instead requiring plugins to use a one-time password form of 2FA.
the multi user support is fine but 90 of users have just a bunch of email logins they need to keep rotating. you shouldnt carry your important credentials like bank codes and stuff on live anyways so whats the big deal if you have to remember to rotate a file every 3 months or so? or is that a big deal and being too lazy want to subject yourself to hacks and bugs that will leak data? good luck to you
If the worry is losing your phone, some of the popular services such as Bitwarden can also be accessed via a web interface, without installing the app.
If BitWarden can be accessed from a browser it means all my passwords are on their servers, whereas with an algorithmic password generator the passwords are in my brain alone
You can't delete an entry but you can deprecate it and stop updating it (it's not actually feasible to revoke access anyways).
disclaimer: was involved on the 2fa part of it.
It's a shame, because I think the idea of it is nicer and no less secure than Google Auth, but I'd much rather enter 6 numbers than wait for the app.
Disclaimer: This was around a year ago, perhaps it's improved since.
Do users have a right to exist under legacy covenants when things at the company have changed?
Again, this is why I advocate for shopping at monetization time. The company has altered the deal, maybe you should alter it further?
IIRC, mobile usage _was not_ free, but later became free.
Are there more?
std::atomic<int> n = 0;
n++;
let n = std::sync::atomic::AtomicU32::new(0);
n.fetch_add(1, std::sync::atomic::Ordering::SeqCst);
n += 1
In the C++ code, the programmer thinks this variable n "is" atomic. It's an atomic integer right? But that's not a thing. C++ is mapping atomic integer operations, which are a thing, onto the type, and not making the integer itself magically atomic, it's just an ordinary (aligned) integer.
So if we tweak both examples to do some slightly trickier arithmetic...
std::atomic<int> n = 0;
std::atomic<int> m = 0;
n++;
m= m + n;
use std::sync::atomic::{AtomicU32, Ordering};
let n = AtomicU32::new(0);
let m = AtomicU32::new(0);
n.fetch_add(1, Ordering::SeqCst);
m.fetch_add(n.load(Ordering::SeqCst), Ordering::SeqCst);
use std::sync::atomic::{AtomicU32, Ordering};
let n = AtomicU32::new(0);
let m = AtomicU32::new(0);
n.fetch_add(1, Ordering::SeqCst);
m.store(m.load(Ordering::SeqCst) + n.load(Ordering::SeqCst), Ordering::SeqCst);
Anyway I decided to move to bitwarden last week and it works pretty great. No noticeable slowdown at all.