Why is Apple's online account security so poor?

[munkery]

The attacker would need the valid password and a valid one-time code to log in. Simply brute forcing one code is not enough. See: http://www.google.com/support/accounts/bin/answer.py?answer=1187538

In relation to Google's implementation of 2-step authentication, this is absolutely untrue.

You only need an application specific password to log in with many clients.

The application specific passwords provided by Google are weaker than a secure password generated by the user.

First of all, the application specific password is quite long, but only consists of lowercase letters - and always has the same length - making them generally easier to guess in a brute-force attack than a user-password.

http://www.ilikealot.com/i/experience_from_using_2-step_verification_with_my_google_account

Also, despite Google making it appear that these application specific passwords can't be re-used, these passwords can be used across many client applications.

Then, these passwords aren't that specific to one application as one might wish for.

http://www.ilikealot.com/i/experience_from_using_2-step_verification_with_my_google_account

So, using Google's 2-step authentication is less secure than using a single secure password if the user accesses the Google account via non-browser client software.

Here is another link to information about this security vulnerability: http://www.google.com/support/forum/p/Google+Mobile/thread?tid=469b8ac44c5fd3d7&hl=en

You keep slamming a system that clearly you have never used or under stand. You are spreading FUD.

I'm not slamming 2-step authentication as a whole.

I'm pointing out issues with Google's implementation of 2-step authentication.

Well first off the 1 time use verification codes are longer than 6 digits (they are 8)

The one-time codes are typically only 6 digits. The backup codes are 8 digits.

The one-time codes are not relevant given that an attacker can brute force the backup codes.

It only takes a few minutes to brute force a code made up of 8 numbers. This time is shortened due to 10 backup codes being available to compromise.

Also, see my reply to "neiltc13" above for information about another major weakness in Google's 2-step authentication.

Also I point back to it is 2 step. It requires you knowing someones password which should be secure any how.

That is exactly my point. A secure password is still the most important security mitigation.

And, the codes and application specific passwords provided by Google don't meet the minimum standard of being a secure password.

Also brute forcing the 2 step is rather hard in time because google does slow it down after a few fail attempts. Brute force kind of sucks when you can not do slam it 100's a second.

Link to source stating that Google limit attempts when brute forcing both the backup codes and application specific passwords?

More FUD. At this point this is pure FUD.

Explicitly explain how the quote below is FUD.

Sure, if you know someone is accessing the device.

But someone trying to compromise your account locally does not necessarily involve your device being stolen; someone can access your device without stealing it.

And, allowing the extra authentication to be suspended negates the purpose of it in the first place.

So, that machine is functioning like it only has a single password. Which means that this is no more secure than having only a single password. Which means that it is still important to make sure to use a secure password.

You clearly have done zero research in to it and on top of that you clearly have zero understanding of how it works.

Are you sure?

 

[Rodimus Prime]

In relation to Google's implementation of 2-step authentication, this is absolutely untrue.

You only need an application specific password to log in with many clients.

The application specific passwords provided by Google are weaker than a secure password generated by the user.

what do you define as a secure password? Also make sure it is one that a human could easily remember threw some type of system.

http://www.ilikealot.com/i/experience_from_using_2-step_verification_with_my_google_account

Also, despite Google making it appear that these application specific passwords can't be re-used, these passwords can be used across many client applications.

While true it is still a 16 char long password. Not exactly easy to crack. Even at 26 possibly and known 16 chars long it is still a long ways to go. You do not exactly eliminated that many possible passwords by blocking out the first 15 spots.
http://www.ilikealot.com/i/experience_from_using_2-step_verification_with_my_google_account

So, using Google's 2-step authentication is less secure than using a single secure password if the user accesses the Google account via non-browser client software.

Here is another link to information about this security vulnerability: http://www.google.com/support/forum/p/Google+Mobile/thread?tid=469b8ac44c5fd3d7&hl=en

Goes back to what you define as secure.

I'm not slamming 2-step authentication as a whole.

I'm pointing out issues with Google's implementation of 2-step authentication.

The one-time codes are typically only 6 digits. The backup codes are 8 digits.

The one-time codes are not relevant given that an attacker can brute force the backup codes.

It only takes a few minutes to brute force a code made up of 8 numbers. This time is shortened due to 10 backup codes being available to compromise.

which as pointed out before would require both your password and that 8 number long code.

Even brute forcing for that 8 number code your password should be harder to crack defeating the purpose. Also after a small handful of failed attempts google kicks in there systems that slows you down big time and computers can not brute for with the Captcha system and that pretty much hammers a brute force system.

Either way what do you define as a secure password.

 

[munkery]

what do you define as a secure password? Also make sure it is one that a human could easily remember threw some type of system.

Secure passwords contain at least 8 characters with at least one character from each of the following: upper case alphabet, lower case alphabet, numbers, and symbols.

Go@wow76 is an example of a password that meets the minimum requirement of a secure password.

Keychain Access, the default password management system within OS X, provides an easy method to keep track of all your passwords.

While true it is still a 16 char long password. Not exactly easy to crack.

Edit: Upon checking, a 16 character long password of only lower case alphabet also takes unfeasibly long to crack.

6 digit codes take 1-2 minutes at a slow attempt interval.

