Slashdot Mirror

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.

United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:

• your e-mail address
• your street address
• your phone number
• your PIN
• your password
• your "old MileagePlus number"

And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.

This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.

I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)

So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.

I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.

It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).

The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.

As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.

I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.

So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.

I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.

And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.