New answers tagged

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 ...


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 ...


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 ...


0

There IS defined hostbased authentication method in ssh protocol, which does basically what is in the question. This method needs to be explicitly allowed: HostbasedAuthentication yes EnableSSHKeysign yes in ssh_config, but also on the server (but certainly not for everyone -- validated DNS name is a good start): Host *.trusted.example.org ...


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 ...


0

When working - for example - with JWT tokens, the tokens are self-signed. Which means that the resource service can verify the token's integrity without having to communicate with the authentication server. Which is fine to do with short-lived access tokens. But when the refresh token will be used to acquire a new access token from the authentication server, ...


0

" When a server supporting the Token Binding protocol receives a bound token, the server compares the TLS Token Binding ID in the security token with the TLS Token Binding ID established with the client. If the bound token came from a TLS connection without a Token Binding, or if the IDs don't match, the token is discarded." draft The problem ...


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 ...


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 ...


0

Generally speaking, this is a question of authentication: How do I know who you are, and how can you prove it to me? Within that, the answers fall into a few categories: Something you have Something you know Something you are There are many different ways to take apart these categories. For example, "something you have" could be a 2FA token, a smart ...


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 ...


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 ...


0

Consider this implementation. You send a refresh token and you get a new access token periodically. Now this token can be a one time pad. Suppose an adversary is able to access your refresh token and gets a new otp, then your legitimate requests will fail. If this happens multiple times, you can detect the attack. On the other hand, when you have non ...


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 ...


0

When using CloudFlare (like mentioned in one of your comments. Two things happen. The server and application both are not aware that CloudFlare (a reversed proxy) is used. To fix this you need to tell the used software (WordPress and fail2ban) where to find this original visitors IP. Otherwise I'll be working with the CloudFlare IP's (since that's the new ...


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 ...


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; ...


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 ...


0

If you have an access to the server then you can install fail2ban. You will need to set up jail for the wordpress /etc/fail2ban/jail.d/wordpress.conf [wordpress] enabled = true filter = wordpress logpath = /var/log/auth.log port = http,https $ service fail2ban restart For more details check here. Make sure that you are not using default username ...


-4

It can't be possible (as far as I know PHP and MySQL). That's because PHP (a language in web development) tells MySQL (database server) to store your input after it's SUBMITTED. And the auto-completion, I don't know much on it or what language is used to make that kind of feature, but I think it just gets what matches more with your string (i.e your ...


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 ...


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.


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 ...


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. ...


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 ...


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, ...


0

I've seen several web applications that implement a "sudo mode". In your example, it might look something like this: I, an admin, am logged into your application, and stay logged in for long periods of time (perhaps the session expires after 30 days). I protect this account with reasonable amount of security, but I'm not super paranoid about it. When I ...


3

I'll propose a rule of thumb which may help you with your decision: When switching from a lower privilege level to higher, make them login again. When switching from higher to lower, do not require another login. Here's an example of how bank ATMs implement this rule. Consider these 2 scenarios: You put in your ATM card, enter your pin, select ...


0

You open yourself up to bad user behavior at that point. Really you want to keep them safe by making sure you protect against as much bad user behavior as possible. If an admin opens the web view it makes it easier for them to forget they are in the admin area and leave without signing out of the admin area, leaving it open to someone sitting down and ...


2

Universally Unique ID v 4 with device pre registration sounds about right for this sort of application. When a device is in the factory you flash it's firmware with a UUID in it. Then you register that UUID with the DB. If the UUID exists, you generate and flash a new one. This should be exactly what you want because now if someone grabs a device, they have ...


0

I think there might some reasons behind for not using lockout/retry counter: For any invalid username input or good username/bad password input, it should always return error message 'Invalid username or password'. Or the error message will leak user information. For lockout, it is not valid non existing users; locking out existing users might even worse ...


2

Careful! Based on what you're saying, you've already donned the Hat, and now it's up for interpretation whether it's a Black, Grey, or White Hat. Depending on localities, you may actually have already committed a felony. System administrators can get very protective of their systems, and they don't always see the honest-guy-shows-you-your-lock-is-broken ...


1

Yes, this is a serious security oversight and needs to be reported so it can be fixed immediately.


2

I see two possible problems with this: Browser/Application Autocompletion If you do it in a web browser, and the field you enter the password in can allow data to be stored by the browsers autocompletion - then people with access to the browser can find your password. Either by chance, or intentionally. If you enter passwords in a password field, it should ...


1

Yes, they need your plaintext password to make the VPN work, simply because their service is badly configured. They shouldn't need your password in plaintext. The problem is that they use your plaintext password in their authentication procedure. When a new user creates an account, the VPN provider should properly hash their password and use that hash to ...


4

Any answer to this will be pure speculation: there is no right answer. That said, my opinion is that OpenSSL is at least as good as any closed-source crypto library. Consider that github lists 175 contributors to the openssl project, and 1,442 forks, while google scholar finds 17,400 academic papers for "openssl". Go ahead and find me a closed-source ...


1

The Key principle behind open source software is peer review. The idea is that many people (experts and amateurs alike) will review the code over time and that review process will lead to better, bug free code. So IMO yes, open sourced crypto algorithms are better than closed sourced algorithms for just this fact. However, both systems are still vulnerable ...


0

The refresh mechanism is precisely built to avoid saving credentials. Credentials give you access to the whole account, whereas the refresh token only gives you access to auth tokens that will work for the designated domain. You say you app is stateless, but if you can save credentials why can't you save a refresh token? Besides, your app should handle ...


0

As I mentioned in the comment, you can't trust javascript served by the server. The idea of keeping the client side downloaded on their computers is interesting, although that doesn't really solve the issue. The server can still include javascript as part of a response unless you are insanely careful. In this case I really wouldn't go with javascript. ...


4

The "common solution" you mentioned has one glaring and obvious flaw: it can't use salt. If your hash has a salt (it should), then you need to fetch the salt before performing the hash operation. And if you're fetching the salt, you should just fetch the hash result at the same time. In fact, the two are typically stored in the same string. Ideally, you ...


3

Assuming that your stored procedure uses something like bcrypt with a secure salt and many rounds, I see no problem with what you are implementing. Your basically treating the database as an identity provider in a federated identity system where the applications are PHP applications. That said, I see no reason why you would do this. PHP has builtin ...


-1

Is the stored procedure doing salting, and multiple rounds of secure hashing? If you don't implement this right, it could effect DB performance and your security. There's a LOT of libraries out there in pretty much every web language to handle secure authentication. Using a stored procedure is a good idea when authenticating the user or interacting with ...


1

With regards to your first question, you probably should make that an option or at least query the user on which piece(s) of information they've forgotten. If they forgot their password but remember their security question then it doesn't make sense to require a new security question answer. If the user forgot both then they'll need to reset both. You ...


0

It doesn't matter that you have the identity unless you are a trusted idp for the service that's protecting its resource with SAML. That said, if you have a SAML response from an idp that the service trusts, then you should be able to post that to them as an sso token.


2

You should send the password reset link (or code) to a predefined email address (or phone number). This is the only protection in this scenario. So called "security questions" are not "less secure" they are totally insecure and if used incorrectly they decrease security as discussed here Do security questions subvert passwords?. The only reason to use them ...


0

I only know that Desfire EV1 has the 3DES/3KDES This is not the only relevant point. NXP has made several design flaws which allows to read the "protected" data. In November 2010, security researchers from the Ruhr University released a paper detailing a 'side channel' attack against MIFARE cards, including the DESFire EV and EV1 cards: ...



Top 50 recent answers are included