Tag Info

Hot answers tagged

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


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


25

They're all master keyed. They're embarrassingly insecure locks on their own. Case in point: https://www.youtube.com/watch?v=xtJx3j7AhQk


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


7

Digits leverages a single 'factor' typically used in multi-factor authentication: "something you have", which in this case is your phone. Yes, there are weaknesses in the security of a single factor, just like only using a password, but there are strengths over and above a simple password, too. disturbance - yes, an attacker could spam the phone network, ...


7

Your main problem can be summed up as: where's the SSL ? Any eavesdropper, observing the exchanges, will obtain enough information to run an offline dictionary attack: the attacker will be able to "try passwords" by recomputing the relevant hash values and see if they match that which was observed. This is "offline" because the attacker can do all of this ...


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


4

The idea of the TSA padlocks is to be used on luggage and travel bags for international flights. They are not designed to be used for high security purposes, so they will be extremely easy to pick open, but when in an airport would someone have the time or the equipment to pick open your bag while you were not looking? They all have a key override which is ...


3

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

Many OTP systems allow you to receive an OTP by SMS/email. So the system has to know when to send you an OTP. You might suggest that there could just be a "request OTP" button next to the form. But then anyone can repeatedly click on the button, meaning that you will receive a huge amount of spam email/SMS. You might suggest fixing that issue by limiting ...


2

You can prevent replay attacks in JWT by specifying the following claims in your JWT: jti (unique identifier), exp (expiration time) and iat (creation time). The JWT spec clearly states that jti claim can be used to prevent a JWT token to be replayed. From the spec: The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier ...


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.


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


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


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


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


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


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


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


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


2

A good example of Challenge-Response Password Token is shown on the diagram below taken from Gemalto's Gold OTP authenticator page:


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


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


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


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


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


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



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