Tag Info

Hot answers tagged

39

The way I've seen some large systems do it is to only require a captcha after sequential failed login attempts (ie: reset the count after a valid login). If you are worried about automated cracking, you could put the captcha at some high number of failures like 20, 50, 100 failed attempts. Almost no legitimate user will see the captcha, but an automated ...


28

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time ...


23

Short version No. All you need is WPA2-AES with a custom SSID and a strong passphrase. All this assumes a "home" scenario where the AP and clients are using a PSK (preshared key). In Enterprise settings there are a couple of other attack vectors but one nice thing about a PSK is it greatly simplifies the attack surface. It pretty much comes down to the ...


21

From your initial understandings: A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate. As ...


19

Since you didn't enter your second factor code from your phone, and since you didn't say that you received a text requesting the second factor, you should be safe. However, if you want to be sure that all bases are covered (or if you hadn't enabled 2 factor authentication), there are a few things to check to be sure that you haven't been compromised and ...


12

The PostgreSQL documentation says that UUID generation relies on the OSSP library. A look at the source code of OSSP (version 1.6.2) shows that the code uses /dev/urandom on Unix-like systems (CryptGenRandom() on Windows), and also a much weaker PRNG based on current time, process ID, and the C library rand() function. Fortunately, the two outputs are XORed ...


7

Secure Communication The communication protocol must be secure. If the communication channel is insecure then the authentication is insecure. TLS/SSL is one way to secure the communication protocol. If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link. If done properly ...


7

Simple version : Salts don't stop brute force attacks against a single user's password. What they stop is is you being able to do a brute force attack against all of the users' passwords at the same time.


6

I think your question is a bit too broad. Session hijacking can be done on different levels, and it's not just copying something between browsers. For example: A malicious network admin / proxy admin could intercept your session ID and re-use this also. A vulnerable website could be exploited using cross site scripting, where an attacker can gain ...


6

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL. When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN ...


6

It is more secure than a password in some ways, but as you describe, it also makes accounts more vulnerable to other attack vectors. As a best practice, properly implemented two-factor authentication offers much superior security to a single factor, regardless if that single factor is a memorized password or an "on demand" password. Reduced Vulnerability ...


5

A captcha on a login screen makes no sense. I'm not surprised your users hated it. The purpose of captcha fields on forms is to prevent them being submitted by bots. A bot should not be able to login through your login screen, as it should not have valid credentials. If a bot can guess valid credentials, then you need to increase password strength.


5

The users now hate it, Some did not even understand it and I had to remove it. This is where you'll have to make the decision between usability and security. Altough it is useful to have a captcha on your login pages, it's incredibly user unfriendly. My best tip would to log every invalid login attempt to a database, and before authenticating the user, ...


5

A traditional delay would mitigate web browser based attacks, for example if someone uses phantomjs to automate login attempts the normal delay (in your case "more than one second") would be enough to stop anyone from trying to brute force a password, it just takes too long. However, most brute force attacks are not ran in web browsers but in scripted ...


4

My goal with this approach is to ensure that only valid clients are accessing the API, while also preventing replay attacks. Use an ever-increasing nonce value. An attacker should be able to see the contents of the messages (not really sensitive), but should be unable to modify them. Have an API key and secret. Your requests contain the key in ...


4

Integrity is about making sure that some piece of data has not been altered from some "reference version". Authenticity is a special case of integrity, where the "reference version" is defined as "whatever it was when it was under control of a specific entity". Authentication is about making sure that a given entity (with whom you are interacting) is who you ...


4

For a low cost, hacked up solution, I'd look at tracking something that someone would be loath to share with someone else or be without. For that, I'd look at their phones. A simple WiFi access point that registers the MACs and IDs of devices on the network would work in your case, but it also has flaws. MACs and IDs can be modified, but it takes a little ...


4

For a malicious attacker who tries to alter an ISO file while keeping its hash value identical to the hash value of the "genuine" file, the problem is known as a second preimage attack. No such attack is known for SHA-1 right now; if somebody wanted to compute such a second preimage, he would have to pay a cost of about 2160 hash function computations, which ...


4

Part of the problem is that keeping the connection open while you wait for the delay to expire uses precious resources, particularly under certain popular configurations where the number of simultaneous connections allowed is pretty minimal. An ideal solution is to architect your system as follows: Design the logic first into the UI. A failed login ...


3

By definition, 2FA is if you authenticate users based on two of the following: Something you know (like a password) Something you have (like a key) Something you are (biometrics) I see that people often argue in which category e-mail should belong. Although many argue that it belongs in the "Something you have" category, I think that it should rather ...


3

Another way of attacking this might be to install a "honeypot". This is an ordinary input field which is included in the HTML together with the login fields (username, password), but this extra field is hidden using CSS. Typically, bots will try to enter text in all the fields shown in the HTML, so in PHP I checked that if the honeypot field were not empty ...


3

Adding a Captcha or ReCaptcha is not a solution, it is merely an obstacle for both hackers and users. I have very good vision with my glasses and sometimes I can barely make out the image text. I would imagine that someone in denial about their vision is going to be infuriated. Everything you implement needs to have a specific purpose or else you just end ...


3

CAPTCHA systems are there to differentiate between automated bots and real users. Unfortunately, as you've noted, they aren't very convenient (in particular for disabled users). Whether it's "a good idea" or not depends on your use case, really, although they aren't very efficient with user logins: they are not very useful to prevent password guessing ...


3

While your question looks complex I think it boils down to the following setup: two servers, client does not know which one is the correct one both require authentication with client certificates And your question is, if client authenticates against server A: can this server use the successful client authentication to authenticate against server B? The ...


3

You want your server to do as little work as possible, to avoid DoSing yourself. Account lockout is great for DoSing your users. if count(unsuccessful authentications for user U) > threshold then demand solved CAPTCHA if count(unsuccessful authentications for password P) > threshold then demand solved CAPTCHA if dislike CAPTCHA then demand Proof of Work ...


2

As with any two-factor authentication (2FA) method, then you're back to essentially only having a password protecting your account. But with grids I'd consider the printout a greater security risk than the server getting hacked. The thing that I find hilarious about grids as a 2FA method is that A) they are too complex to memorize, so you HAVE to have a ...


2

I am not a big fan of the cookie authentication as you had outlined. Session authentication assigns a random token to the client that has no meaning other than being a pointer to the session information stored on the server. The primary problems being low entropy for token generation. However, cookie authentication tends to have more issues. Because the ...


2

The obvious problem with this is the same problem with just using a password: as soon as someone has that, they have all the access they need. Assuming you'd use your phone, then if your phone was stolen, then that person can log in. If you feel that the risks of using this method is acceptable, then it's acceptable. But you have to understand the ...


2

As pointed out in the comments, ssl/tls will protect your credentials in transit. Encrypting traffic is part of the purpose of the protocol. The other major purpose of the protocol: verifying that you are communicating directly with the party you think you are communicating with. The OP said that ssl proxies are possible and has seen it in action for ...


2

Think for a moment about what your captcha is trying to accomplish. Here is the goal I can think of: Prevent a large-scale automated attack from breaking into weak accounts Here's a way to do that which will probably make your users happier: If a computer successfully logs in (as Bob), set a cookie on that computer so the server knows that computer ...



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