Tag Info

New answers tagged

2

As noted in the accepted answer the signature is determined using the private key over various pieces of data: The value of 'signature' is a signature by the corresponding private key over the following data, in the following order: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string ...


2

A good example of Challenge-Response Password Token is shown on the diagram below:


0

When the server uses IIS, client authentication means mapping the client certificate to an identity, i.e. an account (local account or domain account, depending on context). IIS may apply two distinct methods, with confusing names: clientCertificateMappingAuthentication: IIS will look for a domain account that either contains a copy of the exact client ...


0

I'm not sure that there's any one solution. Different strategies work for implementing different functionality. A common strategy for a B2B deployment is for the server's organization to act as CA and sign public keys from clients. When a client cert is received, the server validates the signature and then maps the cert to a user. The user mapping is ...


2

From a security standpoint you should limit the attack surface you are exposing. As with most security features you should use defense in depth and have several security features in place like: A web based API (like REST with JSON), being server over a TLS connection. Limit allows values to a small set. (highscore is only numbers between 0 and 999999 for ...


1

Yes you should be concerned about this. Its a possible side-channel and it reveals information about your system. Some possible defenses (that are being used) are: Use a pseudo random minimum wait delay. (this means that a valid or invalid response will take about the same amount of time) have an invalid response do all the calculation steps of a valid ...


1

I think that Linux uses some increasing delay for invalid logins. For example, if you login with a bad username or password, there's something like a 1 second delay on your first attempt, 2 seconds on your next attempt, 4 on your third, etc... This both hides the calculation delay that you are concerned with as well as slowing down people trying to mine your ...


-2

Usually it's not a problem that an attacker knows if login exists or not, so if you don't know if it's important for you then most likely it's not. But if you still want to hide the fact login is not exists then I would suggest to add some delay. Probably the best way will be to actually check some hash (and finally return 'false' anyway) so waiting time ...


2

To quote directly: Only use inbuilt session management. Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. What this is saying is that, if you've got a secondary system which doesn't/can't use inbuilt sessions, you shouldn't send that second session token as a ...


4

2FA will decrease the chance that an attacker can steal a complete set of login credentials because, as you point out, the second factor is likely limited by lifetime or a once-use policy. But 2FA will not affect snooping or session hijacking. So, while an attacker may find it more difficult to login as you, they can watch your communication stream and send ...


0

As you have stated yourself: it is slightly more secure because it is limited to a < 30 seconds timeframe, but that really doesn't matter much in the grand scheme of things: it is still very insecure and it will mostly just increase the effort legitimate users will have to put in.


1

When you type "sudo [software]", it will Always assume the software needs admin rights. Thus, the OS will ask for the password, Before the process [software] has a chance to run at all. However, you have a risk, and that is when you have sudo set to "remember" your authorization for a preset time. This is default behaviour, and I Think the time is set to 5 ...


0

Use a browser plugin such as Cookies Manager Plus on Firefox, then you can simply copy the value to the clipboard. As you say, simply paste the value into the command line for Hydra. See my answer here for the syntax that worked for me. "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:F=incorrect:H=Cookie: ...


0

There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing). As an example: you start off with ...


2

First, there is no such thing as complete anonymous. At least once the user returns to edit the post it can be linked to the user (or its IP address) if your site gets monitored after the initial post. Apart from that this might work without the need of logins: Create some random token. Give the user the original token. It might be in the form of a link ...


0

The advantage of OAuth over password-based login is that OAuth allows me to give you limited permission to use my identity without telling you my password. So say your site posts messages to Twitter using my account. I want to give you permission to use my account to post a tweet, but I don't want to give you unlimited access to my Twitter account -- I ...


2

I suppose you could add something like the following to appear below an anonymous positing (only in the session of the editor, of course) If you later want to edit this post, please use the following information: postid = 123456, authentication = iufdhgoieroertz3147493532v or use this link directly: ...


1

First things that comes to my mind is are : timing attack: If I would request the token within the 100ms of the original request, (so the credentials are still in memory) will I get a copy of the credentials? Bruteforce: you do not mention any mitigation against brute forcing, so I could possibly mine all your credentials in that way. Record / playback: I ...


1