8 digit codes take 2-3 hours at a slow attempt interval.

http://www.lockdown.co.uk/?pg=combi

Attempting to do this on a remote account would take even longer than the slowest attempt interval described in the link above.

which as pointed out before would require both your password and that 8 number long code.

Unless the attacker decides to brute force an application specific password. Only an application specific password is required to access the account using non-browser client software.

So, using Google's 2-step authentication is less secure than using a single secure password if the user accesses the Google account via non-browser client software.

Even brute forcing for that 8 number code your password should be harder to crack defeating the purpose.

Exactly, a secure password negates the purpose of using Google's 2-step authentication given the issues with Google's implementation of this type of authentication.

Also after a small handful of failed attempts google kicks in there systems that slows you down big time and computers can not brute for with the Captcha system and that pretty much hammers a brute force system.

That sounds like it only works for manual browser based login attempts.

Also, link to support this claim?

Does Google do this for logins performed from non-browser client software?

Apparently, it is fairly easy to use a CLI based email client, such as Mutt, that supports macros in combination with AppleScript/Automator to generate a system to automate brute forcing email accounts.

Given the available knowledge of the application specific passwords (16 characters long, only lower case alphabet, & re-usable), these passwords are much easier to brute force than a secure user generated password.

If a user opts to use Google's 2-step authentication, then the user has to use one of these weaker application specific passwords to access the account with non-browser client software.

 

[Rodimus Prime]

​

Keychain Access, the default password management system within OS X, provides an easy method to keep track of all your passwords.



A password with a known format that is 16 characters long and made up of only lower case alphabet is far easier to brute force than a password that fits the requirements of a secure password defined above.

A secure user generated password has an unknown length and uses an unknown variation of characters from the perspective of the attacker.

The Google provided passwords have a known length and set of included character types.

Well now that you gave me a base line it is time to show you how oh so wrong you are.

Taking you example there are 84 possible chars for each spot (52 letters, 10 numbers, 10 chars above the number and 11 over chars) you have to remember several chars can no be used in a password and in those 84 I was giving some extra. Chances are it would be limited to maybe 73 in most cases which would push the need number to match google even higher than the 12 already.

now there are 26 for each of googles possible 16 spots.

now for your password to be better than a google pass word it requires a min of 12 chars long.

For googles 16 chars there are
43,608,742,899,428,874,059,776 possible passwords That is knowing that it is 16 chars long and all lower case.

Mix that with server time at a max of 100 try per sec brute force it would take on average 6,971,420,173,967.42 YEARS to brute force a Google random password. So even if you had 20 possible random ones that is not going to bring down the number that much at all and really pretty limited effect.

It is simple math.

To figured out the average time it is take that big long number of possible passwords and divided by 2. That gives you the average case for brute force.

So really you might want to do a some math fact checking before try call it insecure.

Reason for the limitation of a 100 trys per second is that is being nice in the max number of server pings Google would allow you to hit it for. Just raw brute force hacking with out that limitation you are still talking years for a brute force hack job as you are maxing out your CPU speeds here.


Really do some basic math checking here.

Either way your secure password at min which is 8 chars long

2,478,758,911,082,496<43,608,742,899,428,874,059,776

Thank you for spreading FUD and getting owned by basic math skills.

Exactly, a secure password negates the purpose of using Google's 2-step authentication given the issues with Google's implementation of this type of authentication.

Does not negate it. Passwords can and often are stolen. Lets assume someone got a keylogger when you entered it once. They got the password but that password is only semi useful to hack in as you can not brute force it due to the limitation of the Google server side.

Passwords can be stolen. The 2 step is a little harder to do. This is one more step to protect your stuff.

I already showed to you that the google random password beats out your secure one. Using Mac keychain is not exactly valid argument for remembering as you can not log in from elsewhere if need be.

I know how to remember long passwords that hard hard to hack. There are tricks and up to 10 chars it is fairly easy to make it look random to everyone but say you.

 

[munkery]

Well now that you gave me a base line it is time to show you how oh so wrong you are...

For googles 16 chars there are
43,608,742,899,428,874,059,776 possible passwords That is knowing that it is 16 chars long and all lower case.

It is simple math.

Your math is wrong.

You forgot to remove all the derivatives that don't include 16 characters.

Albiet, it doesn't make much difference.

Both the application specific passwords and secure passwords take unfeasibly long to crack.

The numerical codes from Google are much more likely to be brute forced. See the edit in my previous post.

Either way your secure password at min which is 8 chars long

2,478,758,911,082,496<43,608,742,899,428,874,059,776

The number of possibilities goes up much faster if you follow the format of a secure password. A secure password quickly surpasses the number of possibilities of an only lower case alphabet password even when the secure password has much fewer characters.

EDIT: removed due to inverting numbers in an equation leading to an incorrect answer. The size of the value also altered the formatting of my post. See the next post in this thread for clarification.

Thank you for spreading FUD and getting owned by basic math skills.

It appears that you have a limited understanding of derivatives. See above.

Does not negate it. Passwords can and often are stolen. Lets assume someone got a keylogger when you entered it once. They got the password but that password is only semi useful to hack in as you can not brute force it due to the limitation of the Google server side.

