So... how are AT&T able to technically achieve this?

Did Apple screw up in some manner, that accidentally left a venue open for ATT to successfully be able to lock the SIM?

Is there a way Apple can fix this in a future revision, so the customer will be able to unlock their SIM, or ATT won't be able to lock it?

quite a valid point!

just like you can NEVER trust a windows (or mac or even linux box) that was not setup by you, especially if its a corporate box that was given to you pre-installed.

almost every company of mid-size or larger preinstalled MitM certs for their spying firewalls. they don't tell employees that, but netadmins and sysadmins pretty much all know this.

I work at a large networking company and they didn't tell me WHAT they do or HOW they'd spy on me, but I found out via a friend (in germany) exactly what they are doing. in .de, you have to disclose to the employees a lot more than the US requires you to do, and he relayed the info to me about how our corp laptops come preinstalled with corp spyware. ability to active mic, camera, screen caps, all that bullshit in addition to traffic logging.

I'm a network mgmt guy and when I was out interviewing for jobs (the last few years) almost all of them involved DPI and MitM attacks, even though they tried to explain it away as 'troubleshooting information' and 'for the users benefit'. quite bullshitty but they said it with a straight face, like they believe their own BS.

you guys have to start realizing that corp america is all about privacy invasion; of customers and employees, alike. if you have a corp laptop, do NOT login to your home email systems and keep your work laptops entirely clean of anything personal and home related. yeah, even if you see the lock icon on the browser, it means nothing anymore, in a corp LAN.

I don't think you could modify packets that are in an ssl stream and not have ssl detect it and reject the 'broken' packets.

https is mostly secure (other than MitM attacks on certs) and vpn's are also very secure.

I have a vpn and while I use it mostly at home, there is an android client (even for my ancient 2.x android o/s) for the vpn provider I have and so I could get as complete privacy as possible on my phone, while doing inet things.

Smartcards alone are not a solution, because they can be lost or stolen. You want both a smartcard and a PIN/password. You smartcard may get stolen, or your password may get compromised, but it is less likely that both will happen at the same time. You might want to setup a threshold for PINless transactions for, say, purchases under $10, but you still want more security for important stuff.

Yes! What are we trying to set up in the free world . . . another East Germany, where people were not allowed to leave the country?

Take away their passports when they enter the Islamic States. But let them out! They can get new passports when entering the Islamic States.

No. The smartcard is pre-programmed with the public key of the authenticator, and vice versa. Unless someone knows the private key of one of the endpoints, the authentication cannot be faked. A MITM attack will not work.

But what's finally good news for the company is that the Surface gross margin was positive this quarter, which means the company finally starts making money on Surface sales.

I think that someone doesn't understand accounting very well. Thre are all kinds of real costs that don't get factored into the gross, so this report does not show whether or not Microsoft is actually making money on Surface sales. For example, all that advertising cost.

Oh, just please tell the truth . . . you have just "shorted" Home Depot stock this morning, and are now profiting because the Home Depot stock is now tanking! :-)

If you can get at the info, a TLA can coerce you into giving them the information. Unless you're both willing to die and to be tortured to protect the information, you can't both access the information and keep it from them, if they're determined. Of course, if they're just mildly curious you can do it, but then things that work against the phone company should work.

Two factor authentication is no more secure than a longer password. (Granted, it can easily be the equivalent of a MUCH longer password.)

FWIW I think we should switch from passwords to pass phrases. "All cows eat radishes" is much harder to guess than "#iOpqn23!"

I'd like to set it to any number of errors in a row starts increasing the time between allowed login tries, and start the delay with the 2 seconds and square it for each succeeding wrong guess. Also a warning on the login page as soon as even one erroroneous login attempt is detected.

Unfortunately, it's not a standard option, I'm lazy, and I don't have anything valuable on my machine. (E.g., I won't do banking over the internet.)

Besides, it wouldn't matter if CAPTCHA were cracked for his purpose. His purpose is to raise the cost of intrusion to the point where the attackers go somewhere else. Not ideal, but it's probably the best you can do.

Now there are several layered approaches that one can adopt to strengthen the security, but convincing the attackers to pick on someone else is probably the best any of them, or all of them combined, will accomplish. How much security you use depends on what you're protecting. Personally, if I were really after security I'd mount the system on a read only device, checksum everything, and have a daemon that rebooted the system if checksum validation failed. The idea of storing the user passwords on a separate device that can only reply "True" or "False" to a username:password pair has a lot going for it. But is it worth the hassle? That depends on what you're protecting. (For me, no. I don't have anything valuable on my machine except some code I'm developing, and when it's done it will be GPL.)

Because we never had people trying to wipe us out before Muslims came along...

They only fix 2 problems - weak passwords and keyloggers.

That's not true. They also provide protection against:

• Shoulder surfing attacks, which require no compromise to the internals of the endpoint
• Storage of data encrypted with a protocol that later proves vulnerable in some interesting way, such as a key compromise

For example, consider heartbleed. If someone stores your encrypted communication, and later compromises a host's private key, that attacker could ostensibly decrypt those communications. If you use a password, that password is compromised, and it's "Game over, man." If you use a physical token, only the PIN is compromised (assuming the actual verification happens in a separate process).

Ideally, you would still want to issue new PIN codes, but the account hijacking risk would be largely mitigated by the physical token requirement, at least after the n-hour cookie expiration window passes, and you could even eliminate that window by expiring any cookies in your authentication database before bringing it back online after you fix the heartbleed vulnerability.