Hot answers tagged

93

I highly doubt it. You didn't press enter but Google will sometimes send the information to quickly present your results. This is forced over HTTPS. Your information was likely encrypted and not exposed. According to most sources Google processes on average 3.5 billion searches per day. There is no additional information to prove your query is a password. ...


38

I recommend that you change your password. The fact is, that your password has been sent to their servers, even if you didn't press enter. You can test that on your own, open your browser, Ctrl + Shift + I, select network, start typing and monitor traffic. Here is an example, writing the keyword "test", and not pressing enter. Pay attention to the letter ...


33

As a general rule to remember: Don't make it to hard to use! If it's to hard to use and you keep forgetting, all you've done is shown that you need a different security method to make your door usable. Things mentioned in this post: Private/Public authentication (keys) UUID pre-authentication (fobs) MFA(specifically 2, fob and code gen) Things mentioned ...


25

It has been sent (encrypted) to Google. Change your password It has probably been logged somewhere, along with many search terms and other junk people have typed there. While it's unlikely it will be used for anything you care or that endangers your account, why bear the risk? Simply changing it will solve it. PS: I recommend using a browser search bar, ...


7

Theoretically, you should change your password, as by typing it into google the password is sent to google. Google does use https however, and I personally wouldn't be too worried about google having my password as a search, but hey, it's not ideal. Realistically, I think you should be fine, but if you want complete security, it can't hurt to change your ...


6

It's doubtful, but consider the following The connection to Google Search is encrypted. As far as we know, Google Search History has not been compromised. In the event you have Google Search and Web History Enabled, your search history could theoretically be accessed by someone who managed to break into your account. You stated that you didn't press enter; ...


4

Even though it was probably encrypted as others have stated, there's a risk that it may be displayed again as a suggested search if you were to type the same first few characters as part of a real Google search. If it was displayed again it may be at risk from shoulder surfers. So I suggest you change your password.


3

If we assume that the keystore is safe and keys can not be copied or extracted but it can perform HMAC-SHA(1) then you might think of using TOTP. But I would also recommend taking a look at OCRA. Here you can do real challenge signing. You either realy do only a challenge signing or you can add time or a counter. This way you would have no problems with a ...


3

Authentication to SSH Authentication takes two primary forms, username and password, and key-based authentication. There is also an authenticity check performed when the client connects to the SSH daemon by confirming that the trusted public key has not changed by comparing the fingerprint that is in the trusted database known_hosts, and what the server ...


3

If you run the following command on the SFTP server (assuming the correct path) ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub You will have an output similar to the following: 2048 7c:d9:68:a7:de:ad:26:12:34:56:78:00:4a:9b:a2:b9 root@localhost (RSA) If you save this hash string with your client you can compare it upon first connecting or if you ever ...


2

Your primary problem when handling client-provided is going to be XML External Entities (XXE) attacks. Systems with such vulnerabilities can often be exploited to read files or enumerate the internal network which the server is on. In PHP you can help fix this by calling libxml_disable_entity_loader(true); in order to disable external entities. Another ...


1

Possibly, sometimes. What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes. A cipher suite is split into a number of algorithms for different functionality: Key exhange Bulk ...


1

Given the thin details in the story it's hard to be sure, but the simplest explanation is the credentials were not encrypted when the hacker made a copy. The passwords might have been encrypted in a database, but many so-called 'transparent' database encryption schemes serve only to protect the database file from being copied and reused; they ...


1

Passwords should not be encrypted, they should be hashed. Encryption can be easily reversed if you have the key - and an attacker who has managed to steal the whole database probably has stolen the key as well. A hash can not be easily reversed. When someone attempts to login, the server does not decrypt the stored password. Instead it hashes the provided ...


1

Ideally you would use 2FA where one factor is something physical that you must possess, and the other factor is something that is stored in your head and cannot easily be lost or stolen. Door codes are great for this if they are short and easy to remember, and also used in conjunction with another form of authentication such as a physical key fob. Imagine ...


1

Biometry is an option. A sensor identifies a physical attribute of your body like your face, your voice or your fingerprint. Pros: Your physical attributes are something you always have with you and can not forget Cons: Physical attributes actually can change over the course of your life, both slowly through natural aging or quickly in case of an ...


1

Fundamentally, to trust a computer, you need to verify that it knows something that only the computer you're expecting knows. This is how all certificates work: you assume that because they signed something with a key that only they could possibly know then it's actually the person you wanted to talk to. The same applies for computers: the computer has to ...


1

With OAuth (including OAuth2 or OpenID for that matter) you would still have a local user entity. Where you store information about this user is up to you. In the case of your example, you would create a user table in your database, just as you normally would. What is different is that you do not store authentication information (such as passwords1) in your ...


1

Theoretically, yes, since your password has been sent to Google and is most likely stored somewhere along with billions of other short strings. In practice though, the probability of that password getting out of that database and somehow making its way to an attacker that tries to use it to access your account is several orders of magnitude lower than many ...


1

So I'm going to call your hash a payload. Your idea sounds like: Send me a payload so I can confirm the bcrypt value of it. Which exactly the same as a password: Send me a payload so I can confirm the bcrypt value of it. This is nothing more than security theater and you're trying to get people to generate an absurdly long password they then ...


1

I'm guessing you are getting many of the failed logins from other countries outside of the U.S. What I recommend for WordPress is to download an IP Blocker from the plugins and this gives you the ability to block certain countries or all the countries besides the ones you want. In my case I have a website that is only to be viewed in the U.S. so I blocked ...


1

I think you're asking the wrong question, and will suggest some edits. Your question ("Because of autocomplete, is my password at risk?") implies you have a single password, and worries about the exposure threat from typing it into a search engine. You probably don't need to worry about that, but you do need to worry that one or more of the sites at which ...



Only top voted, non community-wiki answers of a minimum length are eligible