Tag Info

New answers tagged

9

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


0

Some issues with contactless payments and digital wallets: Loss or theft -- an attacker gaining access to a device could allow access to the confidential information and allow continuous fraudulent transactions until accounts were disabled and/or fraud was caught. Pulling a SIM card could prevent even the most-stalwart lock and/or lockdown protections, and ...


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

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


1

Google Authenticator implements standard protocols such as TOTP (and maybe HOTP), they are not Google-specific nor depend on Google's servers, so using their PAM module isn't related to your Google account and doesn't need an online connection. If you're like me and don't trust Google you can use an independent PAM module and an independent authenticator ...


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


0

Security-wise, the two approaches sound like they are just as secure. They both authenticate both the resource owner and the client (using the names as they are defined by OAuth2, as you mixed that up a bit). However, the big difference is, that the OAuth2 protocol standardizes how to do this. This has some advantages: It is always better to use a known ...


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


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


0

The other answers already explain the security of GSM and the technologies involved against technical attacks. However, there are a number of other attacks which bypass the technical protections. The German Wikipedia article on transaction authentication numbers (which are often sent by SMS) lists some attacks: stealing or stealthily access the victim's ...


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


0

My simple recommendation, and what I have done to mitigate DoS attacks on slow password hashing, is to use a password strength calculation score as primary validation method. So for a user login example: I get the user record by email. Then first check if the strength score match against the plain text password (which is obviously fast, just a couple ...


0

Just a minor correction to what northox said: remote attestation uses an AIK, and is what you need. You can get a properly-certified AIK using either a Privacy CA or DAA, depending on what you have available. However, for this kind of use, you might not actually need the AIK certificate: if you have physical access (or an equivalently secure channel) to the ...


1

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


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


0

I don't think you want to lockout a user this way, you want to lockout the endpoint. There are two reasons that you would do this: Firstly if a user is trying to login at the same time his account is hacked he would be unaffected since he is not logging in from the same endpoint, secondly the attacker may not be just targeting one account so this will lock ...


0

So after a bit of digging I came across a commit on GitHub that can do this. I uncommented virtual_server = check-eap-tls in eap.conf Then create check-eap-tls in sites-available and symlinked it to sites-enabled: server check-eap-tls { authorize { if ("%{TLS-Client-Cert-Common-Name}" =~ /^[A-z.]*@example\.com$/) { update config { ...


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


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


0

I didn't implement such a system. But I can still answer your questions (I hope). A different password for each application is a nice feature to enhance security, so that a broken password won't immediatly give you access to all apps. The problem with logging in with a different password for each application is the amount of passwords. Google has like 10 ...


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


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


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


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


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


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


1

You are saying that the private key cannot be decrypted server-side for authentication (because then the server would need the password), and it also cannot be sent to anybody requesting it, and then decrypted client-side (because then the private key would be vulnerable to an offline brute force attack). Basically, what's left is to design a completely ...


1

You can deal with your password problem with some variation of challenge-response authentication: done properly, it prevents replay attacks, and since the password itself is never sent, a hostile server or man-in-the-middle can't trick you into revealing it. The problem you're going to run into is verifying you're connecting to the server you think you are. ...


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


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


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


1

I have seen this used by many provides as a way to do Home Realm Discovery, when many IDPs are involved. When a user types their email address in, the next screen will be the IDP or in case of many possible choices, a selection list, followed by a redirection. Another possibility is that this technique confuses password managers, or built in chrome ...


1

I suspect this hasn't been done for a genuine security reason, instead these two scenarios might explain it: This is simply an artefact of how the system was developed rather than something they'd necessarily reimplement if they were building the system again today. It has been suggested in previous answers that banks like to make their authentication ...


8

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


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


1

The problem I see is that while you're going to a lot of effort to avoid transmitting the users password, saltedSecret has essentially become a password. The main threat to a transmitted password is that a man-in-the-middle (MITM) will be able to observe it (in the absence of any other forms of encryption) and log into your system. If we look at how a ...


1

Your cell phone carrier will likely have the capability to do this for you. However for privacy reasons (silly I know) they may be reluctant to share the source number with you. However you may be able to ask them to permanently block that number from contacting you. In addition if what is being sent to you possibly violates the law, of course you should ...


1

My preferred method is SSHFS. Your NAS server runs a SSH server which you then connect to from your remote machine. Leveraging SSHFS it will mount a drive on your remote machine via SSH (secure, encrypted) from the server you specify. I've not used the windows client version so YMMV. ...


0

telegram probably will use features that are built in a mobile phone operating system to keep those cryptographic keys, for example Android key Store or Apple's Keychain. these key store mechanism will in turn utilising the hardware provided by mobile phone to prevent key extraction.


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


1

Any mechanism you come up with, that does not involve the user entering a secret for every request will be vulnerable to XSS. The solution is to try and eliminate XSS from your domain, not to have a solution that is secure in the presence of XSS vulnerabilities. A strong CSP policy will help you in browsers that support it. Javascript can access ...


0

Instead of using a hardcoded key, you should use mutual SSL authentication. Using an obfuscated key, doesn't add any security, certainly not when you're already using SSL.


3

A JWT token consists of a base64 encoded string containing header, claims and signature. The claims section contains a JSON encoded expiration field, exp: Expiration time. It contains the UTC Unix time after which you should no longer accept this token. It should be after the issued-at time. The username can also be stored in the claims object. ...


2

The difference between the two keys is that the Master key (PMK) is supposed to be valid for at least as long as the client is connected. In the case of WPA-PSK, the PMK is the same from the moment the AP is configured until either the passphrase or the SSID changes. Therefore, if the PMK is compromised in any way, the attacker gains "permanent" access to ...


1

Here's a little drawing: And the study that support it.


2

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password (passwd -de). That way users get prompted on their first login and can choose their own passwords. I ...


0

Comodo, which was involved in this fiasco, trusts the following email addresses for domain verification: admin@ administrator@ postmaster@ hostmaster@ webmaster@



Top 50 recent answers are included