Tag Info

Hot answers tagged

23

A brute-force can implement pauses to match the short lockout gap you are presenting, so this would slow down a brute-force script. However, locking the account permanently (or forcing CAPTCHA & security question in addition to future login attempts) after x-number of consecutive failed attempts is a better way to accomplish that goal. Your approach ...


17

There's a growing number of what I am calling "slow brute force attacks". Where a bot net with a listing of targets makes a low number of attempts at regular intervals to each target in effort to not get caught by the usual methods of monitoring fast attacks. I manage a number of websites and I typically see failed login attempts ranging from 3 to 10 ...


13

I like the silent approach. As a penetration tester who frequently does testing for PCI compliance, I run into account lockout issues regularly. PCI-DSS requires that accounts be locked out for a minimum of 30 minutes (or until unlocked by an administrator) after six failed login attempts. My problem with a messages stating the account has been locked is ...


10

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks ...


9

From a security control perspective, all it really does is slow down the ability of automated password probing software to perform their task of trying out multiple passwords. The site is hoping an attacker may choose a "softer" target instead of their site. As an actual security control, this technique is not particularly effective. Also, specifically ...


4

The implementation of this would be tricky to get right. You'd have to consider various ways an attacker might realize that something is up. My first immediate thought is that an attacker might notice that a rate limited failed login returns faster than a normal failed login. Or perhaps the message returned is slightly different, inadvertently. In any case, ...


4

Yes, insist to change the request to POST. The main issue here is the fact username and password will be saved in logs. As best practice no logs should contain sensitive information even if they are very secured. This is clearly specified in rfc2616: 15.1.3 Encoding Sensitive Information in URI's Because the source of a link might be private ...


3

It may be that you need to narrow the scope a little in order to get started. Which aspect of security are you interested in. From the list of standards, you seem more interested in application security & especially in authentication and authorisation? That would be a much easier set of targets to learn at least to begin with. Also, you may need to be ...


3

Yes, and no. Using client certificates doesn't solve the problem, it moves the problem. Whereas before your problem is the creation, distribution, and protection of a password or other secret. And now your problem is the creation, distribution, and protection of a client certificate. A client certificate is a lot like a password. But it has the special ...


2

Here's three solutions: Have a limited number of one-time-use recovery codes which the user is instructed to print and store in a physically secure location. This is essentially a substitute for "something you have" as it's unlikely the user will remember any of the codes. This is the approach used by Google. Use transitive trust, this works if you know ...


2

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the ...


2

Some sites may allow users to associate a non-confidential picture or phrase with their username, and show it before the user enters their password. Depending upon the mechanisms used to prevent man-in-the-middle situations, such an approach may make it more difficult for a phisher to make a page which, given a username, would quickly and smoothly call up ...


2

If there is an XSS anywhere on the site, an attacker can take any action the user could take. In this case the attacker could add an iframe to the vulnerable page, the iframe would have a source of /deleteaccount and then the attacker fire the click event on the submit button.


2

Most delay based lockout mechanisms specify a progressive delay. If the delay does not increase over time, it may not be enough to stop an adaptive brute forcing program - one that slows down to meet the small delays. The downside in the original example is that it may not slow down the brute force enough. The downside in an algorithm that increases the ...


2

From what could perceive, your problem is not Active Directory-specific. You would still have this issue if it were SQL-based or any other kind of authentication backend. What we have to solve is: how do we keep awareness about the logged-in user account status without remembering the account credentials or asking for re-authenticating AND not forsaking ...


2

So, the basic scenario you propose is to send credentials from a browser, to your web server. So, we're dealing with HTML and Javascript and associated assets in the browser, and the communication is over HTTP/HTTPS. These are the only components relevant to the specific function in question. And in fact, the fact that you're using JavaScript to send ...


2

Using only a BIND isn't guaranteed to restrict access to desired users. For example, you'll also want to check if the user is locked, e.g. the userAccountControl attribute. If you are really concerned about storing credentials in memory and want rapid suspention of user rights via LDAP, then you can keep the session open with periodic queries of the ...


2

but I was just wondering if there actually is a password for it? Yes. SSH uses your system users (that's the whole idea of it, to allow users to remotely access a systems account), so there is a password for it (stored in /etc/shadow) If there is one, is it possible to just disable it? Yes. You can (and should, as you are not using your password ...


2

Are there any sites which use this approach? This sounds very similar to Yahoo's on-demand passwords. Yahoo announced that in lieu of a standard username-password combination, Yahoo users in the US could log into their accounts with one-time passwords sent to their mobile phones via SMS message. Are there security issues with this approach? ...


2

Users authenticate with their phone number, get a pin text, and if it is correct, they get an access token. Phone numbers are PII, so you should be keeping them safe (encrypted?). Text messages are sent in the clear and are readable by smartphone applications, consider that. Also, are the pin numbers random or can they be deducted easily? Are they valid ...


2

The cat ~/.ssh/authorized_keys command shows you the authorized_keys file of the currently logged in user. When logged in as root, or using sudo, this will give you the authorized_keys file of the root user. The authorized_keys file, at least on Ubuntu, is usually owned by the user. So the currently logged in user (root or not) can see it. The .ssh ...


2

Create a private key with corresponding verifier for server. Rather than use a hash of a salt and password as in typical SRP, just use a random number (mod N) and not zero for the key value. In SRP implementations, the key is typically called "x", and then the verifier is g^x (mod N). SRP with a key of 0 is simply Diffie-Hellman. Now do an SRP login with ...


2

As always, the choice of the authentication scheme mainly depends on what you need to protect and the kind of public you will receive. As "I forgot my password" link mentioned in the comments is a good example. By the past, for certain non-important websites, I used such links on a systematic basis to open a session: Click on the "I forgot my password" ...


2

You are correct! This techniques is there to prevent your passwords from Shoulder Surfing. As you said, it allows a user to prove the knowledge of his password without, revealing it to the person who is shoulder surfing the user. There are many other proposed solutions to the problem of shoulder surfing, including some Graphical Password schemes. This ...


2

You should have session cookies. Most web frameworks have useful support for that. But from a security viewpoint, there is an important issue. Using session cookies (to identify remote clients) and login credentials effectively doubles the authentication functionality of your system. Thus a new attack possibility emerges, based on unexpected interactions ...


2

Use a Session Cookie to track users throughout the authentication process, just as you would after authentication. Make sure that your cookie's length and complexity are sufficient to withstand brute-force and spoofing attacks. Use the secure and httponly attributes to prevent the bad guys from capturing and using it. Use one cookie for ...


1

A couple of sites therefore allow you to log in with e.g. OpenID, Google or Facebook, thereby removing the need for separate credentials. Facebook has also introduced one-time login tokens ("passwords", OTP). Regarding SMS, remember that SMS are clear-text messages that are only protected if the link between your device and the cellular network provider ...


1

They're the same. Note that signature doesn't contain the data shown in grey - rather, it's a signature of that data.


1

A canary value chosen at compile-time is constant from run to run, across all copies of the program. This means an attacker can figure it out by analyzing the program; once they know it, they can set up their overflow attack so that the overflow over-writes the canary with the same value it had originally, making the attack undetectable. If the canary ...


1

Using OAUTH and 2 factor auth is the best way to go in my opinion. Your main account is protected and the other sites just serve up an authentication token to verify against. If the token becomes compromised the rest of your accounts are still safe, just the one token needs to get revoked. Also if youre not using 2fa and your password gets compromised you ...



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