If malware is on the system, then the attacker can capture the application specific password as well. There are no limitations to using these passwords because they can be re-used.

Most users access their email account via email client apps.

I already showed to you that the google random password beats out your secure one. Using Mac keychain is not exactly valid argument for remembering as you can not log in from elsewhere if need be.

So, you can remember 16 character passwords easier than 8 character passwords?

You still have to use a secure password anyway.

 

[Rodimus Prime]

Your math is wrong.

You forgot to remove all the derivatives that don't include 16 characters.

Albiet, it doesn't make much difference.

Both the application specific passwords and secure passwords take unfeasibly long to crack.

The numerical codes from Google are much more likely to be brute forced. See the edit in my previous post.

but I am not wrong. 26 spots, 26 possibility per spot.. If in theory it could have blanks (aka spaces) around 27 possibility per spot.

In lets say you have to have between a 5 and 8 digit number password. For the first have it would be 10*10*10*10*10*11*11*11. Notice the 3 11's. That accounts for the 3 blanks that could be there. Now the final answer would be a little less than that but I am way to lazy to go in and figure that out. So woo the FUD guy is wrong again.

possibility
The number of possibilities goes up much faster if you follow the format of a secure password. A secure password quickly surpasses the number of possibilities of an only lower case alphabet password even when the secure password has much fewer characters.

For example, add another character (so, 9 characters) to a secure password as I have defined.

40483766022843281411184472189571654752207506882090305742200116101065766026718820758174775041 > 43,608,742,899,428,874,059,776

Sorry your math is wrong. AT 9 chars it is 84^9. That is only 20,821,574,853,0929,664 which is still less than 43,608,742,899,428,874,059,776

As I pointed out you have to cross 12 chars in your format before you cross the max number for googles 16 random one.

Do some basic math. It is not that hard. I think you are feeling how to calculated max possible passwords.

If malware is on the system, then the attacker can capture the application specific password as well. There are no limitations to using these passwords because they can be re-used.

Most users access their email account via email client apps.



So, you can remember 16 character passwords easier than 8 character passwords?

You still have to use a secure password anyway.

And difference is the password can be revoke as soon as it is caught.
You still have nothing of an understanding and you have failed to understand it.

Either way I have been showing time and time again that you are not getting it.

You are spreading fud and I looked at most of the links you put in and many of them are full of FUD or miss understanding.

 

[munkery]

but I am not wrong. . .

Your calculation should look like this:

26^16 - 26^15 - 26^14 - 26^13 - 26^12 - 26^11 - 26^10 - 26^9 - 26^8 - 26^7 - 26^6 - 26^5 -26^4 - 26^3 - 26^2 - 26^1 =

This eliminates all the derivatives that don't have 16 characters given that the password is known to be 16 characters in length.

Also, the passwords and codes don't include spaces when entered into client applications.

Whoops: Haha, half asleep. No need to resort to a derivative method if use the equation 26^16 to find the number of possibilities.

I was thinking that the starting value was calculated to find the total number of possible combinations up to 16 characters with an unknown number of characters in the password.

Derivative calculations are used to find the number of possibilities in relation to passwords of an unknown length.

Sorry your math is wrong. AT 9 chars it is 84^9. That is only 20,821,574,853,0929,664 which is still less than 43,608,742,899,428,874,059,776

Whoops, my math is wrong (tired = inverted the values in the equation).

But, your correction is wrong as well.

96 characters are available for use if you follow secure password guidelines.

96^12 = (gives a larger value) 612,709,757,329,767,363,772,416 > 43,608,742,899,428,874,059,776.

96^11 = (gives a smaller but more closely equivalent value) 6,382,393,305,518,410,039,296

The number of possibilities goes up much faster if you follow the format of a secure password. A secure password quickly surpasses the number of possibilities of an only lower case alphabet password even when the secure password has much fewer characters.

And difference is the password can be revoke as soon as it is caught.

This is true of any password so it makes no difference.

You are spreading fud and I looked at most of the links you put in and many of them are full of FUD or miss understanding.

How is the example below FUD?

A single 8-digit (meaning only numbers) code takes up to 12 days to brute force at 100 attempts per second.

Factor in that 10 backup codes are available to compromise. So, the time required to brute force passed Google's 2-step authentication is reduced drastically.

It basically makes no real difference in terms of security than a secure password alone given that brute forcing passed the 2-step authentication is trivial.

 

[munkery]

The following is a summary of the content of this thread:

Windows + keylogger to get secure password + brute forcing a backup code if 2-step authentication is used = Gmail compromised. Then reset passwords for security sensitive logins, such as online banking, that are resettable from the Gmail account.

Mac + secure password = Gmail not compromised. Why? No keyloggers in malware in the wild targeting Mac OS X.

 

[neko girl]

To me, Google seems to be leading the way in this area. Earlier in the year it launched a quite fantastic two step authentication system that ensures that even if a hacker knows a user's password, they won't be able to log in to their account.

I agree that this could be a good, secure feature to add to account password, but to be honest the way Google keeps asking for my cell just about every time I login seems like they're farming for phone numbers rather than purely providing a security service.

I don't want Google to have my cell, which means my level of security is about as good as Apple offers.