Generally, one time use tokens are used to mitigate replay attacks and to make it harder to steal authentication information. They have other uses in protocol design for multi-tentant and multi-user systems. I am going to assume those don't apply because you said this was a custom API built just for you. If you are calling the API over the web using ...


1

This is not a vulnerability as shown as the system is simply taking the value of the first parameter. An HTTP Parameter Pollution (HPP) vulnerability is when you can use the behaviour of the application to some advantage. For example, in my answer here a toAccount parameter is injected: amount=1000&fromAccount=12345&toAccount=99999 This is known ...


2

I agree with the other answers that it is a bad idea, simply because people (=> developers => applications that log information) do not consider URL's to be private and thus there are a lot of different ways the key could be leaked. What you however have correctly recognized is that passwords essentially are a form of security through obscurity. And that ...


0

(B, C, D, R), which ones can attack if the target is A? B and R. Both B and R can spoof the IP address of E and can see the SYN-ACK reply packet from A to get the sequence number for the final ACK. C cannot because the ACK will be sent via R that will route the packet out onto the internet. D cannot because it will not see the SYN-ACKs over the ...


-2

I've personally used HTTPS-with-unguessable-URL as a protocol for delivering files securely. With browser history turned off at the receiving side, and if the URL is communicated as securely as a password would be, this is pretty much as secure as an HTTPS login page. Which is much less secure than, e.g., GnuPG.


57

I'll extend on one point at a slightly more abstract level about why public authenticated spaces are preferable to hidden unprotected spaces. The other answers are all perfectly good and list multiple attacks one should know better to avoid. Everyone with formal training should've heard at some point of the Open Design security principle. It states that ...


-3

Like others have said if you plan on leaving this directory and website up for a day or two with confidential information and data and you are in a serious time crunch then this would be ok but not "best practice". In other words its not recommended but if you feel you need to take the chance. The main issue with this concept is what if the client has a ...


11

Guessing the URL, however, is blind. It requires being on the right domain (and subdomain) However, most respectable spiders don't "guess" at sites, they just follow links’ Considering major search engines not to be respectable is a defensible position, but it doesn't change the fact that they do more than follow links. In particular, search ...


48

Since we're talking theoretically, here are several reasons why a random URL alone is not sufficient enough to protect confidential data: URLs can be bookmarked. URLs are recorded in the browser history (public kiosk). URLs are displayed in the address bar (shoulder surfers). URLs are logged (think 3rd party proxy). URLs can be leaked via Referrer headers ...


1

I believe this attack if successful is called as HTTP Parameter Pollution(HPP) and the ability to inject parameters is called HTTP Parameter Injection. More on that at: https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OTG-INPVAL-004%29 Now, as far as the scenario you described is concerned, in my experience, a lot of servers will ...


2

Your protocol is not safe by any means! Example for MitM: A sends random nonce G1 to B C intercepts and sends nonce G1c to B B sends back hash_k(G1c) and random nonce G2 C intercepts and sends hash_k(G1) and nonce G2c to A A verifies hash_k(G1) (is OK), then sends back hash_k(G1 | G2c) C intercepts and sends back hash_k(G1c | G2) B verifies and a ...


1

No. Stick to known protocols such as TLS, Kerberos, SSH & IPSec for key exchanges. Try researching Diffie-Hellman key exchanges and ECDH (Elliptical Curve Diffie-Hellman, the new method of key exchanges like your example).


0

The question is more geared towards is it a good idea to generate passwords for the users and email it to them? Reasons not to do this include: It could be vulnerable to shoulder surfing. A user walking past while another user opens their email not expecting a password to be displayed could have their credentials stolen. This is particularly a risk ...


1

It's only tangentially related, but David Aspinall (University of Edinburgh) and Mike Just (Glasgow Caledonian University) published a paper on partial passwords in 2013: "Give Me Letters 2, 3 and 6!": Partial Password Implementations & Attacks. Their paper looks at online attacks for which the backend storage mechanism is irrelevant, but it makes a ...


0

Based on your comments it sounds like S is passing some encrypted or signed access token to P that it passes to H. H can decrypt or verify the token is authentic and use the information contained within to determine of P is allowed to perform the app. That sounds great. I'm not sure that you need a nonce here if all you are trying to do is prevent replay. ...


1

