Hackers Are Hijacking Phone Numbers and Breaking into Email, Bank Accounts - <AUTHOR> https://www.forbes.com/sites/laurashin/2016/12/21/hackers-are-hijacking-phone-numbers-and-breaking-into-email-and-bank-accounts-how-to-protect-yourself/#b71d52e360f7 <comment><USER2> This happened to me.

1\. I believe it began with the hacker getting DOB/SSN. 2\. Called wireless provider, and hacker forward all calls and texts to a burn phone. Eventually, the hacker ported my wireless phone to another provider/number (not sure which), and the phone registered to my provider did not work anymore. The landline phone was also forwarding calls to another number.* 3\. Hacker gained access to email (as that email was also within the telco's site). At the beginning, the hacker did not reset the password. After I changed the email's password, hacker was still gaining access to our emails and he/she eventually reset the email blocking my access. (reason was all the text and calls was forwarding to his/her burn phone so he/she can reset the pass anytime) 5\. Requested 2FA from bank. 6\. Gained access to bank account.

This was over a course of 3 months. It was a nightmare to resolve and paranoia still remained. The hacker later on went opening several bank accounts. Fortunately, this was discovered early. The entire situation was communicated to the FBI, local police, and bank institutions, but I do not think anyone cared.

*I saw two numbers that were being used within my wireless account site to forward the calls.

<comment><USER3> > The entire situation was communicated to the FBI, local police, and bank > institutions, but I do not think anyone cared.

Why would they care? It happens dozens of times a day, and the criminals are out of their jurisdiction.

If only the police, FBI, politicians, etc. could go after the banks and telcos to improve their security. But no... they see it as their job to destroy security, in order to make you "safe".

<comment><USER4> They won't go after an attacker if there's not a high amount of damage, like $250K or more. FBI guys are swamped with people calling, and there's just not enough agent time to go around. Same for bank fraud. Ever wonder how people get away with popping someone's bank account, transferring to another local account, and walking off with the cash? For a couple grand, no one's gonna spend the time and effort to track you down.

Liability for data breaches limited to companies over X size would be a good idea though.

<comment><USER5> Maybe we should increase the number of agents investigating this stuff, then? Fraud affects many more people than terrorism, but nobody gives the "there's just not enough agents" excuse for that.

Also, only investigating fraud when there's lots of money involved means we're only helping rich people, who need the least help. Losing less money doesn't mean less impact on someone's life if that's all they have.

<comment><USER6> Because people are more terrified about a random bomb hitting a random place once in a while more than their accounts getting hacked and then finding themselves in a big trouble?

<comment><USER7> It takes a lot of work by the military-media-industrial complex to keep people that terrified about such a stupid ginned-up threat.

</comment></comment></comment></comment></comment></comment><comment><USER8> A few months ago I took 3 of my 4 kids to a birthday party at a minigolf course. I played some holes with my youngest I had taken with me, and then left the two older ones at the birthday party with the understanding that their mother would pick them up (as we had discussed earlier)

After leaving the party with my youngest, I went to the grocery store, and then on home. When I got home my wife was gone, which I expected since she was picking up the older kids from the party.

Throughout this afternoon I had not been checking my phone in an attempt to be a bit less connected on the weekends.

About half an hour later my wife comes home totally freaked out and frazzled.

Apparently after I had left, someone went into a T-Mobile store and somehow convinced the associate that my number was theirs. I had received a couple of texts from T-Mobile with a pin number where the store associate had attempted to do something, but I was not aware of them until later.

Once this person had my number, they called my bank, reset my online password, and transferred all of our money from various accounts into one of my checking accounts. The bank then put a hold on everything (thank god).

My wife happened to have been paying bills online while this was happening, and saw it all go down. Her first thought was to call me, then when I didn't answer to call the mom throwing the birthday party.

Birthday party mom told my wife I had left, so my wife assumed that myself and our 3 year old were being mugged or something. The police were involved and she spent a good amount of time freaking out trying to find me.

All in all I had a pretty good afternoon :P

For real tho, it was a freaking mess. Took weeks to get our accounts safe, and we try to avoid using phone numbers for 2fa now.

<comment><USER9> In Singapore they give us a physical token. We have to enter the 2Fa we receive into it to receive a third code to enter into the website. Well I guess it's 3Fa. It is a bit of a hassle but better safe than sorry.

<comment><USER8> Yea, my wife uses a physical token generator now, and I use the app which is bound to my phone. Someone would have to physically have my phone (and unlock it) in order to access my bank now.

<comment><USER10> Are you sure your bank wouldn't allow someone to disable it over the phone like they allowed someone to change your password? People lose cell phones just as they forget passwords, so there is surely a way for customer support to deal with it.

<comment><USER11> In such cases the bank would offer to send new tokens by physical mail to the registered address or receive them in a branch with proper ID.

I recall a case where an important customer was stuck abroad with everything stolen; they were sent replacement tokens and cards to be received at the embassy, which could properly ID them.

<comment><USER10> Why can a bank have such a robust procedure for replacing tokens, and be trusted to follow it, but not have a similarly robust procedure for handling password resets?

<comment><USER11> They definitely can, but some of them don't, especially in USA for various reasons.

I mean, any bank with proper procedures doesn't really have the concept of "online password" that's sufficient to do anything and makes 2FA mandatory; I believe in EU now it would be forbidden for a bank to have simply a username- password authentication.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> So, I've read the article a couple of times, It's pretty long. For those of you looking to get the most bang for your buck, I think the following advice is Golden:

1\. Do NOT secure your sensitive accounts (facebook, primary email, bank accounts, twitter, etc) with your telco phone #. Telco Phone number is NOT secure!

"Create a brand new Gmail email account. Do not connect it to any of your existing email accounts. (When signing up for a new Gmail, you don't need to enter a phone number or current email, although there are fields for you to do so. Leave them blank.) Once you've created the new island-unto-itself email address, create a new Google Voice number." Use this Google Voice # to secure your primary accounts, and don't have your telco # listed in any of those accounts.

But, make sure your New Gmail account is super secure, with a security key, as mentioned in the article.

2\. Check the password recovery methods for all your sensitive accounts and make sure the answers aren't duplicated from any other site. Actually, it's best to remove them, if you can.

If any security experts want to chime in, please do.

<comment><USER13> Or use a Google Voice number to setup 2FA on the same account. That way you can only ever login if you have a device on your person already logged in. If somehow you're away from technology long enough that all your devices are locked, use a printed backup code to unlock one.

<comment><USER12> But, if you use Google Voice number on your other Gmail account, they say it's not recommended because you can get locked out of both.

I think you can use Google Voice number on everything other than your main Gmail account.

So, to be extra safe, after you've set up your 2FA for gmail, make sure to change your recovery phone # to something other than your main telco or google voice number.

<comment><USER13> Same account. You can use the Google Voice number to 2FA its associated gmail account. A printed backup key will protect you from getting permanently locked out. But nobody will be able to login without physical access to your device or printed key.

This is how 2FA was meant to work. It should always require a physical device only you have access to. Otherwise it's just using 1FA two times.

</comment></comment></comment></comment><comment><USER14> While SMS for 2fa is _a_ problem, it's not _this_ problem. Using SMS for _account recovery_ circumvents 2fa and circumvents strong passwords.

</comment><comment><USER15> Last year when I upgraded my phone I was amused — but mostly horrified — by how easily one could get a SIM card for my own phone number with less than a modicum of information on me.

As I required to upgrade my Micro SIM to a Nano SIM, I went to one of my provider's shops and asked for a Nano SIM for phone number X. I was then asked to verbally confirm my name and address — and that's it. No ID card confirmation, no nothing. "Here you go sir, your new SIM card will be active within a few minutes. Can I help you with anything else?". What. the.

<comment><USER16> Last week I walked into a T-Mobile store and asked for a new SIM card to replace one I lost. I gave them the phone number and apparently an invalid pin (the sales rep verified that I gave him the wrong PIN). I asked if I should do something else to verify it was my account and nothing. They didn't ask for name, ID, or anything else, and they didn't charge me for the SIM card. I went home and popped it in and my account had clearly been transferred -- I didn't have to do any other activation steps or anything.

Great customer service experience, but horrible security.

<comment><USER17> Your story reminds me of when I ordered a $200 video card from Staples ship to store. I went to the cashier and told them they should have a video card I ordered. They asked for my name and gave it to me (inside the shipping box so they didn't even know the contents). It's not as bad as getting your phone number stolen but it opened my eyes how easy it would be to "steal" a package.

<comment><USER18> The problem with all these stories is that there is a physical interaction. Maybe there is a video or whatever, but for some reason people easily let their guard down when transaction is conducted in person.

<comment><USER19> That physical interaction is important. It means there's a human being in your country committing a crime on video. That same person could just pick up a product off the shelf and walk out with it too. Either way, they're putting themselves at risk of arrest.

When it's online, there's almost no risk because they're probably in Russia and leave no physical evidence.

<comment><USER20> Never mind the video, you know for a fact they are carrying a tracking device.

</comment></comment></comment></comment></comment></comment><comment><USER21> NIST has already been discouraging the use of SMS for 2fa[0], but that apparently won't stop the subset of incompetent IPSec consultants who still recomment SMS based 2fa.

[0] www.slate.com/blogs/future_tense/2016/07/26/nist_proposes_moving_away_from_sms_based_two_factor_authentication.html

<comment><USER22> so why do well-respected companies like Google and Stripe do it?

<comment><USER23> Because their target markets contain both people who'll gladly spend 50 quid on the latest account security dongle, as well as people who have a Pentium 4 desktop and a 50 quid feature phone. The latter get much more secure when apart from a password, probably on a post it stuck next to the screen, they are inconvenienced to also type in a few digits from SMS.

<comment><USER24> You are 100% correct. But I'm genuinely curious why institutions such as banks/telcos couldn't spare the resources to offer both SMS 2FA and more secure options for those who do care. I can't imagine it's a matter of technical resources as it wouldn't take much. Is it institutional inertia? technical debt?

<comment><USER23> Security model of banks is completely different from everything else. They will only consider 2FA if the total calculated cost /to them/ becomes significant if they don't.

<comment><USER25> ...and if they were to offer a more advanced 2fa option, it'd possibly only appeal to a niche of users that wouldn't significant change (improve) their calculated cost?

<comment><USER23> That's why they probably wouldn't roll out to a voluntary subset on regular accounts.

Tbf, I've had a handful accounts in a few different countries. I've had proper 2FA in most of them (the one I've started with around 2005 uses printed one use codes), SMS codes in one and no 2FA in one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Can anyone recommend a US based bank (or a bank that accepts US customers) that 1) has either a 2FA token for phone e.g. with Google Authenticator, a hardware token, or some kind of other token based factor; and 2) has strong security when calling? I generally don't need a physical presence.

My current two banks don't have direct 2FA enabled. As far as I remember, the questions available to one of my banks (credit union) are simple enough that you could probably find out by doing a public info search somewhere, and the other bank (Chase) has SMS 2fa, but outside of that it's just public database questions (I know this because I had my card number stolen recently, I currently don't have access to my phone as I'm out of the country, and they asked me a few different questions from a public database, like if I had ever lived at ABC Dr., do you know this person, and what is the full name, etc.). I'd much rather be able to give the banks some kind of information that they are required to verify before they can access my account, like a verbal passphrase, but I don't think that's possible (as in, I wouldn't be able to access my account over the phone without the passphrase).

<comment><USER27> I know that USAA offers TOTP 2FA. Not sure about calling though.

<comment><USER26> Sadly, USAA is only open to military service members and their kids. That would be my choice if I could use it.

<comment><USER28> Not true. They offer insurance only to military families. Banking is open to anyone. EDIT: This is no longer true as of 2013.

<comment><USER26> Are you sure? At the link listed below, it seems that it's only available for military.

[https://www.usaa.com/join/start/?productId=bank-checking- cla...](https://www.usaa.com/join/start/?productId=bank-checking-classic)

<comment><USER28> You are right and I was wrong. They changed the rules in 2013: [https://communities.usaa.com/t5/Other/USAA-Changes- Membershi...](https://communities.usaa.com/t5/Other/USAA-Changes-Membership- Eligibility/td-p/26786)

They've grandfathered in existing members who wouldn't qualify today.

</comment></comment></comment></comment></comment></comment><comment><USER29> It's insane how much easier it is to transfer a phone number than a domain name.

I also find it odd Facebook, and other sites will let you signup solely with a phone number. There's prepaid cell phone providers that recycle phone numbers, etc. Just seems so stupid to rely on a phone number for authentication alone, but two factor I'm okay with since you still need to know the password. Twitter has a developer product where you can be texted a code to login using only a phone number, which to me just seems wrong to do.

It'd be nice if trying to port a number, change important info, etc if they had to actually call you or text you first to confirm. But one of the problems is people will lose their phones, and need a new sim or phone... That I think I'd have a requirement to actually visit the store - but that doesn't work to well with prepaid phone providers without physical stores selling via other stores like Walmart, Target, etc. Maybe in that case without nearby stores, partner with your retailers to verify ID or fax a ID in.

<comment><USER30> "There's prepaid cell phone providers that recycle phone numbers, etc. "

This isn't limited to prepaid phone companies or even cell phones. This practice has gone on for years. (I worked at GTE/Verizon around the time of the merger). My understanding is that the bigger issue is that it is fairly easy to run out of phone numbers if we never repeat. If I remember correctly, most hold the number unused for 3-6 month and fewer folks change now since they can port numbers to a new company at times, if the company that owns the number allows for it. (Yes, the phone company at least used to own the number).

</comment></comment><comment><USER31> I wish we could kill phone numbers once and for all. It's insecure, device- dependent, carrier-dependent, country-dependent, subject to snooping and censorship, and all of these are recipes for disaster as an authentication scheme, especially in the event that a device gets stolen. Phone calls and text messages should emphatically NEVER be used to verify anything.

Conversation with one of my banks the other day:

Them: Can we please verify a code sent to your phone number?

Me: Umm, sure, although that won't verify anything. Use something else to verify that it's me.

Them: Can you please verify your phone number?

Me: Umm, I don't know what phone number I used with you? Try XXX-XXX-XXXX, XXX-XXX-XXXX, XXX-XXX-XXXX, XXX-XXX-XXXX, XXX-XXX-XXXX, XXX-XXX-XXXX, and XXX- XXX-XXXX? They all belong to me depending on where I am.

Them: Can we use XXX-XXX-XXXX? Do you have this phone with you right now so we can we send a text message with a verification code?

Me: Send your insecure SMS to any of my numbers. They all go to my e-mail inbox. [I don't need to have my "phone" with me -- my "phones" are virtual.]

<comment><USER32> Is it really necessary or helpful to be rude to the poor CSR who is just trying to do their job?

They didn't make this policy, and I'm sure they think its just as stupid as you do.

<comment><USER33> I would not think CSR would actually know that phone is not a secure channel. I bet they are taught it is.

<comment><USER34> It is still more secure than not using a second factor at all. Stealing a phone number is more work than not having to do it.

</comment></comment></comment></comment><comment><USER35> I owned a hosted PBX company from 2007-2011 and was amazed with how antiquated the port request system truly is.

The problem is that the phone company owns your phone number and you just get access as part of a service. Unlike a domain name where you own it.

If we change the law we'd bring more accountability.

<comment><USER36> To be fair, you really don't own a domain. You still rely on the TLD honoring your purchase and not hand it over to someone else in the same way you rely on the phone company to treat your number as yours.

<comment><USER37> Some domain registrars are so completely incompetent (ie Dotster), I'm disappointed they're still in business. Literally clueless "customer support" staff that either don't auth (experienced that personally), or refuse to follow the written rules to everyone's detriment.

Recent example:

[https://issues.apache.org/jira/browse/INFRA-13657](https://issues.apache.org/jira/browse/INFRA-13657)

Note - Don't use Dotster (specifically) for your domains. If you're using them now, switch away. Saying that because if you experience any trouble with your domains, you'll be wanting to contact competent staff who can fix problems. Dotster's can't. :(

<comment><USER35> At least you have a legal path:

[https://www.google.com/amp/s/www.forbes.com/sites/theyec/201...](https://www.google.com/amp/s/www.forbes.com/sites/theyec/2015/02/28/how- to-recover-from-a-domain-name-hijacking/amp/)

Not exactly an easy thing to do with a phone number.

</comment></comment></comment></comment><comment><USER38> So 2FA reset via SMS is bad, which I agree but what are the alternatives to prevent a meltdown when your 2FA device dies?

I have had two phones die on me that was my 2FA device, plus OS upgrades, so I have gone through resetting 10-20 2FA accounts a few times. Though with upgrades usually I foresaw that and downgraded my 2FA before hand.

All I wish for was that resetting 2FA would be a very very slow step by step process and spammingly broadcasted to all emails, sms, postal etc associated with the account. But I know for cost cutting customer services departments that wont happen.

<comment><USER39> I use 2FA code generator in cloud-synced 1Password. That endures all software upgrades, unlike Google Authenticator or Authy.

<comment><USER16> If you use an Android phone that's rooted, you can use Titanium Backup to copy your Google Authenticator app data between devices. It's up to you to copy that data somewhere else, but it is a very low level alternative to storing everything in 1Password or similar.

<comment><USER40> Even without rooting, just do that that next time when you register for 2FA, save that QR image, or screenshot it, and/or save that 16+ chars string somewhere safe, same as where you save passwords. Phone died/changed/lost? Install Google Auth, rescan that QR/Screenshot.

</comment></comment></comment></comment><comment> awinter-py Not answering security questions truthfully is tricky.

Yes, it's a problem that security questions turn hacking into a simple public records search.

 _BUT_ most terms of service have a line like 'you warrant that you've been entirely truthful with us' or something. If you give the wrong security question to your bank, they potentially have grounds to freeze your money or screw you later.

Why isn't the answer 'consumers have the power -- punish services that don't support FIDO by not using them'.

At best this article is saying 'don't connect anything to anything'.

<comment><USER41> I answer mandatory security questions with things like these:

      "This account must never be unlocked over phone, chat, or email."

      "Never reveal any information about this account (such as address or CC numbers) via support channels"

      "The person you are discussing with is a hacker trying to illegally access this account"

I expect to never, ever have to use the security questions myself.

Sometimes, I enter random phrases.

Never anything that would actually be true.

<comment><USER42> Do you have an recovery scenario in case you'd actually need those?

I was almost there once. Authenticator device had died, and to my horror the primary backup was corrupt as well. I had a secondary backup (and even an off- site tertiary one, although it's somewhat dated), so I was able to recover... But I also had the idea that I won't ever have to use recovery processes and even though I hadn't, after the incident my certainty it's not so iron-clad.

<comment><USER43> I wish I could elect to have my recovery option be painful. I'll use a yubikey and backup codes. If I lose both of those, mail me something to confirm my identity, all the while notifying me on all other channels (email, sms, phone) that an account reset is happening. I am okay waiting a few weeks for access to my account if I manage to lose my primary and backup access methods.

</comment></comment></comment></comment><comment><USER44> This recently happened to a friend of mine. It was devastating. As mentioned, U2F is very scarcely supported today.

The best way he came up with to secure services that insist on using SMS for 2FA (or credential reset) was to _register the number of a pre-paid phone for those services._

Inconvenient? YES. But a pre-paid phone number can not be ported by a negligent (or willfully criminal!) operator.

<comment><USER45> It's still very trivial to tell a customer rep that you lost your SIM card and have the rep send all new communication to the phone number to a separate SIM card with a pre paid phone.

<comment><USER46> If you only use this pre-paid phone for authentication, then the fraudster has to discover that phone number before they launch their attack. For additional security, you can rotate this pre-paid phone number every few months, and only use it for authentication to online services.

</comment></comment></comment><comment><USER47> What settings exactly do I have to change to get GMail to never unlock my account by SMS alone?

I have enabled proper 2FA on my Google account with U2F, but I haven't disabled everything else yet because I only have one token, and I still need something like TOTP for stuff that uses Google accounts, but doesn't support U2F.

As a closely related remark, I wish U2F would just get popular enough, it's pretty convenient, isn't vulnerable against the kind of attack SMS-based 2FA is, and protects against phishing. But almost nobody outside Google supports it, and OS/Application support is rather incomplete or requires additional setup.

<comment><USER48> Something that is infuriating is that when you have 2FA enabled on Google, they _insist_ that you add a backup phone number that a bot calls to give you a verification code, in case, you know, you lost your second factor. Which is nice and all, but now, you're back to having a second factor that is about as vulnerable as SMS.

<comment><USER49> You can remove the phone after you add another factor (ex: TOTP device).

</comment></comment></comment><comment><USER50> Would this attack be neutralized by a mandatory waiting period of a few weeks for number porting? I recently ported my number to another operator (in a European country), I had to wait for a month and received at least two warning SMS.

<comment><USER51> It would but the average user would be pissed if they went into a retail store and were told that they had to wait weeks to use their new phone. They might decide to abort the purchase.

<comment><USER50> I didn't think about that, because all phones here have a removable SIM card.

</comment></comment></comment><comment><USER42> 2FA (including U2F and whatever else) has one big problem that this article fails to mention. And when 2FA is suggested, this really should be said explicitly.

Users aren't warned enough about the fact that everything fails, and they will have to go through 2FA deactivation/account recovery process sooner or later. They must be really reminded to _DO BACK UP_ the recovery code(s). With "back up" as in "keep not just somewhere, but where you can actually find it, when you'll need it". (But not in your password manager)

This is true for SMS 2FA as well, but completely losing the number (as long as one's a paying customer) must be significantly less common than losing a device.

<comment><USER19> This is what somehow doesn't get mentioned as much as security. It's a tradeoff between not getting hacked, not getting locked out by accident, and convenience. If you get locked out of Gmail, you're up the creek. Google won't help. It's just gone forever.

Having 2 factors increases the chance that you'll lock yourself out. If you've got two, then you really need 4:

1) Password

2) 2FA

3) Backup codes for when you lose the 2FA device/number

4) Phone number or email address for password recovery when you forget your password. Not the same number as 2 of course.

</comment></comment><comment><USER52> Many phone companies will allow you to (a) add an annotation to your account to declare the number you are using should never be ported to another company, and (b) add a password to the account that you will have to provide to customer service representatives when making changes. This helps to minimize the chance that an attacker can use social engineering to redirect your number to a system under his or her control. If these are not options for your phone company, find a better phone company.

Even given that, since it relies upon human choice and behavior, and does nothing versus attackers with assets within the phone company, it seems a bad idea to have 2FA via SMS.

</comment><comment><USER53> 5 or 6 years ago, my phone number got ported by someone else without my knowing. My phone suddenly didn't work anymore. I called into AT&T right the way to ask what's going on and they said someone has "took over billing" from my account and AT&T transferred the number over. WTF? I was adamant to get the number back since that's the number I give it out to people. They won't bungle saying it's out of their hand. Finally they said they could place the number into the free pool for re-allocation which would freeze it for 3 months before it could be used again. I was concerned it could be used as a vector against my bank accounts. It was a nightmare.

<comment><USER54> So basically as long as a hacker wouldn't mind paying your phone bill for a month they could easily take over billing of it, then clean your accounts out, then cancel the number.

This is another one of those messy human areas where computer systems are either too strict or not strict enough.

</comment></comment><comment><USER55> I highly suggest having at least 2 phone numbers, one that is your main number that you use and give out. The others are kept private and never for calls or texts, but only for 2FA.

<comment><USER56> I did this with TMobile when they had get 3 lines and get 4th free. I use the 4th free line as my 2FA. The 2FA line is an old android phone and is always plugged in & on in my basement. I have a little script on the phone that reports any SMS messages a db running on my home server (RPi) and I access it with in my network (or via VPN).

</comment></comment><comment><USER57> Great. Now that we've succeeded in compiling a list of personal sad stories to one up one another, why not not discuss how we could encourage the banks / phone companies to make this situation impossible.

1) Ban SMS as a second factor for high risk targets like banks.

2) Telecom companies should require social security number or uniquely identifying information to provide account access.

3) ???

<comment><USER58> > 1) Ban SMS as a second factor for high risk targets like banks.

As others have pointed out, if it were just a second factor they would also need your password. SMS is being used for full account recovery, so as a single factor.

> 2) Telecom companies should require social security number