You might consider the additional security a bonus, but some (many?) of us think a lot about privacy, too.

Also, 1Password is a better alternative to Google cell phone number farming.

 

[Rodimus Prime]

The following is a summary of the content of this thread:

Windows + keylogger to get secure password + brute forcing a backup code if 2-step authentication is used = Gmail compromised. Then reset passwords for security sensitive logins, such as online banking, that are resettable from the Gmail account.

Mac + secure password = Gmail not compromised. Why? No keyloggers in malware in the wild targeting Mac OS X.

Miss you can not brute force the 8 number. After the third failed attempt the captcha kicks in dropping the attempt to once every few seconds at best and requires human input. Top that off you have to deal with much much higher lag time.
You pretty much spread fud.
Also for your system to work it would me you would never check you email from anything but your computer. You would not use any device but your computer to check it.

End of the day you are spending fud and showing some google hate.

 

[miles01110]

Also, 1Password is a better alternative to Google cell phone number farming.

Right, because having all of your passwords in one place automatically means it's better than 2-factor authentication.

 

[neko girl]

Right, because having all of your passwords in one place automatically means it's better than 2-factor authentication.

Maybe you don't understand what a Mac OS account password or FileVault is.

 

[Rodimus Prime]

I agree that this could be a good, secure feature to add to account password, but to be honest the way Google keeps asking for my cell just about every time I login seems like they're farming for phone numbers rather than purely providing a security service.

I don't want Google to have my cell, which means my level of security is about as good as Apple offers.

You might consider the additional security a bonus, but some (many?) of us think a lot about privacy, too.

Also, 1Password is a better alternative to Google cell phone number farming.

I handed over my cell number a long time ago for the Google Voice service.

Besides Google Voice being a great VVM service on Android and in some ways the best VVM system out there it has one feature way to many people over look.That is I do not give out my cell number to business at all. I will hand them my GV number because I can turn around and screen that system. Big time if it is an annoying business. I have had some numbers that call that do not even go to voice mail. The number is just well blocked. It is great and a much nicer screening system.

The GV number does not even have to forward to your cell phone or any other number. Everything could be kicked to voice mail and you could still use it as a voice mail system for your phone.

Google more asking for the number for password recovering system.

Maybe you don't understand what a Mac OS account password or FileVault is.

and you do not see the problem in you having all your passwords in one location.
It is not exactly that hard to write a keylogger. I could wipe one up in 10-15 mins in java. It is not exactly that many lines of code to grab and store every keystroke on your computer.

The tricky part is getting it to loaded in with something and getting the trogan loaded in. OSX has the same huge security hole every OS has and it is impossible to remove which is the user. No way around that fact. Having everything in one location is not smart. A better idea would be to store none of your passwords on the computer or in FileVault.

Google 2 step is a hell of a lot better than that huge whole in your argument.
You are an example of a problem with many users and that is they think OSX is immuned to malware. Truth be told it is not immuened to it. Mac Defender is great proof of that. It was really good at getting loaded into the computer and lasted for a while. It was not the first and sure as hell will not be the last. The best defense is being smart user. Sadly way to many OSX users have it in there head that OSX can not get malware.

 

[neko girl]

I handed over my cell number a long time ago for the Google Voice service.

I think GV integration with US numbers is what you're talking about. GV doesn't make a lot of sense here, since we all have +86, not +1 numbers - wouldn't help me with calls or texts. Granted, I could get GV for texting (like for 2-factor confirmation) but last I checked I have to put in my cell phone number to get a Google Voice number.

Edit: Regarding a keylogger, I'd be interested to know how you'd get it running on my system. Also, the Google two-step isn't a "hell of a lot better" because my requirement is not to surrender my cell number to Google (as I mentioned). I think there are different priorities here.

 

[Rodimus Prime]

I think GV integration with US numbers is what you're talking about. GV doesn't make a lot of sense here, since we all have +86, not +1 numbers - wouldn't help me with calls or texts. Granted, I could get GV for texting (like for 2-factor confirmation) but last I checked I have to put in my cell phone number to get a Google Voice number.

You do but that is not the point I was making. More I and many other handed over their cell numbers a long time ago for Google voice. GV bring a entirely new level of privacy in terms of cell numbers. But then again I do live in the US.
And as I said before GV gives me a entirely new level of privacy with my phone number.

Not that the phone number is much use to Google. Does not give out my locations (area code is different) and they do not collect anything more than when I get voice mails.

That being said the new level of privacy I gain from being able to kill calls from people/company I do not want to deal with is really nice.

Lastly I trust Google a hell of a lot more than I trust Apple. Apple has shown to time and time again how greedy it is and I would not put it past them to sell more private data that Google ever would for a quick buck. Apple is not a company I would trust at all.

 

[munkery]

Miss you can not brute force the 8 number. After the third failed attempt the captcha kicks in dropping the attempt to once every few seconds at best and requires human input. Top that off you have to deal with much much higher lag time.
You pretty much spread fud.

Are you sure?

Does the captcha initiate for browsers based logins and/or email client based logins?

I believe the captcha only appears for failed password login attempts.

Does the 2-step authentication screen use a captcha after failed attempts as well?

