gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
lovesegfault has quit [Ping timeout: 276 seconds]
lovesegfault has joined #nixos-chat
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-chat
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-chat
lovesegfault has quit [Quit: WeeChat 2.6]
<elvishjerricco> All those DMA security holes with Thunderbolt are prevented on macs using VT-d as early as possible in the boot chain. And the secure boot implementation is a lot more secure than anything else I've heard of.
<pie__> qyliss: ^
<samueldr> one of the annoying misfeature of apple's security is that this is also what is preventing running custom software
<pie__> i was gonna say, cant have those jailbreaks you know
<samueldr> technically speaking I hate poo-poo-ing security practices
<samueldr> but it annoys me how they do it when others have shown that you can make a boot chain that is secure while allowing the end-user to enroll their own keys
<elvishjerricco> Yea all they need to do is allow users to add their own secure boot keys or something
<clever> elvishjerricco: my understanding of the dma attacks, is that they are only possible once the driver has initialized the device and allows things to even try to connect
<clever> elvishjerricco: so you just need to not enable the thunderbolt port until after you have the iommu online
<clever> samueldr: related, when you get a modern mac, and want to run linux on it, you must first fully complete the apple setup (giving it your apple acct details and such) before you can disable secureboot in the gui, and wipe it
<elvishjerricco> clever: That sounds right. But I think it's pretty rare that that's actually done, IIUC.
<elvishjerricco> Plus they did a bunch more stuff for internal pci devices, which are apparently a lot harder, especially device #0
<elvishjerricco> According to the slides anyway
MichaelRaskin has joined #nixos-chat
atlas_ has quit [Ping timeout: 240 seconds]
atlas_ has joined #nixos-chat
<MichaelRaskin> samueldr: well, that's why I sometimes say that large chunks of modern security are actually harmful to society
globin has joined #nixos-chat
globin has quit [Client Quit]
globin has joined #nixos-chat
__monty__ has joined #nixos-chat
<elvishjerricco> `pass-otp` kinda defeats the purpose of using otp for 2FA, doesn't it? If you store both the pass and the otp url in the same place, what's the point?
<MichaelRaskin> elvishjerricco: because OTP is just a way of password manager enforcement anyway?
<__monty__> The point is circumventing silly OTP requirements >: )
<elvishjerricco> MichaelRaskin: Fair point
<MichaelRaskin> Have you _read_ GitHub OTP help? They _recommend_ storing last-ditch recovery codes in a password management. The same that stores your password, presumably
<elvishjerricco> But I can't say I'd call it 2FA at that point.
<MichaelRaskin> It kind of has some 2FA properties
<MichaelRaskin> You need to have a device with your password manager DB at hand, and you also need to unlock the password manager with your master password
<elvishjerricco> Sure, that's a fair point
<__monty__> Real 2FA is too inconvenient for most things imo.
<elvishjerricco> So I shouldn't feel bad about dumping everything in my `~/.password-store`? :P
<MichaelRaskin> Is it encrypted-at-rest?
<MichaelRaskin> (Including when the laptop is in sleep in your backpack)
<elvishjerricco> Yea. I use pass: https://www.passwordstore.org/
<MichaelRaskin> Yeah, you shouldn't feel bad
<elvishjerricco> So as long as the gpg-agent drops the key after 5min like it should, I'm good with a laptop
<MichaelRaskin> Just imagine a case where an attacker gets access to one of your devices with the password DB and also to your password.
<MichaelRaskin> Many of these cases make it highly likely that a physical key will also be stolen…
<__monty__> And the problem with real 2FA is, what if you loose your proof of possesion factor?
<elvishjerricco> __monty__: In theory that's what the recovery codes are for
<MichaelRaskin> Or one of the many multiple-proof-of-posession solutions
<__monty__> Yep, but a second second factor reduces the security, by a lot.
<MichaelRaskin> Well, if stored well enough…
<MichaelRaskin> (given that web browsers are impossible to secure, though…)
<__monty__> Yeah, it's just that storing two things securely is twice as hard as storing one thing securely.
<__monty__> True, what with russia's TLS/SSL subversion.
<MichaelRaskin> Storing a thing securely with one-day access latency is easier than storing a thing on your person securely
<MichaelRaskin> Russia only has SNI DPI, on some networks
<MichaelRaskin> (Well, and the obvious HTTP DPI)
<elvishjerricco> On a semi-related note: I found a cool idea on reddit the other day: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
<elvishjerricco> The basic idea is to do password auth akin to asymmetric crypto, where the private key is derived via a KDF applied to your password. i.e. You never send the password to the server, so you don't have to worry about them accidentally logging it or something
<MichaelRaskin> Note that many challenge-response password auth protocols already do that
<elvishjerricco> I'm sure there are other protocols, yea. That's just the first time I've ever heard of the idea
<MichaelRaskin> I guess everything but web apps uses it now…
<elvishjerricco> Makes me wonder why we don't always do something like that for password auth
<MichaelRaskin> We do, except on the web
<elvishjerricco> Why isn't it common on the web though?
<__monty__> It's only useful *if* you salt that KDF though.
<elvishjerricco> Pretty much any article you read on handling passwords suggests a typical salt&hash solution
<__monty__> Or have it depend on time or something *at least*.
<elvishjerricco> __monty__: Yea that's definitely critical
<__monty__> elvishjerricco: But if you salt then they have to do the same derivation so they have to store your actual password?
<elvishjerricco> __monty__: It's safe for the server to store the salt and send it back to the client so the client can do the salt themselves
<elvishjerricco> no reason the salt can't be public knowledge
<__monty__> elvishjerricco: A single salt isn't enough though.
<MichaelRaskin> Also, server name should be appended to salt
<__monty__> Then people can still just repeat your KDF output.
<elvishjerricco> __monty__: You never share the KDF output
<elvishjerricco> You can't repeat it if you never see it
<__monty__> Oh, use that as a key for a secure connection?
<__monty__> MichaelRaskin: I was talking about the legislation russia's pushing.
<__monty__> I've also heard they compromised root certs for CAs in their territory.
<MichaelRaskin> That part is indeed likely, given some of them are literally government organisations
<__monty__> That means they can MITM any connections certified by those CAs, no?
<elvishjerricco> __monty__: Yea, basically. Like I said, it's roughly analogous to using KDF(pass | salt) as an SSH private key. You never give that key up, but the server with the public key can still auth you
<elvishjerricco> Only thing is a MITM attack, where the MITM steals the "public" key when you first register the password, allowing them to impersonate the server in the future. But obviously that's thwarted by TLS
<tilpner> __monty__: Is it just those CAs, or all CAs?
<MichaelRaskin> __monty__: not exactly; they can issue false certificates certified by this CA (and probably can also abuse some unaware CAs outside Russia)
<MichaelRaskin> One does need to be careful there, though, to avoid triggering too many CT checks
<__monty__> MichaelRaskin: Yeah, but if you can issue a fake cert for a server, you can mitm connections to that server, no?
<MichaelRaskin> (but then again, for _targeted_ attacks they probably just put malware into strategically placed Google Ads)
<MichaelRaskin> __monty__: you can, but risking full disclosure
<__monty__> tilpner: Don't know enough, just something that caught my attention. Met a Phd student of politics or sociology or something. She's doing her Phd about Russia's internet policy.
<MichaelRaskin> A significant thing to remember about Russia's widescale interenet policy is that when they started blocking Telegram, Skype degraded more than Telegram
<__monty__> As in their technical measures sucked?
<__monty__> They're currently pushing for legislation mandating backdoors in all e2e tech.
<MichaelRaskin> Correction: mandating backdoors in all e2e tech provided by operator
<MichaelRaskin> Doesn't look like it is meaningfully applied to overlay-on-top e2ee
<MichaelRaskin> Well, there are competent people in Russian state security, and there are people tasked with carrying out the internet policy
<MichaelRaskin> These are different sets of people
<MichaelRaskin> (Targeted stuff can be competent, incompetent, or incompetent people operating something initially developed by the competent ones)
<MichaelRaskin> The incompetent people at some point blocked >1% of the total IPv4 address space in an attempt to block Telegram (this wasn't enough to block it completely, though)
<__monty__> E2e provided by operators? Is there any e2e provided by operators?
<MichaelRaskin> Well, site operators
<MichaelRaskin> WhatsApp claims to provide it
<__monty__> Then I'm not sure what overlay-on-top e2e is?
<MichaelRaskin> Actually working E2EE like, say, XMPP OTR?
<__monty__> Sure, but doesn't facebook use that for chat?
<MichaelRaskin> Well, a working version is supposed not to be remotely force-updatable
<MichaelRaskin> Good XMPP OTR is a part of the client or a plugin to the client
<__monty__> I was coming at it more from the if backdoors have been developed it'll also be easier to try to get those into other implementations.
<__monty__> ar: Please tell me that's not a real cat. That's the stuff of nightmares.
<ar> __monty__: no idea. looks real to me
pinage404[m] has joined #nixos-chat
<eyJhb> I feel like you don't like kitties __monty__ ?
<__monty__> I do. Not ones that might eat me though.
<eyJhb> All cats secretly wants to eat us
<__monty__> It's not about intent.
<__monty__> It's about ability.
<MichaelRaskin> Most cats are able to eat you given sufficient time and a bit of luck during the initial attack
<MichaelRaskin> But this cat won't need much luck to succeed, true.
<MichaelRaskin> (Although given the proportions, maybe it is well-fed enough to be too lazy to try)
<__monty__> Oh probably definitely.
<__monty__> But still.
<__monty__> Wouldn't live with a tiger.
<MichaelRaskin> Tigers are even larger though.
<__monty__> That's my point.
<__monty__> No wait, read it wrong. Not by much though.
<gchristensen> has anyone tried recompiling their system with that openssh patch which adds U2F support?
endformationage has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 252 seconds]
<MichaelRaskin> gchristensen: I mistakenly thought that readonly /etc would speed up test VM setup (well, it does, but it is around half a second). If you want to use it as a starting point for actually working readonly /etc, though … https://github.com/7c6f434c/nixpkgs/tree/readonly-etc
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 265 seconds]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 276 seconds]
drakonis_ has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis has quit [Ping timeout: 246 seconds]
drakonis_ has quit [Ping timeout: 276 seconds]
<ashkitten> re: earlier discussion about storing otp in password managers: i figure it's exceedingly more likely that someone manages to successfully phish me and steal my password than it is for them to obtain my password database and private key, and manage to crack it open
<qyliss> my thoughts exactly
<MichaelRaskin> Exactly
<qyliss> although they can still steal a single otp and use it once
<ashkitten> if that happened i'd have much bigger problems than the few logins that use otp
<qyliss> They may even be able to phish a backup code
<ldlework> Well it happened. A project I haven't worked on for a few years -- the Dockerfile produces a broken build, the shell.nix still works
<qyliss> :)
<samueldr> some people really stop thinking at the moment they read "two factors", and don't realise that even though this reduces the security of the second factor, they still have _a_ second factor
<samueldr> rather than none
<adisbladis> ldlework: \o/
<adisbladis> Time to remove the Dockerfile? ;)
<samueldr> ldlework: generate the docker image in nix!
<ldlework> I have so much regret for writing this thing in Python
<ashkitten> most phishing attacks would be targeted at people who don't use otp anyways, wouldn't they?
<samueldr> largely cast fishing expeditions, likely
<samueldr> spear phishing? all bets are off
<samueldr> the bank I'm a client of has a quite old 2nd factor auth, like from before it was more of a thing and pretty sure before those standards emerged
<samueldr> it's not a good scheme now, but it's better than none
<samueldr> (questions and answers)
<ashkitten> i'd like to get a yubikey anyways
<ashkitten> for security question style 2nd factor i just generate some random words and put them in my password manager alongside the password
<samueldr> I'm trying to think *when* those 2nd factor questions were added to the bank's site... and I'm drawing a blank... to me it seems like it's been there forever, so likely before 2005
<tilpner> ashkitten: That sounds like a good idea at first, until you consider: "Yes, I need my password reset." "No problem, we just have a few security questions. What city was your mother born in?" "Gahh, I always put random gibberish in"
<ashkitten> tilpner: that's why they're actual words
<samueldr> >> ah, I see it's gibberish, right, what password would be fine for you?
<samueldr> ah
<adisbladis> tilpner: Ye olde town of 1$??N^|s;jH*+
<tilpner> ashkitten: Oh, good. I interpreted "random words" differently
<ashkitten> ahh
<tilpner> As long as you choose from a list of actual cities (perhaps same country), it should be fine
<ashkitten> ofc there's a relevant xkcd
<ashkitten> tilpner: tbh i've never needed to tell another person my security question so far, but i figure it doesn't need to be a real city as long as it's communicable
<tilpner> Yeah, you might get away with fake city names that sounds believable
<tilpner> But why bother, a brute force search over actual city names isn't feasible
<ashkitten> i figure it doesn't matter if it sounds real. the only point is for them to be reading the same thing i tell them
<tilpner> (I don't really believe people will social-engineer their way into _my_ accounts, this is just about not recommending the "random characters in security question" default)
<ashkitten> oof
<samueldr> anyway, the whole UL tag for IoT security smelled bad to me, how would they update it *when* a gaping flaw was discovered?
<__monty__> samueldr: I assume that comment was about what I said? It's not that I don't realize that'd mean you'd still have *a* factor, barring disaster. I was pointing out that "Go forth and multiply," isn't a particularly responsible way to handle second factors.
<samueldr> __monty__: I don't think it was about what you said, but a general thing I've seen at many places
<ashkitten> yeah you can't slap a sticker on there and say this thing will be exactly as secure as it is right now for the rest of its lifetime
<samueldr> "the firmware is validated as secure by UL, so we do not provide updates, as those are not validated as secure by UL" — IoT Vendor
<samueldr> (not an actual quote)
<ashkitten> honestly, that's probably how it'll go
<samueldr> well, it's even worse
<samueldr> because we know there is already at least one IoT firm that used their self-test thing, tweaked the IoT device to pass, then reverted changes
<samueldr> it's assumed that this one did it for good reasons
<samueldr> but is it? and will all do?
<samueldr> the UL IoT thing probably would have been better served by an identifier, and an URL
<joepie91> tilpner: you can bypass security questions pretty trivially anyway.
<joepie91> source: had hardware seized, lost password database, could recover all of my accounts
<tilpner> joepie91: Yes, probably. This just makes it a tiny bit less trivial?
<joepie91> (I also enter random junk)
<adisbladis> I like to call them insecurity questions
<joepie91> I think it was... paypal? where I told them this over the phone when they asked, "oh I dunno, I always enter random characters", and they responded with "oh yeah good call"
<tilpner> joepie91: But my point was that random junk is less secure than random false, but valid, information
<joepie91> how so?
<adisbladis> Less secure against what attacks?
<joepie91> oh, because they will more readily ignore it, you mean? when you ask?
<MichaelRaskin> Attacks on techsupport critical incompetence
<tilpner> Because as you mentioned support might match any random junk with any other random junk
<tilpner> While they hopefully wouldn't do that with actual cities, which they can tell apart
<joepie91> honestly I doubt that that'd be different for plausible values :P
<joepie91> and that probably won't change until we lose the "don't argue with the customer" philosophy in call centers
<__monty__> You had hardware seized? Where's your black hat?
<samueldr> I'm surprised paypal didn't just close off the account "the user lied in their security answers, terms of use breach"
<joepie91> samueldr: Dutch paypal support is actually helpful
<joepie91> difficult to believe, I know :P
<adisbladis> samueldr: He probably didn't have any money in there
<samueldr> (I was obviously being fascetious)
<joepie91> samueldr: and I've more than once had them explicitly agree with me on how stupid their systems are...
<samueldr> (fictitiously fascetious!)
<joepie91> samueldr: well so the thing is, what you said would be 100% plausible for US paypal
<joepie91> but there's a weird divide between US support and NL support
<joepie91> NL support seems to get way more latitude to actually solve problems etc.
<samueldr> I like how apparently if you opened your paypal account before you were 18, they will retroactively apply their rules and close it down at their whim :/
<samueldr> [citation needed]
<joepie91> also a thing that didn't happen to me :P
<samueldr> yet!
<samueldr> it must not have been in their interest
<joepie91> nah, they know my DOB
<joepie91> it just seems like all the enforcement stuff is totally split between locales
<joepie91> and the NL dept doesn't care so therefore none of these rules get applied
<samueldr> that's the thing, most of the reports I've seen is that paypal already has the DOB, it's when they needed something from paypal, or had big transactions, that stuff happened :(
<joepie91> ah well, I've already had all of those
<joepie91> I've had to talk my way out of an impending account suspension over a ToS breach before, and I've done transactions of a few thousand EUR
<joepie91> I've had to have a chargeback fee undone
<joepie91> had to recover my account with zero access, etc. etc.
<joepie91> I think I'm probably safe lol
<joepie91> (....hopefully)
lopsided98 has quit [Ping timeout: 245 seconds]
lopsided98 has joined #nixos-chat
buckley310 has quit [Ping timeout: 240 seconds]
buckley310 has joined #nixos-chat
<__monty__> joepie91: So, you still don't actually know *why* they seized everything?
<joepie91> __monty__: nah, I know
<joepie91> they (wrongly) believed that I knew who did the PSN hack
<__monty__> So the FBI was intervening in the Netherlands on behalf of a Japanese company?
buckley310 has quit [Client Quit]
<joepie91> technically it was the Dutch police on behalf of the FBI
<joepie91> but yes
buckley310 has joined #nixos-chat
buckley3100 has joined #nixos-chat
buckley310 has quit [Ping timeout: 240 seconds]
buckley31002 has joined #nixos-chat
buckley3100 has quit [Ping timeout: 246 seconds]
{`-`} has joined #nixos-chat
drakonis has joined #nixos-chat
<gchristensen> so muchslushy raintoday
<MichaelRaskin> gchristensen: do you have readonly /etc already?
<gchristensen> no
<MichaelRaskin> Then you might want to look if something from my experiments is useful for you (I was measuring how much of VM boot time can be saved by switching to static /etc — not that much for a small test, though)
<MichaelRaskin> eadonly-etc
MichaelRaskin has quit [Quit: MichaelRaskin]
endformationage has quit [Quit: WeeChat 2.6]
endformationage has joined #nixos-chat
<ivan> fun times in using Firefox <ivan> I used Firefox to view a hydra build log for chromium (the log is pretty big) and now my machine is locked up
<drakonis> exciting.
ajs124 has joined #nixos-chat
<joepie91> that moment you realize that you actually have half a UI framework sitting on a shelf already, rather than 'a handful of components'....
<joepie91> I mean, it's the good kind of misremembering, but still :P
__monty__ has quit [Quit: rebootying]
<infinisil> I'm noticing that I'm enjoying browsing reddit much more than youtube
<infinisil> Because I know whatever I upvote won't be used by an algorithm to control future content
<infinisil> With youtube I feel like every hover over any video is being watched carefully
<samueldr> >> Because I know whatever I upvote won't be used by an algorithm to control future content
<samueldr> unless you specifically ask for, the frontpage has been algorithmified to heck recently
<samueldr> and will skew results in a noticeable way depending on your pattern usage
<infinisil> samueldr: Oh? I thought it's just "Select a subset of subreddits, then intersperse the frontpages of the ones selected"
<samueldr> it was, but isn't anymore
<samueldr> it's still within the subset of subreddits, but does not respect the original criterias of mixing them together according to the "best" algorithm from their subreddits
<samueldr> I can see it happening by opening a few links from a "highly engageable" subreddit
<samueldr> in like 5 minutes, the frontpage changes and none of those links are stille there
<samueldr> and if I open that subreddit, these were not the "stable" ordered results
<samueldr> and on updates after "engaging" a lot, it really skews the amount of results to that subreddit
<samueldr> and it shows by the quality of posts that are highly ranked from that subreddit
<samueldr> being interspered within the results I haven't engaged with yet
<samueldr> funnily, since it started happening, I reduced my reddit consumption as I was annoyed by the fact I was shown random bad content
<samueldr> my best guess is that it makes fresher frontpages quicker for end-users, resulting in more clicks
<samueldr> rather than the old meme of "reddit frontpage is all purple"
<joepie91> gotta encourage that addiction- sorry, I mean engagement
<samueldr> exactly!
<samueldr> fun thing is I'm sure most engagement metrics are skewed in making worst experiences in the end
<samueldr> less fulfilling, though addictive
<joepie91> "fun"
<joepie91> but yes :P
<samueldr> (ftr: this has been doctored)
<joepie91> lol