This is exactly what we should _not_ be doing. I would like it to be harder to steal my identity than getting a 9-digit number, which can never be rotated, and which I am required to provide in plaintext to many different people in many different situations (renting an apartment, opening a credit card, etc.).

To make matters even worse, up to the first 5 digits of an SSN can be easily guessed if you know the person's age and birthplace, and the last 4 digits are used even more haphazardly than the entire number is (e.g. sometimes the last 4 are displayed in plaintext on a website while the first 5 are starred out).

</comment></comment><comment><USER59> Someone should write a comprehensive guide on how to protect your accounts while preventing yourself from being locked out of said accounts.

Seems like some combination of the following:

* using Google Voice for all account recovery situations that require a phone number

* Calling your cell phone provider to have a note that states do not allow for number porting

* Use hardware 2fa tokens. Have two setup, one as a backup in case you lose one.

* Keep a copy of your recovery codes somewhere accessible

* Probably have a safety deposit box with your backup 2fa token and recovery codes stored.

* Primary email provider should use a hardware token and not have sms recovery

* Use unique passwords everywhere and use a password manager

</comment><comment><USER60> Security while we all say is super important will never be important until people doing the customer service actually care. When my identity was stolen 20 years ago it was a nightmare involving writing letters to a postbox and getting form letters in return... doing to the police, the banks, and the utilities and being treated like an idiot because I filled out a rental application that someone used to get credit cards is a nightmare that still follows me to this day. It's as if all forms of customer service needs to go through a third party.