Tracking down the links referenced in the answers, I think it would be safe. Out of an abundance of caution, I will exclude the private key from the list of md5sum values I allow to be stored on computers connected to the Internet. I will then use the signatures generated for the same binary to confirm the excluded private keys are identical. Even if ...


0

If I include a Forgot Password service, then what's the point of using a password? Because if a user can log into their account with their known password they know that an attacker hasn't used a password reset link and changed their password. Password resets create noise. In logs on the target system (which can sometimes be viewed by the user), and in ...


0

Although it is only the collision resistance property of MD5 that has so far been compromised, I would not use MD5 for any cryptographic purposes even though in your case an attacker would need to compromise the pre-image resistance. Use a secure algorithm such as SHA-256.


1

Looking at your comment on @zedman9991's answer; if you want to check that the servers' filesystems are identical, why not generate one hash for the whole filesystem, rather than one hash per file? This will likely fail on two different severs since operating systems generate files like candy, timestamps / MAC addresses will differ, etc, so it might be ...


2

In some cases it might actually compromise the security of it. http://www.di.ens.fr/~fouque/pub/crypto07b.pdf HMAC-MD5 has a key recovery attack in the upper end of achievable but impractical, although attacks only get better over time.


0

As part of the handshake for mutual auth SSL, both the server and the client have to prove that they hold the private key corresponding to their cert. If that isn't the case, the SSL handshake will fail. I think that is option (1) of your question.


2

You can use the MD5 cryptography hash without any serious concern but why not consider using the public key to confirm the private key in question. You could have the partner sign a sample binary and use the public key to confirm the signature and thereby confirm the private key. If you want to work outside the signing infrastructure you could use a ...


-1

It is good practice to hash on the client side, then salt the password and hash again on the server side. This is an extra layer of protection against man in the middle attacks. SSL is the first layer however Snowden's revelations made it clear that SSL can be compromised by organisations such as the NSA with relative ease.


0

I know this is an old question, but I thought I'd weigh in. Normally the client sends 'X' (plain text password), which is converted by the server to 'Y' (hash) and stored. The benefit is that the thing that is known to and transmitted by the client is not the same thing that gets stored in the server's database. What I think you're proposing is for the ...


2

Authentication relies on the following: (source) Something you know Something you have Something you are A good reason to use TOTP is to increase security by using multiple factors from the list above. For example, if your password becomes known to someone else, they would still need access to your TOTP device to authenticate. However, that does not ...


1

Yes this would be secure. Why would it be secure? Because you would be running HMAC (the underlying primitive of PBKDF) as a stream-cipher using some key-derivation function. As this is a common approach (at least for integrated encryption schemes) using this would at least as secure as using the bare KDF and a salt. However I'd strongly argue against ...


0

Short answer, I do not think that any society will prosecute anyone for removing illegal content. You are just cleaning some mess, that's all you are doing. Would you talk about uploading new content of the same kind, creating new accounts for such usage, etc., then anonymity would be preferable. But here you are just cleaning your account. From a more ...


1

My brief research on the Home button showed two trends: (a) the user bypassing it with Accessibility options; (b) using certain features to prevent children from hitting it. It appears that it's a SAK in practice whether or not it's designed for it. Note that this applies to apps that haven't compromised iOS security somehow. If they do that, they might ...


0

One thing I didn't see mentioned is using fingerprint scanners to prevent time-clock fraud. This has significant takeup with some of the largest players in retail and timekeeping adopting it. I'm not sure the actual percentage but I've seen them all over the States. The vendors' argument is that they prevent thousands to tens of thousands in time-clock fraud ...


-3

USB Tethered to wrist. (Overkill) Run an entire OS temporarily from a USB stick. When you want to log in, shut down comp, enter USB stick, load from it, log into your accounts, when done, log out, shutdown computer, unplug USB stick. No traces (that lead to credential parsing), easy to destroy, easy to hide... Safe? Adding a jumper module onto the USB ...


0

It never hurts to anonymize the traffic. Chances are nothing is going to happen either way, but if you do login hide the current IP address. It would depend on log retention length and a LOT of other factors.


1

Actually there was a recent flaw found in JWTs. If you are using node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512) it will allow an attacker to create their own "signed" tokens with whatever payload they want, allowing arbitrary account access on some systems. If the JWT is stored in a ...



Top 50 recent answers are included