Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
https://hachyderm.io/@joeyh/112180715824680521
This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
Example of what this user JiaT75 did so far:
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
pull requests mentioning xz, 5.6 without downgrade, cve being mentioned in the last 60 days:
https://play.clickhouse.com/play?user=play#U0VMRUNUIGNyZWF0Z...
If there were a bunch of people who adopted it abnormally fast compared to usual, might point to there being more "bad actors" in this operation (said at the risk of sounding paranoid if this turns out to be a state run thing)
The thing about enterprise Linux distros is that they have a long support period. Bug fixes and security patches pile up.
Fortunately though, xz doesn't seem to have a lot of backported patches.
https://git.centos.org/rpms/xz/blob/c8s/f/SPECS/xz.spec https://git.centos.org/rpms/xz/blob/c7/f/SPECS/xz.spec
But take glibc for example. The amount of patches makes my head spin.
https://git.centos.org/rpms/glibc/blob/c8s/f/SPECS/glibc.spe...
After ~x.4 things slow down and only "important" fixes get backported but no new features.
After ~x.7 or so different processes and approvals come into play and virtually nothing except high severity bugs or something that "important customer" needs will be backported.
The goal is that 8.6, 9.2 and 9.4 will have releases at least every two weeks.
Maybe soon all Z streams will have a similar release cadence to keep up with the security expectations, but will keep a very similar expectations that you outlined above.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
https://web.archive.org/web/20110831134700/http://tukaani.or...
> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.
> *Features*
> * Compiled code 8-20 KiB
> [...]
> * All the required memory is allocated at initialization time.
This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.
One of my complaints about so many SciFi stories is the use of seemingly conventional weapons. I always thought that with so much advanced technology that weapons would be much more sophisticated. However if the next "great war" is won not by the side with the most destructive weapons but by the side with the best kill switch, subsequent conflicts might be fought with weapons that did not rely on any kind of computer assistance.
This is eerily similar to Einstein's (purported) statement that if World War III was fought with nuclear weapons, World War IV would be fought with sticks and stones. Similar, but for entirely different reasons.
I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
Because the slow blade penetrates the shield. (And personal shields are omnipresent)
At least part of the reason is that the interaction between a lasgun and a shield would cause a powerful explosion that would kill the shooter too. No one wants that and no one will give up their shield, so they had to go back to melee weapons.
> However, a great reaction against computers has resulted in a ban on any "thinking machine", with the creation or possession of such punishable by immediate death.
tl;dr - Machine intelligences existed in Dune history, were discovered to be secretly controlling humanity (through abortion under false pretenses, forced sterilization, emotional/social control, and other ways), then were purged and replaced with a religious commandment: "Thou shalt not make a machine in the likeness of a human mind"
The reason nobody tries to use the lasgun-shield interaction as a weapon is because the resulting explosion is indistinguishable from a nuclear weapon, and the Great Convention prohibits the use of nukes on human targets.
Just the perception of having used a nuclear device would result in the House which did so becoming public enemy #1 and being eradicated by the Landsraad and Sardaukar combined.
@Potro: If you liked the movie, read the books. I don't read a lot anymore, but during sick leave I started with the first book. Didn't stop until I finished the main story, including the sequels by Frank Herbert's son about a month later. That's like... uh... nine books?
Because the author wanted a pseudo-medieval setting.
(The shields and the prohibition against computers, nukes etc were just clever plot devices to make advanced weapons unusable).
There is a way for programs to implement the systemd readiness notification protocol without using libsystemd, and thus without pulling in liblzma, which is coupled to libsystemd even though the readiness notification protocol does not require any form of compression. libsystemd provides a wide range of things which have only weak relationships to each other.
There are in fact two ways, as two people independently wrote their own client code for the systemd readiness notification protocol, which really does not require the whole of libsystemd and its dependencies to achieve. (It might be more than 2 people nowadays.)
* https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems...
The reality is that it is not systemd specifically but our modern approach to software design where we tend to rely on too much third party code and delight in designing extremely flexible, yet ultimately extremely complex pieces of software.
I mean this is even true as far as the various CPU attack vectors have shown in recent years, that yes speculative execution is a neat and 'clever' optimization and that we rely on it for speed, but that maybe that was just too clever a path to go down and we should've stuck with simpler designs that would maybe led to slower speedups but a more solid foundation to build future CPU generations on.
BeOS isn't getting a lot of CVEs attached to it, these days. That doesn't mean its good or secure, though.
Then the code should not be complex. Low-level hacks and tricks (like pointer juggling) should be not allowed and simplicity and readability should be preferred.
To be clear, I have no idea how to solve this problem; I just don’t think saying that all code must be non-hacky is the right approach.
I hate this argument. If current hardware promises you a theoretical throughput of 100 MB/s for an operation, someone will try to hit that limit. Your program that has no hard to understand code but gives me 5 MB/s will loose in the face of a faster one, even if that means writing harder to understand code.
Another favorite of mine is bitshifting / bitwise operators. Clear and obvious? Depends on your background. Fast as hell? Yes, always. It isn’t always needed, but when it is, it will blow anything else out of the water.
Bitwise is highly context dependent. There are simple usages like shifts to divide/multiply by 2. Idiomatic patterns that are clean when wrapped in good reusable and restricted macros, like for common registers manipulation in microcontrollers. And other uses that are anything from involuntary obfuscation to competition grade obfuscation.
Clean code should not do that as the compiler will do that.
Clean code should just say what it wants to do, not replace that with low-level performance optimizations. (Also wasn't performance to be obtained from newer hardware?)
I never said performance should come only from newer hardware. Only that it is possible to trade vs hardware/costs - unlike correctness and trust.
Performant code needn’t be unclean; it’s just often using deeper parts of the language.
I have a small project that became absolute spaghetti. I rewrote it to be modular, using lots of classes, inheritance, etc. It was then slower, but eminently more maintainable and extensible. I’m addressing that by using more advanced features of the language (Python), like MemoryView for IPC between the C libraries it calls. I don’t consider this unclean, but it’s certainly not something you’re likely to find on a Medium article or Twitter take.
I value performant code above nearly everything else. I’m doing this for me, there are no other maintainers, and it’s what I enjoy. You’re welcome to prioritize something else in your projects, but it doesn’t make other viewpoints objectively worse.
I maintain ML libraries that run on microcontrollers with kilobytes of memory, performance is a friend of mine ;)
1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!
2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.
Any government which uses GNU/Linux in their infrastructure can pitch this as an attempt to backdoor their servers.
The real question is: will we ever even know who was behind this? If it was some mercenary hacker intending to resell the backdoor, maybe. But if it was someone working with an intelligence agency in US/China/Israel/Russia/etc, I doubt they'll ever be exposed.
Such a system could theoretically bring greater transparency and responsibility, particularly in an ecosystem where contributions come from all corners.
Implementing verifiable identity proofs for contributors might be challenging, but it also presents an opportunity to bolster security without compromising privacy and the freedom to contribute under pseudonyms.
The accountability of those accepting pull requests would also become clearer, potentially reducing the risk of malicious code being incorporated.
Of course, establishing a robust validation chain for software would require the commitment of everyone in the development ecosystem, including platforms like GitHub. However, I view this not as a barrier but as an essential step towards evolving our approach to security and collaboration in software development.
So you review would need to guess from 2 new test files that those are, decompressed, a backdoor and could be injected which was never in the git history.
This was explicitly build to evade such reviews.
OK, that is absolutely devious.
And? You never do any mistakes? Google "underhanded C contest"
In a large tech company (including ones I have worked at), sometimes you have policy where every change has to be code reviewed by another person. This kind of stuff isn't possible when the whole project only has 1-2 maintainers. Who's going to review your change other than yourself? This is the whole problem of OSS right now that a lot of people are bringing up.
I maintain a widely used open source project myself. I would love it if I could get high quality code review for my commits similar to my last workplace lol, but very very few people are willing to roll up their sleeves like that and work for free. Most people would just go to the Releases page and download your software instead.
Maybe someone can disrupt the open source funding problem by brokering exploit bounties /s
(I have written a TOTP implementation myself. I do not have a GH account, and likely never will.)
What makes TOTP different from a password in terms of use or refusal?
The main problem I have with MFA is that it gets used too frequently for things that don't need that much protection, which from my perspective is basically anything other than making a transfer or trade in my bank/brokerage. Just user-hostile requiring of manual action, including finding my phone that I don't always keep on me.
It's also often used as a way to justify collecting a phone number, which I wouldn't even have if not for MFA.
The worse part is that people think they're more protected, when they're really not.
It's very easy to permanently lose accounts when 2FA is in use. If I lose my device my account is gone for good.
Tokens from github never expire, and can do everything via API without ever touching 2FA, so it's not that secure.
Incorrect, unless you choose not to record your seeds anywhere else, which is not a 2fa problem.
2fa is in the end nothing more than a 2nd password that just isn't sent over the wire when used.
You can store a totp seed exactly the same as a password, in any form you want, anywhere you want, and use on a brand new device at any time.
You know google authenticator app introduced a backup feature less than 1 year ago right?
You know phones break all the time right?
When I said they are just another password, I was neither lying nor in error. I presume you can think of all the infinite ways that you would keep copies of a password so that when your phone or laptop with keepassxc on it breaks, you still have other copies you can use. Well when I say just like a password, that's what I mean. It's just another secret you can keep anywhere, copy 50 times in different password managers or encrypted files, print on paper and stick in a safe, whatever.
Even if some particular auth app does not provide any sort of manual export function (I think google auth did have an export function even before the recent cloud backup, but let's assume it didn't), you can still just save the original number the first time you get it from a qr code or a link. You just had to know that that's what those qr codes are doing. They aren't single-use, they are nothing more than a random secret which you can keep andbcopy and re-use forever, exactly the same as a password. You can copy that number into any password manager or plain file or whatever you want just like a password, and then use it to set up the same totp on 20 different apps on 20 different devices, all working at the same time, all generating valid totp codes at the same time, destroy them all, buy a new phone, retrieve any one of your backup keepass files or printouts, and enter them into a fresh app on a fresh phone and get all your totp fully working again. You are no more locked out than by having to reinstall a password manager app and access some copy of your password db to regain the ordinary passwords.
The only difference from a password is, the secret is not sent over the wire when you use it, something derived from it is.
Google authenticators particular built in cloud copy, or lack of, doesn't matter at all, and frankly I would not actually use that particular feature or that particular app. There are lots of totp apps on all platforms and they all work the same way, you enter the secret give it a name like your bank or whatever, select which algorithm (it's always the default, you never have to select anything) and instantly the app starts generating valid totp codes for that account the same as your lost device.
Aside from saving the actual seed, let's say you don't have the original qr code any more (you didn't print it or screenshot it or right-click save image?) there is yet another emergency recovery which is the 10 or 12 recovery passwords that every site gives you when you first set up totp. You were told to keep those. They are special single-use passwords that get you in without totp, but each one can only be used once. So, you are a complete space case and somehow don't have any other copiesbof your seeds in any form, including not even simple printouts or screenshots of the original qr code, STILL no problem. You just burn one of your 12 single-use emergency codes, log in, disable and re-enable totp on that site, get a new qr code and a new set of emergency codes. Your old totp seed and old emergency codes no longer work so thow those out. This time, not only keep the emergency codes, also keep the qr code, or more practical, just keep the seed value in the qr code. It's right there in the url in the qr code. Sometimes they even display the seed value itself in plain text so that you can cut & paste it somewhere, like into a field in keepass etc.
In fact keepass apps on all platforms also will not only store the seed value but display the current totp for it just like a totp app does. But a totp app is a more convenient.
And for proper security, you technically shouldn't store both the password and the totp seed for an account in the same place, so that if someone gains access to one, they don't gain access to both. That's inconvenient but has to be said just for full correctness.
I think most sites do a completely terrible job of conveying just what totp is when you're setting it up. They tell you to scan a qr code but they kind of hide what that actually is. They DO all explain about the emergency codes but really those emergency codes are kind of stupid. If you can preserve a copy of the emergency codes, then you can just as easily preserve a copy of the seed value itself exactly the same way, and then, what's the point of a hanful of single-use emergency passwords when you can just have your normal fully functional totp seed?
Maybe one use for the emergency passwords is you could give them to different loved ones instead of your actual seed value?
Anyway if they just explained how totp basically works, and told you to keep your seed value instead of some weird emergency passwords, you wouldn't be screwed when a device breaks, and you would know it and not be worried about it.
Now, if, because of that crappy way sites obscure the process, you currently don't have your seeds in any re-usable form, and also don't have your emergency codes, well then you will be F'd when your phone breaks.
But that is fixable. Right now while it works you can log in to each totp-enabled account, and disable & reenable totp to generate new seeds, and take copies of them this time. Set them up on some other device just to see that they work. Then you will no longer have to worry about that.
But if you forgot to do it on day one, you can't do it on day two because there is no way of getting them out other than rooting the phone.
Giving how your premise was wrong, I won't bother to read that novel you wrote. I'll just assume it's all derived from the wrong premise.
The fact that you did not know this does not change this fact.
I acknowledged that web sites don't explain this well, even actively hide it. So it's understandable not to know this.
But I also reminded that this doesn't actually matter because you WERE also given emergency recovery passwords, and told to keep them, and told why, and how important they were.
You were never at risk of being locked out from a broken device EVEN THOUGH you didn't know about saving the seed values, UNLESS you also discarded the emergency codes, which is not a 2fa problem, it's an "I didn't follow directions" problem.
And even if all of that happened, you can still, right now, go retroactively fix it all, and get all new seed values and save them this time, as long long as your one special device happens to be working right now. It doesn't matter what features google authenticator has today, or had a year ago. It's completely and utterly irrelevant.
My premis remains correct and applicable. Your statement that 2fa places you at at risk was incorrect. You may possibly be at risk, but if so you did that to yourself, 2fa did not do that to you.
Ah yes those… the codes I must go to a public library to print, on a public computer, public network and public printer. I can't really see any problem with the security of this.
And then I must never forget where I put that very important piece of paper. Not in 10 years and after moving 3 times…
What in the world is this library drama?
No one is this obtuse, so your arguments are most likely disingenuous.
But if they are sincere, then find a nephew or someone to teach you how your computer works.
Libraries? Remembering something for 10 years? Moving? Oh the humanity!
So I can keep them on the same device that I keep my passwords, right?
> Or just keep them in a few copies of a password manager db in a few different places.
Great now you no longer have 2FA but just a longer password.
Or not. You decide how much effort you want and where you want to place the convenience vs security slider.
Yes, if you keep both factors not only on the same device but in the same password manager, then both factors essentially combine into nothing but a longer password.
I did say from the very first, that the seeds are nothing other than another password.
Except there is still at least one difference which I will say for at least the 3rd time... the totp secret is not transmitted over the wire when it is used, the password is. That is actually a significant improvement all by itself even if you do everything else the easy less secure way.
And you do not have to store the seeds the convenient less secure way. You can have them in a different password app with a different master password on the same device, or on seperate devices, or in seperate physical forms. You can store them any way you want, securely, or less securely.
The point is that even while opting to do things all the very secure way, you are still not locked out of anything when a single special device breaks, because you are not limited to only keeping a single copy of the seeds or the emergency passwords in a single place like on a single device or a single piece of paper.
You are free to address any "but what about" questions you decide you care about in any way you feel like.
The only way you were ever screwed is by the fact that the first time you set up 2fa for any site, most sites don't explain the actual mechanics but just walk you through a sequence of actions to perform without telling you what they actually did, and so at the end of following those directions you ARE left with the seeds only stored in a single place. And in the particular case of Google Authenticator, stored in a more or less inaccessible place in some android sqlite file you can't even manually get to without rooting your phone probably. And were never even told about the seed value at all. You were given those emergency passwords instead.
That does leave you with a single precious drvice that must not break or be lost. But the problem is only a combination of those bad directions given by websites, and the limitations of one particular totp app when that app didn't happen to display or export or cloud-backup the seeds until recently.
Even now Googles answer is a crap answer, because Google can see the codes unencrypted on their server, and Google can kill your entire gooogle account at sny time and you lose everything, email, drive , everything, instantly, no human to argue with. That is why I said even today I still would not use Google Authenticator for totp.
Except even in that one worst case, you still had the emergency passwords, which you were always free to keep in whatever way works for you. There is no single thing you must or must not do, there is only what kinds of problems are the worst problems for you.
Example: if what you are most concerned about is someone else getting ahold of a copy of those emergency passwords, then you want to have very few copies of them and they should be off-line and inconvenient to access. IE a printed hard copy in a safe deposit box in switzerland.
If what you are most concerned about is accidentally destroying your life savings by losing the password and the investment site has no further way to let you prove your ownership, then keep 10 copies in 10 different physical forms and places so that no matter what happens, you will always be able to access at least one of them. One on goggle drive, one on someone else's google drive in case yours is killed, one on onedrive, one on paper at home, one on paper in your wallet, one on your previous phonr that you don't use but still works, etc etc.
You pick whichever is your biggest priority, and address that need however you want, from pure convenience to pure security and all possible points in between. The convenient way has security downsides. The secure way has convenience downsides. But you are not forced to live with the downsides of either the convenient way or the secure way.
You don't like long full detailed explainations, and you ignore short explainations. Pick a lane!
A friend of mine a long time ago used to have a humorous classification system, that people fell into 3 groups: The clued, The clue-able, The clue-proof.
Some people already understand a thing. Some people do not understand a thing, but CAN understand it. Some people exist in a force bubble of their own intention that actively repels understanding.
In your quest to convince me you forgot to even stop to ponder if you're right at all. And in my view, you aren't.
Perhaps the problem isn't that I don't understand you. Perhaps I understand you perfectly well but I understand even more, to realise that you're wrong :)
No one is stopping you.
This is a silly thing to argue about but hey I'm silly so let's unpack your critique of the classification system
There is no 4th classification. It only speaks of understanding not agreeing.
Things that are matters of opinion may still be understood or not understood.
Whether a thing is a matter of opinion or a matter of fact, both sides of a disagreement still slot into one of those classes.
If a thing is a matter of opinion, then one of the possible states is simply that both sides of a disagreement understand the thing.
In this case, it is not a matter of opinion, and if you want to claim that I am the one who does not understand, that is certainly possible, so by all mrans, show how. What fact did I say that was not true?
Keep trying soldier. You never know. (I mean _I_ know, but you don't. As far as you know, until you go find out, I might be wrong.)
Whatever you do, don't actually go find out how how it works.
Instead, continue avoiding finding out how it works, because holy cow after you've gone this far... it's one thing to just be wrong about something, everyone always has to start out not understanding something, that's no failing, but to have no idea what you're talking about yet try to argue about it, in error the whole time..., I mean they (me) were such an insufferable ass already trying to lecture YOU, but for them (me) to turn out to have been simply correct in every single fact they spoke, without even some technicality or anything to save a little face on? Absolutely unthinkable.
Definitely better to save yourself from that by just never investigating.
You are too busy writing novels and raging at me to read what I wrote with an open mind.
Because if you don't use weak passwords MFA doesn't add value. I do recommend MFA for most people because for most people their password is the name of their dog (which I can look up on social media) followed by "1!" to satisfy the silly number and special character rules. So yes please use MFA.
But if your (like my) passwords are 128+bits out of /dev/random, MFA isn't adding value.
I don't have strong opinions about making it mandatory, but I turned on 2FA for all accounts of importance years ago. I use a password manager, which means everything I "know" could conceivably get popped with one exploit.
It's not that much friction to pull out (or find) my phone and authenticate. It only gets annoying when I switch phones, but I have a habit of only doing that every four years or so.
You sound like you know what you're doing, that's fine, but I don't think it's true that MFA doesn't add security on average.
Right. I don't ever want to tie login to a phone because phones are pretty disposable.
> I don't think it's true that MFA doesn't add security on average
You're right! On average it's better, because most people have bad password and/or reuse them in more than one place. So yes MFA is better.
But if your password is already impossible to guess (as 128+ random bits are) then tacking on a few more bytes of entropy (the TOTP seed) doesn't do much.
Plus, the server/provider side remains a huge weak point too. And the effort of enrolling/giving the user the initial seed is suspect.
This is why the FIDO/hardware passkeys/etc are so much better because is basically hardware enforced two way public key auth, done correctly there isn't any way to leak the private keys and its hard has hell to MITM. Which is why loss of the hw is so catastrophic. Most every other MFA scheme is just a bit of extra theater.
Exactly, that's it. Two parties have a shared secret of, say 16 bytes total, upon which authentication depends.
They could have a one byte long password but a 15 byte long shared secret used to compute the MFA code. The password is useless but the MFA seed is unguessable. Maybe have no password at all (zero length) and 16 byte seed. Or go the other way and a 16 byte password and zero seed. In terms of an attacker brute forcing the keyspace, it's always the same, 16 bytes.
We're basically saying (and as a generalization, this is true) that the password part is useless since people will just keep using their pets name, so let's put the strenght on the seed side. Fair enough, that's true.
But if you're willing to use a strong unique password then there's no real need.
(As to keyloggers, that's true, but not very interesting. If my machine is already compromised to the level that it has malicious code running logging all my input, it can steal both the passwords and the TOTP seeds and all the website content and filesystem content and so on. Game's over already.)
> This is why the FIDO/hardware passkeys/etc are so much better
Technically that's true. But in practice, we now have a few megacorporations trying to own your authentication flow in a way that introduces denial of service possibilities. I must control my authentication access, not cede control of it to a faceless corporation with no reachable support. I'd rather go back to using password123 everywhere.
With MFA even if somebody has your password if they don't have your physical authenticator too then you're relatively safe.
This is part of why MFA just to log in is a bad idea. It's much more sensible if you use it only for sensitive actions (e.g. changing password, authorizing a large transaction, etc.) that the user almost never does. But you need everyone to treat it that way, or users will think it's just normal to be asked to approve all the time.
There are plenty of scenarios where MFA is more secure than just a strong password.
> There are plenty of scenarios where MFA is more secure than just a strong password.
And how realistic are they? Or are they just highly specific scenarios where all the stars must align, and are almost never going to happen?
The point is also that you as an individual can make choices and assess risk. As a large service provider, you will always have people who reuse passwords, store them unencrypted, fall for phishing, etc. There is a percentage of users that will get their account compromised because of bad password handling which will cost you, and by enforcing MFA you can decrease that percentage, and if you mandate yubikeys or something similar the percentage will go to zero.
For a typical person, maybe, but for a tech-minded individual who understands security, data entropy and what /dev/random is?
And I don't see how MFA stops phishing - it can get you to enter a token like it can get you to enter a password.
I'm also looking at this from the perspective of an individual, not a service provider, so the activities of the greater percentage of users is of little interest to me.
That's why I qualified it with "certificate-based". The private key never leaves the device, ideally a yubikey-type device.
Except that phishing doesn't require the private key - it just needs to echo back the generated token. And even if that isn't possible, what stops it obtaining the session token that's sent back?
Sure, you can probably come up with some non-HTTPS scheme that can address this, but I don't see any site actually doing this, so you're back to the unrealistic scenario.
If I were trying to phish someone, I wouldn't attack the public key crypto part, so how domains come into play during authentication doesn't matter. I'd just grab the "unencrypted" session token at the end of the exchange.
Even if you somehow protected the session token (sounds dubious), there's still plenty a phisher could do, since it has full MITM capability.
There's also the issue of how many sites actually use it, as well as how it handles the loss of or inability to access private keys etc. I generally see stuff like 'recovery keys' being a solution, but now you're just back to a password, just with extra steps.
Most people use their phones most of the time now, meaning the MFA device is the same device they're using.
Of the people who aren't using a phone, how many are using a laptop with a built in keyboard? It's pretty obvious if you have a USB dongle hanging off your laptop.
If you're using a desktop, it's going to be in a relatively secure environment. Bluetooth probably doesn't even reach outside. No one's breaking into my house to plant a keylogger. And a wireless keyboard seems kind of niche for a desktop. It's not going to move, so you're just introducing latency, dropouts, and batteries into a place where they're not needed.
Long, random, unique passwords are phishing resistant. I don't know my passwords to most sites. My web browser generates and stores them, and only uses them if it's on the right site. This has been built in functionality for years, and ironically it's sites like banks that are most likely to disable auto fill and require weak, manual passwords.
no. a second factor of authentication is completely orthogonal to password complexity.
It's hard to get a software keylooger installed on a corp. machine. It's easy to get physical access to the office or even their homes and install keyloggers all over the place and download the data via BT.
You are of course correct.
This is where threat modeling comes in. To really say if something is more secure or less secure or a wash, threat modeling needs to be done, carefully considering which threats you want to cover and not cover.
I this thread I'm talking from the perspective of an average individual with a personal machine and who is not interesting enough to be targeted by corporate espionage or worse.
Thus, the threat of operatives breaking into my house and installing hardware keyloggers on my machines is not part of my threat model. I don't care about that at all, for my personal use.
For sensitive company machines or known CxOs and such, yes, but that's a whole different discussion and threat model exercise.
I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.
All very fair points.
For the longest time the max password size was 8 characters and the csr knew what your password was.
Heck I've had Chase security tell me they'd call me back.. dude that's exactly how people get compromised.
They do require 2FA, though.
Now I have to wait for an SMS. Great...
See the sibling comment.
I don't think it's a thing that happens that often in UK etc.; but, it doesn't happen that frequently in the US either. It's just a thing that can potentially happen.
“I pay the bills there” is barely better than nothing, though. We do this in Canada too. It is what I used for a driver’s license one renewal.
This happened the other day while I was on a conference call with perfect audio and video using my phone’s mobile data.
A few weeks back, had some shop which sends out an SMS to inform you the job’s done tell me this is usually hit and miss when I complained about not hearing from them.
And, by the way, the SMS in question never arrived. I don't know if there's some kind of timeout happening, and the network gives up after a while. Some 15 years ago I remember getting texts after an hour or two if I only had spotty reception. This may of course have changed in the meantime, plus this is a different provider.
Source: worked at all the major banks, all the wealthy clients use hardware MFA
Get better banks people :)
This is the default for all their customers, wealthy or not.
https://www.abnamro.nl/en/commercialbanking/internetbanking/...
Ideally they’d just implement passkeys (webauthn/fido). More secure, and it works with iOS, android, 1password, and yubikeys
I pushed YubiKey as a solution and explained in detail why SMS was an awful choice, but they went with SMS anyway.
It mostly came down to cost. SMS was the cheapest option. YubiKey would involve buying and sending the keys to customers, and they having the pain/cost of supporting them. There was also the feeling that YubiKeys were too confusing for customers. The nail in the coffin was "SMS is the standard solution in the industry" plus "If it's good enough for VISA it's good enough for us".
> support
You answered your own question.
https://www.bankofamerica.com/security-center/online-mobile-...
Some will provide and require them for top customers to ensure they are safe.
Here's the thing about SMS: your great aunt who doesn't know what a JPEG is, knows what a text is. Ok, she might not fully "get it" but she knows where to find a text message in her phone. My tech-literate fiancée struggles to get her YubiKey to work with her phone, and I've tried it with no more luck than she's had. YubiKeys should be supported but they're miles away from being usable enough to totally supplant other 2FA flows.
I have a feeling this won't hold true forever. Microsoft has their own authenticator now, Steam has another one, Google has their "was this you?" built into the OS.
Monetization comes next? "View this ad before you login! Pay 50c to stay logged in for longer?"
It's not completely closed, but in practice no one on that list is a small independent open source project, those are all the kind of entrenched corporate security companies you'd expect
Maybe a pubkey system where you choose your own client would be what you’re looking for?
I’m not even sure it is difficult. Most people I’ve talked to in tech don’t even realize it is a possibility. Certificates are “complicated” as they put it.
Not only that, but it's completely impossible to disable or remove that functionality or even make TOTP the primary option. Every single time I try to sign in, Google prompts my phone first, giving me a useless notification for later, and I have to manually click a couple of buttons to say "no I am not getting up to grab my phone and unlock it for this bullshit, let me enter my TOTP code". Every single time.
It's a good spec. I wish more people who spread FUD about it being a "tech-giant" only thing would instead focus on the productive things like demanding proper import/export between providers.
Password manager turns something you know into something you own. If also the something you own is in the password manager itself… it's the same as requiring extra long passwords.
I've never understood how key-based systems are considered better. I understand the encryption angle, nobody is compromising that. But now I have a key I need to personally shepherd? where do I keep it, and my backups, and what is the protection on those places? how many local copies, how many offsite? And I still need a password to access/use it, but with no recourse should I lose or forget. how am I supposed to remember that? It's all just kicking the same cans down the same roads.
True story.
In gh you can generate a limited one, but it's not really clear on what the permissions actually mean, so it's trial and error… which means most people will get tired and grant random stuff to have them working.
(But you are right that a sleeper would be affordable for them.)
Even a team of 10 people working on this - the code and social aspect - would be a drop in the bucket for any nation-state.
Anyway. This team got caught. What are the odds that this state-actor that did this, that this was the only project / team / library that they decided to attack?
Even if an access token to github is stolen, the sudden lack of signed commit should raise red flags. github should allow projects to force commit signing (if not already possible).
Then the access token plus the singing key would need to be stolen.
But of course all that doesn't help in the here more likley scenario of a long con by a state-sponsored hacker or in case of duress (which in certain countries seems pretty likley to happen)
As a state sponsored project. What makes you think this is their only project and that this is a big setback? I am paranoid myself to think yesterdays meeting went like : "team #25 has failed/been found out. Reallocate resources to the other 49 teams."
This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.
Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.
Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.
At the same time, XZ became a cornerstone of major Linxus distributions, being systemd dependency and loaded, in particular, as part of sshd. What could go wrong?
In hindsight, the commercial idea of Red Hat, utilizing the free work of thousands of developers working "just for fun", turned out to be not so brilliant.
A lot of comments in this thread seem to be missing the forest for the trees: this was a multiyear long operation that targeted a vulnerable developer of a heavily-used project.
This was not the work of some lone wolf. The amount of expertise needed and the amount of research and coordination needed to execute this required hundreds of man-hours. The culprits likely had a project manager....
Someone had to stalk out OSS developers to find out who was vulnerable (the xz maintainer had publicly disclosed burnout/mental health issues); then the elaborate trap was set.
The few usernames visible on GitHub are like pulling a stubborn weed that pops up in the yard... until you start pulling on it you don't realize the extensive reality lying beneath the surface.
The implied goal here was to add a backdoor into production Debian and Red Hat EL. Something that would take years to execute. This was NOT the work of one person.
Nation states will go to long lengths to disguise their identity. Using broken Russian English when they are not Russian, putting comments in the code of another language, and all sorts of other things to create misdirection.
This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.
It considers trust to be an individual metric instead of leaning more into the graph.
(There are other issues, e.g. the fact that "trust" isn't a universal metric either, but context dependent. There are folks whom you'd absolutely trust to e.g. do great & reliable work in a security context, but you'd still not hand them the keys to your car)
At least kuro5hin modeled a degradation of trust over time, which most models still skip.
It'd be a useful thing, but we have a long way to go before there's a working version.
Kuro5hin had a system which didn't work at all, as you mentioned.
But the best was probably Raph Levien's Advogato. That had a web of trust system which actually worked. But had a pretty limited scope (open source devs).
Now everyone just slaps an upvote/downvote button on and calls it a day.