<comment><USER61> "It's as if all forms of customer service needs to go through a third party."

.. and therein lies opportunity for the tech-preneurs

</comment></comment><comment><USER62> A few months back I lost my phone, so I went to my operator with passport to get new sim with my old number (in Thailand) . She said the sim isn't actually in my name but my ex-girlfriend's, and I told I remember I took the sim with her id as I didn't carry my passport with me, so I guess there's nothing I can do.

She just replied well we could change the sim to your name, didn't even check with the original owner and 5 minutes later I was on my way with new sim.

</comment><comment><USER63> A couple of years ago i got a new phone which used mini sim instead of the micro sim that my older phone used. So i went to an AT&T store to get it and the rep asks for my name and my phone number and 5 minutes later comes back with a new sim saying it'll activate my noon the next day.

There was no authentication at all. Literally anyone could have walked in gave my name and phone no and would have gained access to my phone. I stopped using my phone for 2FA since then.

</comment><comment><USER64> Companies are calling it "two factor authentication", which it is not. Please, hn, don't promote sms 'authentication' at your jobs. TOTP is easy to implement and not never difficult for users to understand.

</comment><comment> EZ-E This kind of attacks could lead to total disasters in China where the standard is to login and register solely on a phone number using a confirmation text.

In China your phone number is pretty much as valuable as all your password combined, all services are solely linked to it.

