Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:That's great if you have a mobile phone (Score 1) 213

For this scenario, yes. Without speculating as to how likely it is, it can of course be achieved using a compromised browser (e.g. attacker's CA added as trusted) or a compromised CA (e.g. common CA hacked or compromised in some other way like government agency pressure).

In one of those scenarios, the SMS step doesn't add much, if anything.

It does add a useful step in the case of something like the user's machine being compromised by keylogging, but frankly these days the MITM scenario doesn't seem that unlikely. (Think Snowden revelations level government attacks.)

Comment: Re:That's great if you have a mobile phone (Score 1) 213

Scenario at time of account signup:
Browser - MITM - Server

Scenario after signup:
Browser - (Optional MITM) - Server
User's phone - Attacker's phone - Server

1. Browser sends user's phone number to MITM
2. MITM sends attacker's phone number to Server
3. Server sends SMS code to attacker's phone
4. Attacker forwards SMS code to user (preferably masking the source number, perhaps using an internet SMS gateway)

To the user, the above process was transparent so the account is used normally. At any time the attacker can sign in as the user by requesting the SMS code, neglecting to forward it on to the user, and using it for himself.

This of course relies on a MITM at the time of signup, but the first AC in this thread proposed that the SMS was to ensure the initial signup is secure. It can't be secure if the second channel (SMS) relies on a compromised first channel (MITM attacked HTTPS).

Comment: Re:meanwhile... (Score 1) 755

by l_bratch (#49065741) Attached to: Removing Libsystemd0 From a Live-running Debian System

It won't kill your hardware (I've compiled it on significantly less suitable machines), but it will take a fair while (a number of hours) on a machine of that power.

There's a lot of learning to be done with Gentoo, but once you get it, I think you'll appreciate it considerably.

(Nothing is needlessly complicated or arcane, but it can be rather different to somebody used to most popular distros.)

Comment: Re:meanwhile... (Score 1) 755

by l_bratch (#49065469) Attached to: Removing Libsystemd0 From a Live-running Debian System

I've been running Gentoo since 2005, and my main desktop (which I'm using right now, incidentally) has had the same Gentoo install since 2006. I only got rid of my original 2005 install because I switched architecture (x86 -> x86_64).

If it's sane enough for me to keep it running and fully up to date for nine years without much effort, it must be pretty sane. I'd trust it!

Comment: Re:So (Score 1) 373

by l_bratch (#46267777) Attached to: Report: Valve Anti-Cheat (VAC) Scans Your DNS History

There's no evidence that anything from the DNS cache is sent home at all - perhaps the processing is done locally.

Of course local processing/data can't necessarily be trusted, but this may be just be one of many tests performed to decide the statistically likelihood of cheating.

If anything from the cache *is* sent home, then I will be just as angry as you. At the moment there isn't any evidence for that though.

Behind every great computer sits a skinny little geek.

Working...