If the attacker has the password from a Windows machine via a keylogger and the 2-step authentication doesn't use a captcha, then this is irrelevant.

Also, there are Gmail cracking tools built from Google APIs that don't seem to be limited by the captcha. Haven't tried any of them myself.

https://duckduckgo.com/?q=gmail+brute+force -> some are found via this search.

The captcha also provides the same protection to a secure password so any argument you make that relies on the captcha to support 2-step authentication also applies equally to only using a single secure password.

Using this 2-step authentication doesn't meaningfully improve security over using only a single secure password. This is exactly the point I'm trying to make.

Also for your system to work it would me you would never check you email from anything but your computer. You would not use any device but your computer to check it.

I only use my personal computers and devices to check my security sensitive accounts because public machines should never be trusted.

Do you want to give an attacker an opportunity to get your secure password via a compromised public machine just because you feel safe because of Google's 2-step authentication?

End of the day you are spending fud and showing some google hate.

I don't hate google.

Honestly, another point that I'm trying to make is that the premise of this whole thread is FUD.

This is especially true in relation to Mac OS X if a secure password is used given that no malware keyloggers are present in the wild targeting OS X.

 

[neko girl]

Lastly I trust Google a hell of a lot more than I trust Apple.

From: http://www.google.com/intl/en/privacy/privacy-policy.html

When you send and receive SMS messages to or from one of our services that provides SMS functionality, we may collect and maintain information associated with those messages, such as the phone number, the wireless carrier associated with the phone number, the content of the message, and the date and time of the transaction.

However, from here: http://mail.google.com/support/bin/answer.py?answer=114129

We will never share your number or use it to send you unwanted messages. We promise.

So good is the "promise" that it is not mentioned/iterated in any way in their official privacy policy.

I understand that Google has 3 uses for this information:

• Share with affliates for money
• Use to process for serving their own ads, like in Google Voice or Gmail
• Adding to speech recognition database

From iTunes's terms and conditions: http://www.apple.com/legal/itunes/us/terms.html

• The personal information we collect allows us to keep you posted on Apple’s latest product announcements, software updates, and upcoming events. It also helps us to improve our services, content, and advertising.
• We also use personal information to help us develop, deliver, and improve our products, services, content, and advertising.
• From time to time, we may use your personal information to send important notices, such as communications about purchases and changes to our terms, conditions, and policies. Because this information is important to your interaction with Apple, you may not opt out of receiving these communications.
• We may also use personal information for internal purposes such as auditing, data analysis, and research to improve Apple’s products, services, and customer communications.

I've only ever received e-mails from Apple, no SMS or phone. Apple doesn't have any corporate or profit reason to share cell phone information. If you think otherwise, can you list out what they are, specifically?

 

[Rodimus Prime]

Your calculation should look like this:

26^16 - 26^15 - 26^14 - 26^13 - 26^12 - 26^11 - 26^10 - 26^9 - 26^8 - 26^7 - 26^6 - 26^5 -26^4 - 26^3 - 26^2 - 26^1 =

This eliminates all the derivatives that don't have 16 characters given that the password is known to be 16 characters in length.

I am going to be blunt here but just going to point out you are wrong. Oh so very wrong on that.

If you wanted to include blank spaces the correct way to figure it out would be 26^16+26^15.....

If you want some simple proof of this then let look at 00-99. There are a 100 numbers in there.
Now if you want to include being able to use a blank so you could do 0-99 then you would have a 110 numbers because of the extra 10 in the 0-9 and then you got 00-99.

Adding blanks in there all the way down to having a min char length of 1 max increase in total possiblity
would be 11.1111111...% and that is with 10 digits. The greater the number possible chars the less that gain is. It would be for 26 it would (1/26+1/26^2+....1/26^x)*100=percentage increase where x is (Password length-1)

From:
I understand that Google has 3 uses for this information:

• Share with affliates for money
• Use to process for serving their own ads, like in Google Voice or Gmail
• Adding to speech recognition database

From iTunes's terms and conditions: http://www.apple.com/legal/itunes/us/terms.html

I've only ever received e-mails from Apple, no SMS or phone. Apple doesn't have any corporate or profit reason to share cell phone information. If you think otherwise, can you list out what they are, specifically?

Just going to point out to you that minus improving speech recognition database Apple has the same use for the information.

You need to remember Apple is in the advertising game now as well. If Apple was not in that department I would be more inclined to agree with you but they are not in there yet.

 

[munkery]

I am going to be blunt here but just going to point out you are wrong. Oh so very wrong on that.

If you wanted to include blank spaces the correct way to figure it out would be 26^16+26^15.....

If you want some simple proof of this then let look at 00-99. There are a 100 numbers in there.
Now if you want to include being able to use a blank so you could do 0-99 then you would have a 110 numbers because of the extra 10 in the 0-9 and then you got 00-99.

Adding blanks in there all the way down to having a min char length of 1 max increase in total possiblity
would be 11.1111111...% and that is with 10 digits. The greater the number possible chars the less that gain is. It would be for 26 it would (1/26+1/26^2+....1/26^x)*100=percentage increase where x is (Password length-1)

I pointed out my own error yesterday. See the following quote in the post to which you are replying.