Even though phone companies ask for id before issuing a SIM card, I'm pretty sure a tiny bribe is enough to get past most store clerks

<comment><USER19> ID isn't just for security, it's so the police can track you. So they'll be putting pressure on phone companies to do it thoroughly. They take a copy of my passport when I get a SIM card. Probably not going to bribe them into leave missing documentation on your file. They could easily be caught by their boss at any time in the future.

</comment></comment><comment><USER65> A few weeks ago I was vacationing in Big Bend National Park, which is in a remote corner of Texas. When trying to pay for our breakfast, my credit card was declined.

On the phone with them, they said the card had been flagged as being used in fraud because we were off in the middle of nowhere, away from our normal spending patterns. The ONLY way to reactivate the card is for the CC company to SMS text us with a code, which we have to read back to them. The thing is, the very reason they flagged us - that we were way off in the middle of nowhere - also meant that we had no cell phone service, and couldn't receive the SMS. And given the vast size of Big Bend (getting out of the park from the hotel is a 45 minute drive), it was questionable if I'd be able to drive to a location with cell service if I couldn't fill my gas tank first.

The hotel manager overheard me arguing on the payphone with the credit card company, and he drew me a map of some pockets of cell service within the park, so in the end I was able to get it taken care of.

One ironic part of this was that the card is in my wife's name. When they wouldn't listen to her, she gave them verbal authorization to talk to me in her stead. They were willing to believe her identity for this, but not for the re-activation of the card, which doesn't make sense.

I also asked their CSR why they flagged the card. They said that I should always notify them if I'm going away. I asked them what the criteria is for that, since this was an in-state trip (I live in Austin, and Big Bend is also in Texas). The CSR said that's odd, and he doesn't know why that would happen.

So good for them that they watch for fraud, but the failure mode for their heuristic is the most catastrophic possible. If the very reason they flag me _also_ prevents me from fixing the problem, then it's a rather badly-designed system.

<comment><USER66> This used to happen to me all the time with Lloyds "Worldwide Service". When I would travel, I would tell them ahead of time where and when, and inevitably the first time I used my card in another country it was declined and I'd need to call in to card security and clear it. Mind you this would cost a couple quid due to the overseas use of my phone. These weren't exotic locations either, it would happen in NYC.

Then one time to me it happened when I was exhausted after a very long flight, trying to check into a hotel. I got on the phone with them, sternly told them the history of events and the situation, and demanded to be compensated for the time and hassle otherwise I would switch banks. I pointed out their bank was misnamed "Worldwide Service". They put £100 in my account, and the problem seemed to go away after that point (I still needed to inform them ahead of time, but that did the trick).

</comment></comment><comment><USER67> Does this hack work on Google accounts? I just tried the "forgot password" feature there and as far as I can tell there's no way to actually complete a password reset with only a compromised phone number.

</comment><comment><USER68> The issue I have with 2FA without sms is that I need to also take care of recovery codes. Basically, it's like erasing all the benefits of going digital, since now I have to store (and take care of) paper copies of recovery codes.

If I use a 2FA app like the Google one and lose my phone, I need to have the codes ready. If I were to use my phone number, I kind of don't need that since I just get a new sim and a new phone. But at the same time that is not safe now.

So what is the solution here? I liked the idea of something like DUO but not enough places use it.

<comment><USER69> > If I use a 2FA app like the Google one and lose my phone, I need to have the > codes ready.

It is a trade off. You either want difficult access if you lose your phone (via printouts) - or you want quick access (via SMS).

I dont think you can realistically have it both ways.

Having a "slow" method to retrieve a major access to your accounts seems to be the safest method, especially when you are likely to rarely use your phone.

You could also give a copy of the printouts to a family member or close friend, who you could ring if you were remote.

<comment><USER68> I guess you are right. It's not like I am using those codes all the time, so the inconvenience is tolerable.

</comment></comment></comment><comment><USER70> Years ago, when SMS 2FA first became a thing, I remember people familiar with telecom stuff pointing out SS7 vulnerabilities and porting/SIM takeover issues. People shouted them down and claimed that they were being too paranoid and exaggerating the risk, or that most people aren't attractive-enough targets for someone to dedicate so much effort for hacking their accounts (and that SMS 2FA was thus good enough for most people).

</comment><comment><USER71> If I want to change my number to a new SIM, my telco requires me to log in, and fill in a form. If I forgot my password their email it to me.

They don't have any offices open to the public, nor any hotline, and are really the cheapest alternative where I live, but it seems that their attempts to save money have resulted in them ending up with a securer infrastructure than some notorious ones from very advanced countries.

</comment><comment><USER72> You should also make sure providers like Google don't fall back to less secure account recovery methods. I blogged about this here, after I realized that I was still vulnerable even while using real 2FA:

