Chromium and Google Chrome security question
closed account (N36fSL3A)
What's the point of getting these if your data is un-secure and you can't play games?
closed account (N36fSL3A)
Anybody can easily break into the server room and take a few servers with them to steal data. I'm sure some terrorist organization can take credit card numbers to pay for war debts.
Lesson From This Story - Don't buy crappy google laptops (BTW, my uncle has one)
Lesson From This Story - Don't buy crappy google laptops (BTW, my uncle has one)
closed account (G309216C)
Well terrorists would do that but normal Hacker wold not do that as this requires physical strength and most hackers are one and it would be hard to physically steal it. Of course each server would weigh around a tonne and also require Liquid Nitrogen cooling systems so trying to crack the actual hashes and salts would take centuries and it would be too cumbersome.
| Fredbill30 wrote: |
|---|
| Anybody can easily break into the server room and take a few servers with them to steal data |
Yes, nobody has physical security. That's way overrated.
Then that's no longer considered easy by the average person. I sure as hell can't find a group of friends who wants to grab some firearms and go storm a Google datacenter by force.
closed account (1yR4jE8b)
Someone could walk out from a Google data center with my sync data and I wouldn't give two shits:
1. It's hashed.
2. It's salted.
3. It's encrypted using a unique passphrase known to NO ONE -- not even me, I randomly generated it then stored in an Rijndael encrypted and SHA256 hashed database stored only on a TrueCrypt volume.
1. It's hashed.
2. It's salted.
3. It's encrypted using a unique passphrase known to NO ONE -- not even me, I randomly generated it then stored in an Rijndael encrypted and SHA256 hashed database stored only on a TrueCrypt volume.
closed account (N36fSL3A)
As I said before- Use it to by weapons to terrorize a country. Anyway, that's irrelevant. Back on topic.
closed account (1yR4jE8b)
No. You are missing the point entirely. Everything is encrypted, so even if they *have* the data; they can't look at it, therefore, cannot terrorize jack -- and would be worthless to sell. And it is on topic, because the topic would include a "rogue" Google employee stealing some data and causing havoc on people's accounts which we've already established multiple times is nearly impossible without the unhashed password and passphrase.
Last edited on
Let me tell you something, going in by order:
1. Install Chrome on PC "A"
2. Save a password for a website
3. Install Chrome on PC "B"
4. Try to load a password for the same website.
What happens is:
If YOU can get your password, GOOGLE can too!
They made the encryption/hashing/salting/whatever systems and they're completely able to get your passwords.
If this wasn't like so, you would be never able to load back your passwords on another PC, because Google didn't make the decryption system at all, in that case!
And, yes, I remember a Google employee who broke into a discussion between kids, and got slightly later fired.
http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats
So, guys, it's useless that you say "They cannot decrypt the password" because they do the encryption.
But they don't seem to be liking this password stealing idea.
I'm pretty good at leaving all of my passwords to google, because the bigger problem isn't where my passwords are stolen, but how.
This isn't the only way to steal a password.
If I recall, the passwords are being passed as base64, and it doesn't take much if you "filter" your network, to see the password being sent as a header for HTTP request.
HTTPS, it's different and I don't know how it works.
1. Install Chrome on PC "A"
2. Save a password for a website
3. Install Chrome on PC "B"
4. Try to load a password for the same website.
What happens is:
If YOU can get your password, GOOGLE can too!
They made the encryption/hashing/salting/whatever systems and they're completely able to get your passwords.
If this wasn't like so, you would be never able to load back your passwords on another PC, because Google didn't make the decryption system at all, in that case!
And, yes, I remember a Google employee who broke into a discussion between kids, and got slightly later fired.
http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats
So, guys, it's useless that you say "They cannot decrypt the password" because they do the encryption.
But they don't seem to be liking this password stealing idea.
I'm pretty good at leaving all of my passwords to google, because the bigger problem isn't where my passwords are stolen, but how.
This isn't the only way to steal a password.
If I recall, the passwords are being passed as base64, and it doesn't take much if you "filter" your network, to see the password being sent as a header for HTTP request.
HTTPS, it's different and I don't know how it works.
closed account (1yR4jE8b)
You have no idea how hashing and salting works.
Hashing is completely different from encryption, and is *one-way* only. When you hash-something, there's no going back. Period. Ever wonder why if you forget your password, your only option is to reset it? Because they can't just open your account and "unhash" your password. Once it's been hashed, that's it. Using a salt makes it practically impossible to brute-force a password. Because not only do you need to know the proper term to get the hash, you ALSO need the salt which is usually just random data.
So, let me tell YOU something; going in by order:
1. Install Chrome on PC "A"
2. Log on to Sync, put in your Google password. Your password is saved locally, then hashed+salted and stored on their servers.
2. Save a password for website.
3. Password is encrypted using your "real" version of your google account password, stored locally.
4. Encrypted password is sent to google sync servers.
5. Install Chrome on PC "B"
6. Log into sync on that PC. You put your password, then it's hashed+salted and compared to the saved hash+salt data on the server.
7. Server sends you the encrypted password data.
8. Password is decrypted on the client using the real version of your google account password which you inputed yourself.
If you use a passphrase, your sync data is encrypted *twice* and the passphrase isn't stored at all on Google's server. That's why they say, "if you lose your passphrase, you are screwed".
All you have to do is use a program like Wireshark and check the packets coming and going from Chrome sync. Without your Google password, it's just garbage.
Sending a password for anything over HTTP is just *stupid* and has nothing to do with Google. And Google uses an encrypted connection to transfer your sync data anyway.
Really, this is basic undergraduate level computer science here. I could implement a rudimentary system as strong as Google's in a matter of hours.
As far as that Gawker (lol) article: chat logs != encrypted passwords; and the article doesn't even mention encryption or decryption. Given the gawker network's reputation for sensationalism, lack of citing sources and outright lying, I would take anything they say with a huge grain of salt.
Hashing is completely different from encryption, and is *one-way* only. When you hash-something, there's no going back. Period. Ever wonder why if you forget your password, your only option is to reset it? Because they can't just open your account and "unhash" your password. Once it's been hashed, that's it. Using a salt makes it practically impossible to brute-force a password. Because not only do you need to know the proper term to get the hash, you ALSO need the salt which is usually just random data.
So, let me tell YOU something; going in by order:
1. Install Chrome on PC "A"
2. Log on to Sync, put in your Google password. Your password is saved locally, then hashed+salted and stored on their servers.
2. Save a password for website.
3. Password is encrypted using your "real" version of your google account password, stored locally.
4. Encrypted password is sent to google sync servers.
5. Install Chrome on PC "B"
6. Log into sync on that PC. You put your password, then it's hashed+salted and compared to the saved hash+salt data on the server.
7. Server sends you the encrypted password data.
8. Password is decrypted on the client using the real version of your google account password which you inputed yourself.
If you use a passphrase, your sync data is encrypted *twice* and the passphrase isn't stored at all on Google's server. That's why they say, "if you lose your passphrase, you are screwed".
All you have to do is use a program like Wireshark and check the packets coming and going from Chrome sync. Without your Google password, it's just garbage.
Sending a password for anything over HTTP is just *stupid* and has nothing to do with Google. And Google uses an encrypted connection to transfer your sync data anyway.
Really, this is basic undergraduate level computer science here. I could implement a rudimentary system as strong as Google's in a matter of hours.
As far as that Gawker (lol) article: chat logs != encrypted passwords; and the article doesn't even mention encryption or decryption. Given the gawker network's reputation for sensationalism, lack of citing sources and outright lying, I would take anything they say with a huge grain of salt.
Last edited on
@The article:
He actually had access to their communication and asked the actual "users" about personal questions.
I'm not sure if he's the one, because more than one access to private data, from Google personnel, have happened.
@The 8 steps:
So... you're telling me Google doesn't have users passwords?
You're saying that, if users miss their passwords, they will have screwed up Favourites and Passwords on every website, because they're not unhashing with A but unhashing with B and will be getting different results.
@Sending passwords via HTTP:
Concords, but I'd be more careful about this, than about saving passwords on Google "Cloud".
Useless to say, if Google has either your real or hashed password, it is anyways able to access to your websites' other hashed passwords.
He actually had access to their communication and asked the actual "users" about personal questions.
I'm not sure if he's the one, because more than one access to private data, from Google personnel, have happened.
@The 8 steps:
So... you're telling me Google doesn't have users passwords?
You're saying that, if users miss their passwords, they will have screwed up Favourites and Passwords on every website, because they're not unhashing with A but unhashing with B and will be getting different results.
@Sending passwords via HTTP:
Concords, but I'd be more careful about this, than about saving passwords on Google "Cloud".
Useless to say, if Google has either your real or hashed password, it is anyways able to access to your websites' other hashed passwords.
| In an incident this spring involving a 15-year-old boy who he'd befriended, Barksdale tapped into call logs from Google Voice, Google's Internet phone service, after the boy refused to tell him the name of his new girlfriend, according to our source. After accessing the kid's account to retrieve her name and phone number, Barksdale then taunted the boy and threatened to call her. |
| In another incident, Barksdale unblocked himself from a Gtalk buddy list even though the teen in question had taken steps to cut communications with the Google engineer. |
Last edited on
closed account (1yR4jE8b)
| So... you're telling me Google doesn't have users passwords? |
Yes.
They have hashed and salted version of them, which are usless for decrypting the encrypted sync data.
| if Google has either your real or hashed password, it is anyways able to access to your websites' other hashed passwords. |
Google doesn't have your real password and the hashed one can't be used to decrypted the encrypted sync data.
| You're saying that, if users miss their passwords, they will have screwed up Favourites and Passwords on every website, because they're not unhashing with A but unhashing with B and will be getting different results. |
Are you an idiot? If they forget their password, they won't be able to authenticate on another machine and won't have any data at all.
Like I said: Chat/Voice Logs != Encrypted Sync Data. Nothing in that article mentions decrypting any ecrypted data, so it's completely irrelvant.
Last edited on
So, tell me:
1. How is the password stored while being entered
2. How does the password gets sent in first place
3. How does the cloud server store the password
4. How is a website password stored while being entered
5. How is a website password sent
6. How is a website password stored in a cloud server
Because you're basically saying that only the client can encrypt and decrypt passwords, and that they have no knowledge of how can a server do it.
1. How is the password stored while being entered
2. How does the password gets sent in first place
3. How does the cloud server store the password
4. How is a website password stored while being entered
5. How is a website password sent
6. How is a website password stored in a cloud server
Because you're basically saying that only the client can encrypt and decrypt passwords, and that they have no knowledge of how can a server do it.
closed account (1yR4jE8b)
I've already answered all of these questions, more than once. Go back and actually read.
All of the hashing and encryption happens on the client-side and Google only sees the encrypted data and does not store the encryption keys. Only hashed versions of your Google password to authenticate when you try to log in to your account -- when you put in your password, it's hashed then compared to the hash they have.
It is impossible to "unhash" something. Hashing != Encryption.
Yes. The server would need the unhashed password and passphrase to decrypt the password, and they don't have either.
All of the hashing and encryption happens on the client-side and Google only sees the encrypted data and does not store the encryption keys. Only hashed versions of your Google password to authenticate when you try to log in to your account -- when you put in your password, it's hashed then compared to the hash they have.
It is impossible to "unhash" something. Hashing != Encryption.
| Because you're basically saying that only the client can encrypt and decrypt passwords, and that they have no knowledge of how can a server do it. |
Yes. The server would need the unhashed password and passphrase to decrypt the password, and they don't have either.
Last edited on