Whoops: Haha, half asleep. No need to resort to a derivative method if use the equation 26^16 to find the number of possibilities.

I was thinking that the starting value was calculated to find the total number of possible combinations up to 16 characters with an unknown number of characters in the password.

Derivative calculations are used to find the number of possibilities in relation to passwords of an unknown length.

This has nothing to do with blank spaces given that the passwords and codes don't include blank spaces when entered during authentication.

The formula I provided shows how to remove all possibilities that are not 16 characters in length if the value that is provided includes all possibilities with an unknown length up to 16 characters in length while only using the lower case alphabet.

But, my retraction posted yesterday also includes an error. I referred to the method used as derivative when it is actually a permutation.

Now, to get this thread back on track, the following is why Google's 2-step authentication doesn't provide any meaningful benefit over only using a secure password:

1) email clients still have to use a single password referred to as an application specific password. User generated secure passwords are also unfeasible to brute force and user generated secure passwords become harder to brute force with fewer characters than the application specific passwords provided by Google.

2) there is a potential for the 10 backup codes to be brute forced if the user password is known given that Google's captcha has been defeated in the past and Gmail brute forcers that are unaffected by the captcha are sometimes available. So, the user generated secure password is the only functional protection when methods exist to bypass the captcha.

3) the captcha also provides the equivalent amount of protection from brute forcing to user generated secure passwords and Google's 2-step authentication.

It should be noted that the initiation of captcha for failed login attempts is much less restrictive on email clients in comparison to browsers. Email client logins are more likely to be the target of brute force attacks. Email clients used in conjunction with Google's 2-step authentication still use only a single password. So, Google's 2-step authentication makes no difference in this regard.

For those that want to test their own password against a brute force attack, the following is a good guide.

http://edwincastillo.com/archives/111

 

[Ptit]

does not matter what method apple uses to secure all your personal or professional data, nothing on the internet is safe from publicly been exploited, one would be called naive in court to think apple can provide better security then the Feds who already got hacked by 10 year olds, wikileaks, etc etc

 

[munkery]

does not matter what method apple uses to secure all your personal or professional data, nothing on the internet is safe from publicly been exploited, one would be called naive in court to think apple can provide better security then the Feds who already got hacked by 10 year olds, wikileaks, etc etc

The Feds?

You mean HBGary?

HBGary had an exposed web app (CMS) with known vulnerabilities (rudimentary SQL injection), weak password hashing (unsalted MD5), and many users had weak passwords for externally facing logins.

It is very easy to do better than HBGary.

 

[yg17]

Oh my god there's so much FUD in here.

For one to brute force a Google account with 2 step authentication, they have to brute force your regular password (and using 2SA is not an excuse to use a crappy password like your dog's name, you should still be using a good, strong password as your main password) but then they have to brute force the temporary code. Oh, then after a few failed login attempts, CAPTCHA kicks in, and I bet after a few more failed attempts some other sort of security kicks in. We're talking about a one in a billion chance.

The phone app to generate a code works much like the RSA tokens I use here at my job to log in to certain systems. The way I understand it, it's based off the clock and a random seed. Both the server and token are seeded with the same value, therefore, they're able to generate matching codes without requiring any sort of network connection or being able to communicate with each other.

And all this talk of keyloggers is irrelevant. I would bet that most passwords are harvested from phishing - from grandma and grandpa thinking they'll win the Nigerian lottery as long as they hand over all of their credit card numbers and account passwords. Or from someone who works in an office setting and can't remember their secure password so they have it written on a post-it note stuck to their monitor, out in the open for anyone to see. And having worked a couple years in an IT support role, I've seen both of those happen on plenty of occasions. You can't fix stupid.

 

[munkery]

For one to brute force a Google account with 2 step authentication, they have to brute force your regular password (and using 2SA is not an excuse to use a crappy password like your dog's name, you should still be using a good, strong password as your main password) but then they have to brute force the temporary code.

Email clients, at the moment, still only use a single password (referred to as "application specific passwords") for authentication when using Google's 2-step authentication so it really makes no difference than using a secure password without 2-step authentication if an email client is used to access email.

Both secure passwords and Google's application specific passwords are infeasible to brute force. So, Google's 2-step authentication provides no benefit in this regard.

Also, Google provides users with 10 backup codes which are a much easier to brute force than the temporary codes. The implications of this are further explained below.

As you have stated, Google's 2-step authentication is not an excuse to use a weak password. Given that Google's 2-step authentication isn't anymore secure than a single secure password, just using a secure password is sufficient to secure Google accounts.

Oh, then after a few failed login attempts, CAPTCHA kicks in, and I bet after a few more failed attempts some other sort of security kicks in. We're talking about a one in a billion chance.

The initiation of the CAPTCHA for email client based logins is much less strict than for logins via a web browser.

Google provides an API to make email clients that use the user password and 2-step authentication codes rather that the application specific passwords provided by Google.

This allows an attacker to target the user password and 10 backup codes with brute force using a client made with Google's API. This would allow the attacker to take advantage of the more relaxed CAPTCHA afforded to email client based logins.

If the user has a weak password, then the attacker just has to keep the client login attempts at a low enough interval to avoid triggering the CAPTCHA.

Once the weak user password was brute forced, then the attacker could do the same to the 10 backup codes to gain access. Only one of the 10 backup codes needs to be brute forced to provide access to compromise the account.

So, a secure password still has to be used to prevent the account being brute forced despite the 2-step authentication.

Google's implementation of 2-step authentication doesn't really provide much benefit over using a secure password without the 2-step authentication.

The following is why Google's 2-step authentication doesn't provide any meaningful benefit over only using a secure password:

1) email clients still have to use a single password referred to as an application specific password. User generated secure passwords are also unfeasible to brute force and user generated secure passwords become harder to brute force with fewer characters than the application specific passwords provided by Google.

2) there is a potential for the 10 backup codes to be brute forced if the user password is known given that Google's captcha has been defeated in the past and Gmail brute forcers that are unaffected by the captcha are sometimes available. So, the user generated secure password is the only functional protection when methods exist to bypass the captcha.