[https://ericrafaloff.com/google-account-security-and- number-...](https://ericrafaloff.com/google-account-security-and-number- portability/)

<comment><USER73> Regarding the $8k of bitcoin stolen ([https://medium.com/@CodyBrown/how-to- lose-8k-worth-of-bitcoi...](https://medium.com/@CodyBrown/how-to- lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com- ba75fb8d0bac)), that's what you get for storing your coin in Coinbase or someone else's service. If you're not in control of your keys, you don't own the coins. This uncomfortable truth has a way of occasionally poking out, like that story.

</comment></comment><comment><USER74> What's funny is... my Bank does not allow me to use any special characters and for the investor accounts numerical only. They do not have 2FA either.

CIBC Canada

Addendum also several of my purchases were flagged as hacked purchases by them and I had to call them three times so far this year. All purchases from same Amazon account, same IP too. So I do not think they have a good services team.

</comment><comment><USER75> Take a modified attackers point of view.

Could you convince a cell phone store rep that you are who you say you are without your drivers license?

Or, for a million bucks, could you make a cell phone store rep think you were someone else?

The answer is why SMS 2fa isn't such a great idea. Because your security checkpoint is owned by a (underpaid) store representative.

</comment><comment><USER76> Seems pretty silly putting any form of security apparatus into a technology which could possibly have been engineered from the ground up to be SIGINT- enabled. It's as if GSM was deliberately designed by the intelligence community to be available for eavesdropping. They build the protocol with just enough good security that Johhny can't intercept his wife's calls to check for cheating, but with enough bad security that intelligence services (and sophisticated criminals) can play Mallory[0]

[0]: [https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...](https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters)

</comment><comment><USER77> Anyone here happen to know how hard it is to steal a Twilio number as compared to a number issued by eg T-Mobile or Verizon? Is the only way to do so, by accessing the Twilio account that controls the number (whether directly or by API)?

</comment><comment><USER78> Has anyone tried suing a Telco that's given away access to their phone account?

</comment><comment><USER79> "If you follow several of the steps I outline in this story (unless you go with Google Voice), you'll end up with at least three email addresses: your current primary one, one just for your mobile carrier, and one that you use for other sensitive accounts such as online banking or Facebook or Dropbox."

Why not just have all sites that require SMS 2FA (there are a lot, including tele co.s) be directed to a personal google voice number? And also remove the any SMS 2FA from this google and your personal? Wouldn't that solve the issue they are suggesting? Why do you need a third account?

</comment><comment><USER80> I read a blog where someone got hacked through a simcard clone, and they went into the details of how easy it was to do. This prompted me to enable 2fa on everything I could, but the funny thing is, a lot of the backup options for 2fa is -- you guessed it -- your cell phone number. Some of them don't even allow you not to use your cell phone as a backup. I think Github and Slack are like this, but I may be wrong, it has been a while since I turned them on.

<comment><USER12> The most important thing is: DONT use your telco phone number in any of your sensitive accounts. Replace that phone number with a Secure phone number: the article recommends using Google Voice -> since this can't be compromised in the same way that a telco phone # can be.

</comment></comment><comment><USER81> I am surprised no one here mentioned mooltipass [https://www.themooltipass.com/](https://www.themooltipass.com/)

<comment><USER82> It's another gadget to carry arround, and if you lose it or forget it somewhere, you're SOL. Better have a KeePass2 database on your phone synced to a cloud storage. Even if the cloud account is compromised, without the KeePass password, your credentials should be safe. If you need, you can open the database using a webapp in any browser.

</comment></comment><comment><USER83> Remember this the next time you may tend to agree with governments' push for backdoors. If they get their way even Google Authenticator won't be safe, just as SMS isn't anymore for 2FA, all because the surveillance agencies preferred to keep the SS7 vulnerability and others like it so they can exploit it ( _outside_ of the "rule of law", as otherwise they wouldn't need it).

<comment><USER84> But...if a public that doesn't understand the nature of backdoors is fearful of the consequences of backdoors being cracked, it's a short step to turn attempts to crack the backdoor into something terrifying, in which case an attempt to crack the backdoor becomes a justification for its existence.

Yes, I'm cynical on this matter.

</comment></comment><comment><USER85> For 2FA I like how Microsoft does it. You have an app on your phone. When they need to authorize you, they push to the all and it automatically pops up with approve and decline buttons. You verify the code is the same on the phone and screen and hit approve. It's an easier workflow than having to open Google authenticator, find the code, and enter it.

<comment><USER86> Google is starting to do this as well. You get a push notification instead of entering the code.

</comment></comment><comment><USER87> I'm SHOCKED this wasn't a thing earlier. Spoofing a phone number is insanely easy. When I was in High School we figured out how to do it and used to prank call people from other peoples numbers. Eventually, we realized that if you call someone's cell from their own number it takes you directly into the voicemail admin menu. Fun times.

<comment><USER88> That's a bit different than receiving text messages aimed at a different number.

</comment></comment><comment><USER89> This sort of attacks have been happening for over 5 months in crypto.

Kraken published a highly useful blog post on it. Do give it a read. [http://blog.kraken.com/post/153209105847/security- advisory-m...](http://blog.kraken.com/post/153209105847/security-advisory- mobile-phones)

</comment><comment><USER90> I've noticed a number of people using [https://jmp.chat/](https://jmp.chat/) to get a second number for 2FA. It supports most of the short codes companies use for 2FA, but it doesn't require you have a Google account (or even an existing phone number).

</comment><comment><USER91> These attacks have been going on for at least a decade in South Africa. The fact that it's still going on, and if the coverage is to be believed, spreading globally, is a pretty shocking indictment of the industry.

I wonder what other scams are being incubated in lesser-known parts of the world, that are waiting to be unleashed.

</comment><comment><USER92> Articles like this ramp up my paranoia, especially since I got a phone call from the UK three days ago. Nobody on the other end. Hung up after saying hello three times. Never heard back since. It has me worried, especially since I just came back from my holidays (not in the UK).

</comment><comment><USER93> It seems a simple solution would be for the phone company to send a confirmation SMS or automated voice call to confirm number porting or any other major action. Is there a reason they don't do this? It seems like a good balance between convenience and security.

<comment><USER94> There was this recent case showing how _not_ to do this feature. [https://medium.com/@CodyBrown/how-to-lose-8k-worth-of- bitcoi...](https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin- in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac)

</comment></comment><comment><USER95> Worth reposting Kraken's mobile phone security advisory:

[http://blog.kraken.com/post/153209105847/security- advisory-m...](http://blog.kraken.com/post/153209105847/security-advisory- mobile-phones)

</comment><comment><USER96> Where I live you need a copy of your passport to port a number, in addition the new sim can only be sent to your government registered address, I think that would be quite hard to game.

Even so, hackers can still use SS7 to hijack phone numbers.

<comment><USER97> SS7 is harder to obtain and alot of good operators have now protectons for hiacking via SS7.

</comment></comment><comment><USER98> Take a look at the article by Cody Brown regarding his coinbase account being drained of ETH and BTC due to the same fundamental problem: way too easy to steal someone's phone number.

</comment><comment><USER99> Too many Forbes articles. They're months behind on this story and have an aggressive anti-adblock so I'd rather not see stories from them.

</comment><comment><USER100> Wouldn't the easiest solution be to use a landline and use the call options for 2f? Physical access to my home is root access

<comment><USER101> What is this land line thing you speak of?

</comment></comment><comment><USER102> Resuming: what's the simplest solution to at least reduce risk? Is it to get a second phone number just for banking?

</comment><comment><USER103> What is a good way to make these attacks more difficult? Would something like Yubikey work if it had more adoption?

</comment><comment><USER104> Wow! What's the easiest way to stop this kind of attack? Stop all two-factor authentication?

</comment><comment><USER105> Does anyone know if Project Fi provides any extra layers of security? I haven't seen anything

<comment><USER106> If anything the ability to get texts via the web makes it worse.

<comment><USER107> How so?

By which I mean... I think that doesn't make any sense but please elaborate.

</comment></comment></comment><comment><USER108> With helpful picture of a "hacker" so you can recognize one.

</comment><comment><USER109> Or just ask them all to implement decentralized SecureLogin.

</comment><comment><USER110> "Locksmiths Are Breaking into Bank Safes"

</comment><comment><USER111> Old article ?

</comment><comment><USER111> isn't it old article ?

</comment><comment><USER112> Test

</comment><comment><USER113> This has been the vector for Twitter hacks for many years.

Get the 2nd factor

<comment><USER114> Get the 2nd factor... that's NOT sms.

<comment><USER115> SMS as a _second factor_ is fine. As bad as it is it can't reduce your security compared to just a password.

SMS as an account recovery mechanism is the problem.

</comment></comment></comment><comment><USER116> Two factor authentication is nothing more than a massive vulnerability. We've seen people somehow change our listed contact numbers through unknown exploits, then hijack ownership of properties using the new number to prove they are us. This wouldn't be possible if not for 2nd factor authorization schemes.

<comment><USER117> Only for 2-factor schemes that rely on your phone number. Those are horribly insecure, there's a reason NIST and pretty much all security experts recommend against using them.

SMS authentication was created as a cheap hack to get around needing SecurID tokens, and should have been abandoned when ToTP (Google Authenticator and the like) became possible.

<comment><USER118> SecurID tokens do ToTP just fine.

<comment><USER117> True, I mean the OATH standard / RFC 6238 style ToTP, which runs on generic hardware (a smartphone or PC).</comment></comment></comment></comment>


Why Python is Important for You - <AUTHOR> http://blaag.haard.se/Why-Python-is-important-for-you/ <comment><USER2> I like to call this cognitive compatibility - the amount of effort required from an uninitiated English-speaking observer to understand what a program does. Most people who are deeply familiar with a language will have a tendency to discount this effort, but really it is essential because it minimizes the translation layer that your brain has to use any time you read code.

Python encourages code which is readable in English and reasonably brief. Having readability, consistency, and the "principle of least surprise" as primary language and community principles ultimately saves developers time and makes them more efficient.

And the maturing of PyPy is incredibly exciting.

<comment><USER3> I want to make what I think is an important qualification which conflicts with a reading of your comment: Python is readable to people who are familiar with conventional Algol-based programming, i.e. every modern programmer. That does _not_ make it readable to an arbitrary English-speaker, which is an assertion I sometimes hear: "Oh, Python is so much like English, people who aren't even programmers can read some of it!" Which I can say from experience is not the case in the slightest. If it were, my job—which involves teaching Python to non-programmers—would be inestimably easier.

Python is simple and easy because it takes everything you know from other languages and systems and makes those things simple and easy and pleasant to do. I've even seen Python used as a kind of runnable pseudocode for projects that would eventually be written in other object-oriented Algol-based imperative languages, which is a testament to how well it distills those concepts down and makes programming simple. But it is not "readable in English." It is readable in pseudo-Algol.

<comment><USER4> Thankyou! So many programmers seem to forget they have an enormous base of syntax and logic which is not at all like natural language. They see python and say, oh wow this is so easy to read, just like English! But its only an easier way to express a syntax that really is nothing like what a nonprogrammer would consider English.

<comment><USER5> It varies.

When I was helping @limedaring learn Python, I'd read source with her and explain what it does. Quite often I'd feel somewhat embarrassed when explaining what a line does by verbatim reading what it says.

"for user in users: ..."

"if user.is_admin: ..."

It was especially nice that the topic of "what code block does this condition apply to?" did not even occur to either of us. The indentation-based blocks made it completely organic. (Try explaining Bash to someone and when to use do/done, if/else/fi, case/esac.)

But sure, things get weird with decorators and generators and other advanced features.

<comment><USER6> IMHO, decorators, although very useful are a _big_ departure away from python's "simplicity" in syntax. I remember having lots of headaches several years ago wile trying to fit it in my brain. Even after I realized it is something as simple as JavaScript's myfun(fun(){}), my brain somehow continued denying to absorb it.

<comment><USER7> Agreed that they can be tricky initially and hard to debug, but I think they're totally worth it for eliminating repetitive code. And IMO as long as there isn't a bug in the decorator itself, code with decorators can be just as readable (if not more so) to someone else (e.g. decorating your functions with @authenticated instead of if self.user.is_authenticated: # blah, blah blah)

<comment><USER8> if Python had better function syntax and anonynous functions, decorators wouldn't even be a 'thing'

<comment><USER9> > if Python had better function syntax and anonynous functions, decorators > wouldn't even be a 'thing'

Better function syntax? What's wrong with python's function syntax and how does it relate to decorators?

Python does have anonymous functions, though they are limited: You can have only 1 expression, you can't have statements, and you can't have local variables. The reasoning is lambdas should be used for small operations; for everything else, named functions should be used.

The reasoning behind lambdas is arguable, but it still doesn't explain how it affects decorators.

Consider:

        def memoize(fn):
            from functools import wraps
            @wraps(fn)
            def memoized_fn(*args):
                if not memoized_fn.cache.has_key(args):
                    memoized_fn.cache[args] = fn(*args)
                return memoized_fn.cache[args]
            memoized_fn.cache = {}
            return memoized_fn

        @memoize
        def fib(n):
            if n < 2: return n
            return fib(n-1) + fib(n-2)

        print fib(100)

What would a _better function syntax_ and _anonymous functions_ do so that _memoize decorator won't be a thing_?

<comment><USER10> Less restricted anonymous functions would allow stuff like this:

        fib=memoize(function...)

So the @ shortcut for:

        def fib():
            ...
        fib=memoize(fib)

wouldn't be necessary to 'clean up' the decoration of the function.

<comment><USER9> Even if it were possible, I would stick with

        @memoize
        def fib:
            pass

_fib = memoize(function ...)_ has unnecessary nesting, and _@memoize_ is cleaner IMO.

I am curious - do you find _@memoize_ confusing? Personally for me and anyone I have talked to, _@memoize_ is vanilla - the confusing part is the decorator itself, especially one that takes arguments; that coupled with the fact that classes(which override __call__) and functions are both used as decorators.

<comment><USER10> No, I don't find it confusing. But I read craigyk as mostly talking about the special decorator syntax, not function decoration in general.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly.

This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier, not to mention languages with real strong type systems like Haskell.

That's not to say that building large systems in Python is impossible, but it takes a lot more effort and documentation that it would in other languages.

<comment><USER12> This is a significant problem for me as well, coming from C++ and Haskell. Even just going through and making a few changes here and there, there's _no way_ for me to know without extensive testing whether my edit was even remotely correct beyond a cursory syntax check.

I've never had to deal with testing all that heavily in statically typed languages, because I can rely on the type system to do a lot of very helpful static analysis. The lack of basic static knowledge about a Python program is frustrating and discomfiting, and ultimately discourages me from using the language for anything serious.

<comment><USER13> I find the focus on dynamic typing a bit fascinating: you don't see people focus so much on it on a discussion about LISP. [EDIT: I meant to say that this most likely reveals something else is at work in the particular case of python].

When a C program compiles, it really does not tell you much about whether it will work or not. Maybe it is a matter of application domains, but I tend to actually spend more time testing C parts of the code compared to the python code. But, in proportion, I spend more time testing in python than in C, because I spend so much less time doing things in python than in C.

Haskell is different, because types can be used to enforced constraints in a much better fashion than C/C++/Java/etc…

The one part when simple typing systems is useful is refactoring. Doing so in a dynamically typed language is difficult (but possible, as shown by smalltalk, which is supposedly even more dynamic than python).

<comment><USER12> Lisp's other useful features just make the particulars of the type system less of an issue. When writing prototypes, I move things around and refactor a lot. Python makes this easy at the cost of certainty about whether it was done right. I don't write a lot of Lisp, but in my experience refactoring there is quite different: I'm not editing methods and classes, I'm factoring functions and macros. If I were one for supposing, I'd suppose the OO philosophy of Python forces you to create interfaces before you necessarily know that they're correct, so you end up refactoring them, and there's poor support for that when no static type system has your back.

<comment><USER13> This is already a more interesting discusion. I cannot comment on Lisp, as I have too little experience with it. When you say python forces you to create interfaces, I am not sure I understand. For me, programming is mostly about creating interfaces (as the interface part of API), python or not. When I refactor some C code, static typing does not help me that much, as what's difficult in C is lifetime's object (e.g. ref counting in C extensions), things like that.

What is true is that it is easy to write code that is impossible to refactor, because it is full of globals, or "stringified API" (e.g. using a dict instead of objects when the set of keys is supposed to be fixed). But I am afraid people writing this kind of code would write bad code in any language, or are at least very inexperienced in the language.

</comment></comment></comment></comment></comment><comment><USER14> I do love Python, but I often wish there was more rigor for some things. I currently work on a large project (>500K LOC) and have started to see it fall apart with a bigger team. Lack of enforced typing in function arguments, inability to create strict interfaces, inconsistency in standard library conventions, and package management would probably be my biggest gripes.

<comment><USER13> On most projects I have seen where python was seen as problematic, I think that having types ala C++/Java would not have improved much. The real problem is that the function is not documented, nor is the function expectations. Typing in C++/java does not replace that (more advanced typing systems do much better, though).

Package management and generally deployment is certainly a pain in python. I think it is one of the main issue in typical "corporate environments"

<comment><USER15> In most C++/Java code, the function is not documented either. The nice thing about manifest types is that the source code becomes the documentation (shitty documentation, yes, but usually good enough that you can figure out how to use it by looking at the source). Type inference with a doc generator would work too, as long as you run the doc generator regularly and everybody knows where to find the docs.

History has shown that programmers are too lazy/busy to write good documentation, and when they do, they don't keep it in sync with what the code does. If it's not checked by the compiler or automated tests, it's probably wrong.

<comment><USER13> It is not my experience that you can figure out how to call functions _correctly_ just from the function signature. Certainly, that's not true from C++ when you need to figure out lifetime issues, etc… It may be possible to figure out from the source code, if the code is written well enough, but that's true independently of the language IMO. Developer not writing decent doc is an institutional problem, and if this cannot be enforced, then the institution is most likely not capable of producing very good code either.

I think it is more interesting to talk from the POV of how to write code that is actually readable: type may help, but that's only a not that important part of the equation in my experience.

<comment><USER15> C++ with good coding conventions can encode pretty much all the information you need in the type. If a parameter is read-only, pass by const reference. If it's writable but ownership is not transferred, pass by pointer. If ownership is transferred, pass by unique_ptr. If it's owned within an object or function lifetime, use a scoped_ptr. If it can't be copied, inherit from boost::noncopyable.

</comment></comment></comment></comment></comment><comment><USER16> I have used Python for a rather long time (I think 1997 when I was 17 was when I first used it). As the the writer of the article stated Python is awesome for writing "tools" and throughout my career I have used it for such.

However I have used Python also for big projects and that is where its gets a little messy. I know I am going to get down-voted to kingdom come but I think Java is a better language for big projects mostly because of the static typing (try renaming a class in Python compared to Java).

Modern Java is for sure more verbose than Python and more complicated but the languages are extremely similar (Guido has even take some of the design consistency from Java for Python 3.0).

The reason I bring it up is Java is very often in various circles crapped on to no end. The reality its basically just more verbose Python. Not to mention Java offers an introduction to Parametric/algebraic typing (generics) and more sophisticated concurrency (futures ... yes actors are better but python really has neither).

<comment><USER17> Just replace Java with Haskell, and you've got yourself a nicer Python replacement.

Less code than either Java or Python, far more compile-time guarantees than either, and nearly as fast as Java when speed matters (speed takes a bit more effort in Haskell than in Java, but compared to Python, it is a no-brainer).

</comment></comment><comment><USER18> As a commenter on the article wrote: what about Ruby?

I say this as a happy Python user. Ruby seems very similar but I'm reminded of a pg essay on language power: looking _up_ the power curve, you see '$Language plus a bit of weird stuff that is probably irrelevant.' So I don't trust myself.

As someone who loves Python and doesn't know any Ruby beyond a few bits of syntax and the obvious bits that are common to most languages, what am I missing?

<comment><USER19> Ruby's blocks and built in regular-expressions are two examples of things you're missing.

if result =~ /regex/

that kind of thing is awesome for readability, but it can also be pretty darn slow.

There's also some interesting things about the ruby object model and interpreter that are different from python's approach. Whereas in the python REPL you type help(object) to get the docs on that object, in ruby you type object.methods or object.public_methods, etc. It's less documentation oriented, and more code-exploration oriented, but the two end up delivering the same sort of information.

Hope that's helpful! Ruby's a lot of fun to tool around with, and there are (in my opinion) fewer things about it to trip you up completely than there are when first learning python. But once you use it for a while and get beyond the basics, it becomes clear that there's a lot of unfocused cruft foating about, which fits no rhyme nor reason. Much more than Python has.

(cautionary note: I'm not an expert with either language)

<comment><USER20> ruby does have its share of cruft, but it also has some inspired features that make a far bigger difference than you'd think they would. blocks are the biggest (specifically, syntactic support for attaching a lexical closure to every method call, which the object can choose to use or not), but here's another cute one: the case statement

        case object
          when matcher1; ...
          when matcher2; ...
        end

performs a method call on the _matchers_ , with the object as an argument, rather than vice versa. so you can say things like

        case name
          when "John Smith"; puts "hello again"
          when / Smith$/; puts "are you related to john?"
        end

the string "John Smith" and the regexp / Smith$/ will each call a different matcher to see if they match your name - a far cleaner design than the string class having to provide matchers for everything you might want to use in a case statement.

</comment></comment></comment><comment><USER21> I am kinda afraid of getting down voted, but I have used Python and I feel like I get all this and more (CPAN) when using Perl. The major difference in my opinion is that Perl gives you even more freedoms, which causes you to need some self discipline, but you get stuff done even quicker that way.

It feels a bit like Python is better for programming beginners or people that tend to be too lazy sometimes and Perl is for people who want to be able to be lazier since they know what they are doing.

Also, I think Python (and most other language projects) should clone CPAN (including CPAN testers). Seriously it's a major deficit.

I also think Python is the easiest to grasp for people coming from static languages. Perl and Ruby are way harder.

<comment><USER22> Ok, just as a disclaimer: i recently read Larry Wall's post on perl design principles +natural language and am reconsidering perl.. But honestly all my previous experience poking around with perl have been horrible... it's pretty messed up syntax to read... i guess it may not be so hard for a perl expert..

<comment><USER23> Most Perl tutorials do a terrible job of explaining the two or three things you really need to understand to learn Perl syntax. I wrote Modern Perl to rectify that:

<http://onyxneon.com/books/modern_perl/>

</comment></comment></comment><comment><USER24> Python doesn't have the glyph noise that brace-based languages do, and well- written Python is beautiful and easy to read.

But lately I have been having an internal debate on whether using autodoc and inline docstrings detracts from its beauty and makes it harder to read because it reduces the amount of code you can see on the screen (see Steve Yegge's rant on this [http://steve-yegge.blogspot.com/2008/02/portrait- of-n00b.htm...](http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html) from a few years back).

If you use Sphinx to document a method's description, params, param types, and return type, then it can easily turn a three-line method into a 12 line method, and then you can only see ~5 methods on the screen at a time.

So if the code is already readable, would it not be better to put the docstring comments in an external file to keep the code density?

Django does this, and I'm starting to think it's the right balance.

<comment><USER25> Docstrings should already be easy to detect by editors, so it would be trivial to add a show/hide functionality. Incidentally, one could also use Sphinx to create a plugin for that.

<comment><USER24> But not all editors have this, nor is it widely used in editors like Emacs.

And GitHub doesn't have it so it can make it harder to get a big-picture view and see the structure of a module when evaluating different libraries online.

</comment></comment></comment><comment><USER26> I work with python daily. I find that when I first started I avoid a lot of the "fancy" constructs such as list comprehensions, dynamic arguments, and decorators as well as meta programming.

The great thing is the bar to being effective in the language is so low. You can pretty much pick up most python code and just read it and get a general feel for what it does. Not only that but it is much easier to read because of whitespace delimiting.

I can generally tell the quality of a python program but how nicely indented it is. If there are lots of indents like 5 or 6 levels deep I know something is wrong. For a newbie if your code is hard to understand and it is in Python you are writing it wrong.

<comment><USER27> I find a great way to avoid deep nesting is to move code to functions, and bail out when some conditions are not met.

As an example, this deeply nested code:

        def frob(someargs):
            if something > 2:
                ... # do some processing
                if that == "CONNECT":
                    ... # some more processing
                    if verdict in blessedsolutions:
                        ... # even more processing
                        print "Happy birthday!"

I tend to write like this:

        def frob(someargs):
            if something <= 2: return # Not our concern.
            ... # do some processing
            if that != "CONNECT": return # Not handled here.
            ... # some more processing
            if verdict not in blessedsolutions: return
            ... # even more processing
            print "Happy birthday!"

I do the same thing in loops, using 'continue'. The above second example looks rather flat, but in practice the 'do some processing' statements often need identations due to conditions and loops.

I added the processing to demonstrate that it's not always possible to combine conditions. And, of course this way of 'bailing out early' vs. 'nested ifs and processing' is not Python specific. The dogma that a function should have only one exit point (as proposed by 'structured programming' adepts and Pascal afficionados) often leads to deeply nested control structures and convoluted testing. Brian Kernighan has written a paper on this[1].

[1] [http://www.cs.virginia.edu/~cs655/readings/bwk-on- pascal.htm...](http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html)

<comment><USER28> Neither solution is great. Excessive use of return and continue is an incredibly fast way of making code completely incomprehensible.

Such complicated control flows should be treated as a major, fundamental problem. Keeping them in place will cause bugs and prevent future contributors from having confidence that their changes are correct. The problem of complicated control flow is too deep to be solved with a band-aid like this, although perhaps syntactically it looks a bit nicer. In fact, this is exactly what people did before the so-called "structured programming adepts" came around, except using gotos instead of continues. It didn't work so well back then, and it doesn't work so well now.

<comment><USER27> Hmmm, you have a point there, but what is your proposal to solve it in a correct way, then?

Some problems need a deeply nested control flow and arcane business rules, you have to implement that somehow, and in such a case the method I use looks like the lesser of two evils. I'd rather have some flat ecosystem of meaningful functions than one monolithic deeply nested control structure.

From time to time I like defensive programming, and when I write a function 'frob' that promises to frob something, that function first makes sure that the thing can indeed be 'frobbed', and if not, bails out. This also works well for programs that should be idempotent (although that is a whole other issue).

<comment><USER29> The way I would do it is to push the processing out to functions, too. Something like:

      verdict = get_verdict(the_thing)
      if verdict not in blessedsolutions:
          return

I'd advise against running returns onto the same line - I find it makes it harder to read, particularly when you have a lot of checks like this.

<comment><USER27> _"The way I would do it is to push the processing out to functions, too."_

This is indeed a good idea to isolate code away, but wouldn't alleviate a deeply nested control structure. It _would_ make it somewhat more easier to look at, though.

 _"I'd advise against running returns onto the same line "_

I usually follow PEP8 and place returns and continues on the next line, but the code examples I posted earlier had to be a bit condensed to conserve screen space, that's why ;-)

<comment><USER29> Sometimes your problem space is really just that complex, in which case there's not much you can do, short of writing some sort of business rules engine.

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> It's important because it reminds me I should keep looking.

I should keep looking instead of turning it into my Blub. I love Python but its boundaries have been hitting me frequently for years. There probably never will be a total sweet spot between functionality, syntax, compatibility, support, and platform-crossing but I know I have to keep looking for a language that's more sophisticated yet more practical.

</comment><comment><USER31> When I was at Google there was a paper titled "Please don't use Python for large programs." Can someone post that? It would be an interesting counterpoint.

<comment><USER32> What language do they recommend for large programs?

<comment><USER33> don't know for sure, it might be C++, Java, and now they have Go.

</comment></comment></comment><comment><USER34> I like Python the language, but the standard library can often annoy me as there is no unified style. thereAreMethodsLikeThis or_there_are_methods_like_this orevenworsefullylowercase. Gah.

<comment><USER35> PEP 8 covers this: <http://www.python.org/dev/peps/pep-0008/>

</comment></comment><comment><USER36> Many years ago I've decided it was time to pick up a modern programming language. In the past I had written lots of (Turbo) Pascal code, some x86 (and more exotic) Assembler and a bit of C, but then for several years I only did shell/awk scripts and ported C software to IRIX and SINIX/RU.

So I sat down and decided to find a nice general-purpose language that I would focus on learning. I wasn't quite sure what for yet, but I decided I was going to pick one and stick with it. I didn't have the time to learn multiple languages and I didn't have a lot of time to try out different ones, so I just looked around a little bit. Some I ruled out early: C and it's relatives were just too verbose, I didn't want to spend the time writing all the error handling necessary just to read a damn file. I was doing a lot of sysadmin type work at the time and had therefore developed an intense disliking for Java. This was based on too much badly packaged Java software that even if you got it running at all was sluggish, hogging way too much memory and crashed with arcane error messages. I did like the quick & dirty way I could make things work in a shell script, so I looked mostly at scripting languages.

I looked at Perl, which was the standard scripting language at the time and had a huge library (CPAN) of modules, which was great. I hated the syntax though and found the code often unreadable and there being too many ways of doing the same thing.

I looked at Pike, which had the benefit of using a C syntax (which I already knew, so that was a plus), but it seemed not widely supported and nobody was using it (this hasn't changed since, it seems).

I don't remember what else I looked at, but then there was Python. The syntax was a revelation. Here someone had finally made the most of creating a language from scratch and spent the time thinking about syntax and how to do away with largely pointless stuff (brackets), replacing it with things that everyone did anyways (indentation). It also came with a sizeable library of stuff that did almost everything I could dream of at the time. It was love at first sight.

Recently I've spent £35 on a stainless steel mill that grinds salt when you twist it one way and pepper when you twist it the other way, just because I really love well thought out and engineered things that make stuff that's been around forever just a little bit better. That's how I feel about Python. It's not doing anything fantastically new or unique, but it's doing the stuff that others do just a little bit better.

Today I'm doing lots of web stuff, some sysadmin stuff and random hacking of various things on the side. I'm still doing almost everything in Python and whenever Javascript bitches at me about a missed semicolon I do think: "All these fantastic things you can do in a web browser these days and you couldn't figure out that this command in an entirely different line isn't part of the previous line?".

The only thing that I can't do in Python is write software for my iPhone, which bugs me a bit. But every time I try to get into Objective C I just get annoyed by the syntax and amount of cruft I have to write to do anything.

<comment><USER25> _I'm still doing almost everything in Python and whenever Javascript bitches at me about a missed semicolon I do think: "All these fantastic things you can do in a web browser these days and you couldn't figure out that this command in an entirely different line isn't part of the previous line?"._

I hear you about Python, but JavaScript doesn't require semicolons either, as far as I know. The main reason it's advisable to put them is to avoid ambiguity when 2 statements find themselves on the same line, for example, in a minified js file. Python uses semicolons for the same reasons, but minifying Python files is quite uncommon (and would probably serve no real purpose).

<comment><USER37> JS semicolons are actually encouraged —omitting them, while syntactically valid, can lead to obscure bugs. [http://bonsaiden.github.com/JavaScript- Garden/#core.semicolo...](http://bonsaiden.github.com/JavaScript- Garden/#core.semicolon)

<comment><USER38> If you are following Crockford (JavaScript, the Good Parts), it is encouraged. However, some, like the current node.js maintainer think otherwise; see [http://blog.izs.me/post/2353458699/an-open-letter-to- javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript- leaders-regarding)

Personally, I still follow Crockford's advice though.

<comment><USER39> And you guys just demonstrated yet another reason why I choose Python for my go-to scripting language. Semicolons are completely redundant in Python and the language is so clean and the style guide PEP 8 is so natural, you rarely hear about these meaningless formatting style bickering in other languages. Saves so much time from arguing.

</comment></comment></comment></comment></comment><comment><USER17> "Weirder languages (e.g: Haskell)" sounds like something a Blub programmer would say.

How is Haskell "weird"?

I've used Python for many years, but only recently have I migrated my last Python niche (simple scripts) from Python to Haskell. I've found that even there, Haskell has become more productive.

<comment><USER40> > How is Haskell "weird"?

Functional the world (of wide-spread computing languages) is imperative, lazy the world is eager, objects-less when the world is object-oriented, curried when the world is uncurried, pattern-matched when the world is conditional and brings up "strange" concepts from mathematical bowels like "monads", "functors" or "zippers" when the world barely iterates on arrays.

How is Haskell _not_ weird from the point of view of 99% of the developers population? Knowing, liking or using Haskell is not even relevant there, Haskell _is_ weird because it _is_ an alien to the majority in the same way Smalltalk, Erlang or Clojure are weird (but for different reasons, for the most part).

<comment><USER17> I understand "different". Not "weird".

<comment><USER40> They reify to the same thing, something different looks weird, and something weird is different.

</comment></comment></comment></comment><comment><USER41> Python is great in every way except one -- it isn't Javascript.

(to clarify: I'm not saying JS is a superior language. I'm just saying it's going to win out in the end because of the history of its implementation. There is a serious benefit to having one language everywhere, and JS is the only viable candidate because of the investment in client-side sandboxing and performance -- two features which turn out to matter almost as much on the server as well.)

<comment><USER42> I wasn't aware that Python and JavaScript were in competition. Or for that matter, that JS is by any stretch of the imagination "invested in performance".

People don't use Python because of its merits as a programming language. They use it because of the excellent standard library, Scipy, Sage, etc. While it may be that in a decade JavaScript has built an ecosystem to match, I frankly don't see why anybody would bother. We already have Python, why would we invest such effort into a less suitable language?

JavaScript is tolerated by web developers, because they're forced to use it on the client, and so there's a benefit to also using it on the server to prevent duplication of effort. But there is absolutely no reason why non-web developers would or will ever use it outside of that niche.

<comment><USER41> > non-web developers

Sorry, not sure what that means </sarcasm>

OK maybe not _everything_ will be a web app, but pretty much everything that isn't some deep driver-level boot code or embedded firmware is already almost always part of some sort of web app, and the stuff that isn't is pretty much all written in C/C++.

When is the last time you wrote a Python program that didn't interact over TCP or equivalent with some other process? And how often was that other process _not_ something at least nominally webby?

<comment><USER42>
        > When is the last time you wrote a Python program that
        > didn't interact over TCP or equivalent with some other
        > process?

My last python program was a set of scripts to help me analyze music harmony. Entirely CLI based.

Before that? objcfix - a refactoring tool. Again, CLI based.

That's not counting the multitude of small scripts I write on a day to day basis. I've written a large amount of Python code, and very little of it interacts with a network.

Put it this way: Python was invented in 1991, the same time as the web. It didn't become a _good_ tool for making websites until after 2005 when Django arrived. So, what did people _do_ with it before then, if not make websites?

        > but pretty much everything that isn't some deep driver-
        > level boot code or embedded firmware is already almost
        > always part of some sort of web app, and the stuff that
        > isn't is pretty much all written in C/C++.

This is not the reality we live in. There's:

* Games (either written in C++, Objective-C or Java nowadays, plus a bit of Lua)

* Big Software: MS Office, Photoshop, Avid, Logic, InDesign, etc. Written in C++

* Scientific Computing: Written in C++, Matlab, Mathematica, Python

* Financial Computing: C, C++, Java, and a tiny spot of OCaml.

* iPhone/Android Apps: again, Objective-C or Java.

* "Enterprise Software", whatever _that_ is. Java.

And as you point out, embedded software. Everything around us runs Embedded C.

The future is the same as the present: full of a rich and diverse selection of languages.

</comment></comment></comment></comment><comment><USER43> Mostly true 'cept for pythons built in pasta makers:

<http://www.python.org/dev/peps/pep-0318/>

<comment><USER27> Yeah, that's fun ;-) I wish there was a

        if main:
            ... # do some processing

instead of having to write:

        if __name__ == "__main__":
            ... # do some processing

That'd make DHH happy, too ;-)

<comment><USER29> I find that the best way to fix this is to write your program as a library, then the part that you're supposed to run as a script which imports and runs it. No __underscore__magic__ required.

</comment></comment></comment><comment><USER44> I could not agree more. After learning the python idioms, I realized how much time I have wasted doing similar things in PHP. Python has gotten lot of things right. I don't feel cramped by a language as I have with Java.

Python idioms : [http://python.net/~goodger/projects/pycon/2007/idiomatic/han...](http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html)

</comment><comment><USER45> True. The real magic: The basic constructs are so simple, so how the output is so robust? And picking old or library code is always easy!

</comment><comment><USER46> Executable whiteboard.

</comment><comment><USER47> I have a list I wrote up once about Python's problems. Some of these are more exotic than others. Most of them are kludgearoundable. A couple are fixed in Python 3. Some are simply design choices that are exactly different from my mental model of the world, and due to the TOOWTDI Python world, it is frustrating to work with them.

Some Things Wrong With Python

* Immutable strings[0]

* Everything a reference[1]

* Environment copied on loop entrance (implying assignments often break when done in loops)

* Lack of braces[2]

* Lack of enums[3]

* Standard debugger pdb reminds me of the first debuggers ( used on the PDP-1 and EDSAC) in its feature list.

* Exception-oriented design, which clutters code with "try/catches" everywhere.

* Exceptions aren't just exceptions, they are also overloaded to provide signals.

* Two forms of objects (old style vs. new-style)

* Object inheritance is pointer to parent. Metaprogramming becomes an exercise in hackery.

* Objects are actually dictionaries with some pointers behind the scenes.

* Duck typing will automagically cast certain things[4]

* As an interpreted language, code that is not tested can be assumed to be syntactically correct but in error (this is a horrible problem when testing for rare error conditions)[4.5]

* When Python is fast, it's because it's calling out to C.

* Python objects are gigantic. An empty string is 40 bytes, for example. This adds up.

* Python can not meaningfully multithread, due to the global interpreter lock.

* Python suffers from many different versions being installed on different versions of Linux[5]

* Lambdas are totally broken[6]

* Large-scale module importing is a half-baked job[7]

* Python 3 routes around some these issues by using generators for everything[8].

[0] Ever try to step through a string and modify it in-memory? Well, you can't. Sorry. ;-)

[1] I.e., a function can modify something unexpectedly.

[2] Which means block commenting or commenting out tops of loops means a complete reindenting of the block, that is, editors can't do the smart thing, they don't have enough context. This is a waste of the engineer's time. Delimiters were figured out in Lisp, a very long time ago.

[3] This was figured out long ago as well.

[4] But not others. Object design is a bit funky.

[4.5] This is a general design 'con' in dynamic languages. It's partially solvable with a sufficiently smart compiler, most compilers aren't that smart.

[5] This is why serious Python programs (that don't come bundled with their own version of Python) are written to target Python 2.4, released in 2004.

[6] A 'lambda' function in Python can not have statements. Most interesting functions have statements.

[7] Python (similar to Java) relies on a very specific directory structure for a given program to be able to import libraries. This means that if you are doing anything remotely exotic with layouts (e.g., libraries are in a peer directory, not a child directory), you have to commit hackery.

[8]This avoids the fact that the end result has to be emitted in some fashion.

<comment><USER48> You forgot _mutable_ default arguments!

        def fn(ls=[]):
          ls += [1]
          return len(ls)

(My syntax might be a little off, but you get the idea.)

This will return an ever-increasing number if called repeatedly with no arguments.

Also, the reliance on tuples, particularly tuples of _one_ item always gets me because (1) and (1,) are different.

Also, the scoping for list comprehensions doesn't make sense:

        x = 11
        [x for x in [1,2,3]]
        print x # 3!

This has also gotten me in the past.

<comment><USER49> Just for the record list comp scoping is fixed in python 3:

        $ python3
        Python 3.2.1 (default, Aug  1 2011, 14:47:14)
        [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
        Type "help", "copyright", "credits" or "license" for more information.
        >>> x = 11
        >>> [x for x in [1,2,3]]
        [1, 2, 3]
        >>> x
        11

</comment></comment></comment><comment><USER14> See also: <http://xkcd.com/353/>

</comment><comment><USER50> Haskell is not weird.</comment>