Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

2

If you hash the google ID you must then rely on the hash function having no collisions, also as you need to use a plain hash like SHA256 not a salted hash like Bcrypt2, because for lookups you need a hash that can be repeated with zero information. For passwords you want a salted hash like Bcrypt2 to prevent rainbow-table attacks. Hashing the google id (...


1

No. The secret is password, not user ID. Hashing any user IDs has no sense. Furthermore, is seems you store hashed Google passwords. It makes no sense. Normal users will not tell you (your application) their Google passwords.


3

If any email service is processing mail, then there is a possibility that they can "read" the emails. That goes for ProtonMail, too. The only way to avoid the risks is to have end-to-end encryption of the email content. Email has never meant to be secure from the email handling infrastructure.


7

There's no difference: DuckDuckGo doesn't offer any privacy protection when redirecting the search to another result page with a !bang. E.g. !google foo (https://duckduckgo.com/?q=!google+foo) just redirects to https://google.com/search?hl=en&q=foo using both meta refresh <meta http-equiv='refresh' content='0; url=https://google.com/search?hl=en&...


0

It sounds like something on your site is generating posts to your authentication page (perhaps a bug or misconfiguration) with no credentials. Your brute force protection is picking up on the Auth failures and locking users out. Then when you visit the site you generated the same empty authentication posts and triggered the same brute force protection and ...


2

I think you've confused a few things. What kind of attacker? What access do you mean they have? DNS only does domain resolution - it deals with turning names into IP addresses, for what's in the URL before the first slash, when it's not an IP address. What you posted is IP addresses, which shouldn't even touch DNS, other than potential reverse-resolves.


7

As inefficient as it sounds, that's exactly how it works. Head on over to google.com, bring up your developer tools in your browser (CTRL+SHIFT+I or CTRL+OPTION+I in Chrome), click the network tab, and then start typing in the search box. You'll see a series of GET requests to to the /complete/search url path, like this: https://www.google.com/complete/...


0

Is there a cache stored somewhere in the browser? This is really easy to test: enter a search term in the search bar, then disconnect the network and try the same search term. I just tried this to confirm again, and there is no autocomplete without a network. Every character you type is sent to Google to auto-suggest completions. If so, are these ...


1

The google login uses OpenID Connect and therefore does not expose Alices credentials to the service. Google handles the authentication process and passes the information, that this is indeed Alice to the service provider in the form of a token. However, if Alice was tricked to enter the password for her google account in a phishing-form on the ...


3

Your unhashed password ended up on their system because that's typically how authentication works, with credential information being sent to a server which then verifies it. It should never be an assumption or expectation you make as a user that your password is not available to the server. That is why it is typically considered best practice to use ...


4

Certain browsers have certain features. The service runs JavaScript they provide you, so they can run a lot of feature tests in the actual browser. This can be used to validate your userAgent string. For example (purely hypothetical), if everyone knows that Chrome after v50 supports CSS variables, and any Chrome after v40 no longer support the old ...


-3

It's still true that hashes are one-way: A hash can be computed from a password, but the inverse is not true: a password cannot be derived from its' hash. So logically, that leaves us with only one possibility as to how Google came to capture their users passwords in clear-text: they were NOT being hashed BEFORE transmission. Were Google to have only ...


10

I'm figuring that the foundational knowledge about this topic is slowly being lost to time, and there are new course modules in schools around the world to cover this type of thing, so I think it's appropriate to cover it here. There is a separation between the content of a site and the advertisements shown on the site. Sites like Instagram (or newspapers, ...


Top 50 recent answers are included