3) the captcha also provides the equivalent amount of protection from brute forcing to user generated secure passwords and Google's 2-step authentication.

It should be noted that the initiation of captcha for failed login attempts is much less restrictive on email clients in comparison to browsers. Email client logins are more likely to be the target of brute force attacks. Email clients used in conjunction with Google's 2-step authentication still use only a single password. So, Google's 2-step authentication makes no difference in this regard.

 

[polobruce]

Apple's Account Security SUCKs!!!

The original poster is absolutely correct. Apple's account security sucks. I love Apple and switched over to all apple gear 5 years ago. Shortly after they introduced MobileMe I signed up without any problems and started using that as my primary personal email account. I hadn't had any security issues until about a year ago when my account was hacked into. At the time I was really bad with my passwords and basically had one primary password that I used for everything, mail, forum accounts etc. The password was pretty strong i thought so I thought I would be good. And depending on the account I did have different usernames I used as well switching from personal or biz email address, or from 2 different other usernames.

After my account was hacked the first time... I immediately researched best practice for passwords, signed up for LastPass, and began going through the task of changing every accounts password so that it was unique......


Then like a month after I did this... LastPass got hacked....

Now they say no account information was stolen etc.. but shortly after this occurred my account was then packed into for 2nd time. I went through the process of changing all of my password again. One thing that I feel last path could do a better job at is the mass changing the passwords individual passwords for each account. This could be accomplished by allowing users to submit member pages or account pages for each of those sites to make it easier when needing to do mass password updates.

Today I'm finding out that my iCloud account has been hacked into again. there are multiple things that concern me about Apple's lack of security. With the introduction of icloud and the ability to backup your iPhone and computer data, access mail, bookmarks, history, make purchases via iTunes and, the App Store, create support tickets as well is look at serial numbers for products registered, hackers can now get so much information about me from one username and password.


Not only that. But your email box is used as a verification method for most sites when you forget or need to change your password. So, if they have access to my email then they can... a. read my life and find such things as pictures of my drivers license, birth certificate and passport which I was told is good practice to keep in case your out of the country and lose your real one... Social security number is probably in their on pdf's of my mortgage docs for example. I believe they can go into last pass and change my master account password because they use email as a verification method. Basically my life is "up in the cloud".... And like the clouds in the sky..... Anyone that wants to lookup will be able to see me and my info...

What's worse is that the hacker changed my password. So, when I go to applied and reset my password and the verification methods are verify with your email address or personal information... BUT IF THE HACKER ALREADY HAS ACCESS TO MY ACCOUNT AND HAS CHANGED THIS INFORMATION WHAT THE HELL GOOD IS THAT........ and that's it... that's their security.

IF THE HACKER FEELS LIKE WIPING MY IPHONE OR MAC PRO... OR BETTER YET... MONITOR WHERE I AM AND MAYBE KIDNAP ME CAUSE HE SAW THAT I HAVE A MILLION DOLLARS IN MY BANK ACCOUNT BECAUSE THE STATEMENTS GET SENT TO THE EMAIL ADDRESS. GUESS WHAT THEY CAN.
WANTS TO BUY SOME APPS... SURE U CAN DO IT.


EVERYONE HERE THAT DOES NOT SEE THIS AS BEING AN ISSUE IS STUPID...... AND HONESTLY I'M NOT SURPRISED.... WHY???

BECAUSE APPLE HAS STUPEFIED EVERYTHING FOR YOU. To appeal to the masses apple is trying to simplify everything so that the lowest common denominator can still use their products. Since the introduction of the iPhone Apple began stripping away features in their products. You see these changes in iCloud, in the mac os, final cut pro, Lion Server. Some i'm sure were welcome but others you can tell were done to grannie enable it. Like in iCloud mail.. You can no longer create a mail rule that says search for a subject that "STARTS WITH" you only have the option for "Contains". So, for example if I wanted to have order confirmations from my commerce application go directly into a folder but don't want that same rule to run if their is a RE: in the beginning of the subject line i can't..... You can't even add multiple options to a single rule... which i'm almost positive use to be there... (i.e. email = and subject =



The biggest challenge for apple is going to be securing the cloud.... and so far apple has FAILED and shortly it is going to back fire on them..


Unless I am missing information and please correct me.... Apple is lacking even the simplest thing of showing a log of the date, time, and ip address of previous logins, let alone tell you the login was from iPhone, appstore, iCloud web. etc.. They lack any form of 2 step authentication. lack phone verification option for password changes (something that CRAIGSLIST DOES) among others.


So, at this point i'm about ready to stop using my iCloud account and move all my email off there and into my google account... (which has better security) and you can see a login history and can log yourself off locations...

PLEASE I"M OPEN TO EVERY SUGGESTION EXCEPT FOR THE GIVEN ONE OF NOT STORING YOUR STUFF IN THE CLOUD.


SORRY FOR THE RANT BUT THIS REALLY IS A SERIOUS PROBLEM.

 

[*LTD*]

The original poster is absolutely correct. Apple's account security sucks. I love Apple and switched over to all apple gear 5 years ago. Shortly after they introduced MobileMe I signed up without any problems and started using that as my primary personal email account. I hadn't had any security issues until about a year ago when my account was hacked into. At the time I was really bad with my passwords and basically had one primary password that I used for everything, mail, forum accounts etc. The password was pretty strong i thought so I thought I would be good. And depending on the account I did have different usernames I used as well switching from personal or biz email address, or from 2 different other usernames.

After my account was hacked the first time... I immediately researched best practice for passwords, signed up for LastPass, and began going through the task of changing every accounts password so that it was unique......


Then like a month after I did this... LastPass got hacked....

Now they say no account information was stolen etc.. but shortly after this occurred my account was then packed into for 2nd time. I went through the process of changing all of my password again. One thing that I feel last path could do a better job at is the mass changing the passwords individual passwords for each account. This could be accomplished by allowing users to submit member pages or account pages for each of those sites to make it easier when needing to do mass password updates.

Today I'm finding out that my iCloud account has been hacked into again. there are multiple things that concern me about Apple's lack of security. With the introduction of icloud and the ability to backup your iPhone and computer data, access mail, bookmarks, history, make purchases via iTunes and, the App Store, create support tickets as well is look at serial numbers for products registered, hackers can now get so much information about me from one username and password.


Not only that. But your email box is used as a verification method for most sites when you forget or need to change your password. So, if they have access to my email then they can... a. read my life and find such things as pictures of my drivers license, birth certificate and passport which I was told is good practice to keep in case your out of the country and lose your real one... Social security number is probably in their on pdf's of my mortgage docs for example. I believe they can go into last pass and change my master account password because they use email as a verification method. Basically my life is "up in the cloud".... And like the clouds in the sky..... Anyone that wants to lookup will be able to see me and my info...

What's worse is that the hacker changed my password. So, when I go to applied and reset my password and the verification methods are verify with your email address or personal information... BUT IF THE HACKER ALREADY HAS ACCESS TO MY ACCOUNT AND HAS CHANGED THIS INFORMATION WHAT THE HELL GOOD IS THAT........ and that's it... that's their security.

IF THE HACKER FEELS LIKE WIPING MY IPHONE OR MAC PRO... OR BETTER YET... MONITOR WHERE I AM AND MAYBE KIDNAP ME CAUSE HE SAW THAT I HAVE A MILLION DOLLARS IN MY BANK ACCOUNT BECAUSE THE STATEMENTS GET SENT TO THE EMAIL ADDRESS. GUESS WHAT THEY CAN.
WANTS TO BUY SOME APPS... SURE U CAN DO IT.


EVERYONE HERE THAT DOES NOT SEE THIS AS BEING AN ISSUE IS STUPID...... AND HONESTLY I'M NOT SURPRISED.... WHY???

BECAUSE APPLE HAS STUPEFIED EVERYTHING FOR YOU. To appeal to the masses apple is trying to simplify everything so that the lowest common denominator can still use their products. Since the introduction of the iPhone Apple began stripping away features in their products. You see these changes in iCloud, in the mac os, final cut pro, Lion Server. Some i'm sure were welcome but others you can tell were done to grannie enable it. Like in iCloud mail.. You can no longer create a mail rule that says search for a subject that "STARTS WITH" you only have the option for "Contains". So, for example if I wanted to have order confirmations from my commerce application go directly into a folder but don't want that same rule to run if their is a RE: in the beginning of the subject line i can't..... You can't even add multiple options to a single rule... which i'm almost positive use to be there... (i.e. email = and subject =



The biggest challenge for apple is going to be securing the cloud.... and so far apple has FAILED and shortly it is going to back fire on them..


Unless I am missing information and please correct me.... Apple is lacking even the simplest thing of showing a log of the date, time, and ip address of previous logins, let alone tell you the login was from iPhone, appstore, iCloud web. etc.. They lack any form of 2 step authentication. lack phone verification option for password changes (something that CRAIGSLIST DOES) among others.


So, at this point i'm about ready to stop using my iCloud account and move all my email off there and into my google account... (which has better security) and you can see a login history and can log yourself off locations...

PLEASE I"M OPEN TO EVERY SUGGESTION EXCEPT FOR THE GIVEN ONE OF NOT STORING YOUR STUFF IN THE CLOUD.


SORRY FOR THE RANT BUT THIS REALLY IS A SERIOUS PROBLEM.

So you were hacked three times, or was it four times, on the same service?

I'm curious because most of us go through life not having been hacked even once, on anything.