Tag Info

Hot answers tagged

28

As Phil stated, you can still use the card using its number (as you would do on-line). Also, some ATM machine won't accept the card if not able to read the magnetic strip. The best thing is to use a credit card: in that case you can block the payment and get a refund.


25

There are two main arguments for enforcing requirements/restrictions on username choices. The first is that making usernames more difficult for attackers to predict helps resist online guessing attacks. While usernames aren't necessarily considered to be as secret as passwords they are one of at least two pieces of information that must be stolen to ...


23

Yes, you can. On some places you can find a device called demagnetizer. Just run your card over it (or over a very strong magnet), and the magnetic track will be corrupted and you will only be able to use the chip part of the card.


19

This behaviour is specified by RFC2617. The reason for the extra round trip is that the server can request different kinds of authentication: basic, digest, etc. If you know in advance that the server takes basic authentication, then as you say, you can save a round trip. But that isn't the default, and I think the .NET libraries are right to expose this as ...


19

Basic authentication has a number of drawbacks, one of which is that the username and password are passed in the clear with every request. This is clearly unsafe under HTTP, but is somewhat less vulnerable under HTTPS. However, because the credentials are submitted with every request, it's still worse than any other method (including digest) that does ...


14

Embossed letters are still present on CC to allow to quickly carbon-copy (literally) the card on paper. That's in the (very) old days, but still allowed today, and it will count as PRESENTIAL. Magnetic strip is still there because half of the CC readers still work that way. ATM and TPV outside USA and UE are still missing the chip reader, and even inside ...


12

"Biometrics" and "100% accuracy" are distracting the other people answering from the core question: "Are there any other benefits to MFA?" and that the answer is in fact Yes, there are other security benefits to MFA. You're 100% certain you can identify everyone connecting to your site. You correctly reject an attacker attempting to brute force their way ...


11

If you are 100% certain you can, with 100% confidence identify your wife based on her biometric data and that there is a 0% chance of someone spoofing her biometric data, then there will be no benefit to using multi-factor authentication. The problem comes in when the identifier, be it biometric data or username and password, can be leaked or spoofed. ...


11

In addition to the other points mentioned, another significant drawback to HTTP Basic Authentication (vs, say, forms-based login) is that it has no concept of "logging out". Once the user inputs their credentials, the browser stores them internally to send with every subsequent request. This means that you can't have a timeout or "Log out" button/link to end ...


10

YES, but there is a big chance that an (internally chip-capable) ATM (depending on region) will reject the card! The most common 2 problems for an ATM (including chip-capable) to reject a card are: a dirty or scratched magstripe (as shown in spork's answer) an erased or mangled (=invalid) magstripe by exposure to magnets or EMP (they need to emit ...


9

These user names requirement can cause user names to be less predictable. I don't think that this provides a substantial security improvement, but I can think of a couple of scenarios where they help a little. I doubt that it offsets the loss of usability, but I lack concrete evidence to conclude. As usual, security at the expense of usability, comes at the ...


8

Basic access authentication over HTTPS has clear advantages over Digest access authentication over HTTP. Even with digest access authentication, you can actually store your passwords hashed with an unique salt (realm + username), but first this salt is guessable (this makes attacks against single users and small groups easier), and second you can't use ...


7

I would consider a physical signature a biometric, albeit a pretty weak one. It isn't really something you have, since unlike a physical token, it cannot be stolen, or given to another (or, under most common circumstances, lost). It isn't really something you know either, even if an attacker knows exactly what your signature looks like, he cannot necessarily ...


7

Don't do this, it will not work in ATM machines in my experience. I've had to get a new debit card mailed in last month because there was a little scratch out of the magnetic strip, although I had not noticed and had used it for daily chip-only and wireless transactions. It wouldn't work in any (Dutch) ATM machine afterwards (I tried my own bank's and ...


6

The prime usage of signature is to signal intent. Properly verifying if some signature A 'matches' some signature B is something that requires a lengthy and costly expertise and generally isn't done outside of significant court cases, so in most cases it actually doesn't function as authentication factor at all. For example, when accepting credit cards at ...


5

This recommendation is most relevant on systems where multiple people can perform root-level operations. The Linux auditing daemon can distinguish "UID" and "effective UID", so user "bob" who does "sudo -i" and then performs a root-level operation will show up in audit logs as "user bob acting as user root". So, if you track changes to files in /etc, or ...


4

You should ensure that your session token is random and at least 128 bits. Aside from that you just basically send a session token and a user id. To be fair, only your session token should be needed to identify a user since it is unique. Ensure also that you destroy the session token after the user logs out. Aside from that it seems similar to any other ...


4

To make user IDs less predictable. To conform to other systems. The reasons for less predictable user IDs might be: An application limits a number of password guesses (a typical thing for internet banking) per a user ID. Then an attacker can mount an attack "try password 123456 for all known user IDs". If the attacker does not know the large amount of ...


4

Don't know if there is some study about it, or if this question will be closed as opinion based, but: In one online attack, you'll limit how much tries one can do for every x minutes, or even lock the account after x tries. So, a brute-force attack will have some limited impact. Anyway, a password probably will have more combinations than the code you'll ...


3

I agree that forcing a weird username will make breaking the account sligthly harder (as it works as a kind of second password) as opposed to having the same username as in the XYZ account whose password they are reusing. (But imposing some requirements also makes easier that the user forgets his own username!) The main reason I see for setting a minimum ...


3

Multi-factor authentication is an implementation of the principle "defense in depth". One particular authentication factor by itself is going to have its strengths and weaknesses against attack. So the goal of multi-factor authentication is that a second factor can compensate for the weaknesses of the first factor, and vice versa. In reality that goal ...


3

If you can come up with a single means of authentication that is absolutely fool proof (e.g. there is no way it can be hacked and it is always 100% accurate), then I don't see any additional benefit to multifactor authentication. However, in real life, I do not believe there is a system that is 100% accurate. For example, a person can steal a token, or ...


3

Cribbing from my previous answer... Authentication factors are 'something you know,' 'something you have', and 'something you are'. Something you know is something that you store in your brain. Passwords are the most common example, but it includes anything and everything that relies on your memory to know. You use your brain to remember your password. You ...


3

Protections are in place to combat risks. If the risks are low, then the protections can be low. Think about a forum site. There might be no reason for the site to use "strong protection", because all you really want to do is to be able to identify who is contributing. It could be determined that the site needs very weak protections in that case. The ...


3

Create a cryptographically secure random token and associate it with the user id in your DB Perform an HMAC on the token the cookie value will then be token+HMAC This way an attacker would have to know your HMAC key in order to brute force the token and that is not possible. For validating the cookie you first extract the HMAC, validate the authenticity ...


3

I don't think this is a security question. But anyway I think your person lied to you. Everyone knows the voice telling something like The person you have called is temporary not available. If a cellphone has no contact to the network or is switched of or the sim is not in the cellphone you get either this message or the mailbox.


3

In the ideal case, both can be entered at the same time, such as in the case of an an OTP generator. This way, you're testing the combination of the password and the OTP at the same time, without revealing which had the error, preventing an attacker from brute-force attacking either one in isolation. But you have to take practical concerns into ...


3

The first step in securing anything should be to evaluate what you need to secure and where somebody might attack you (attack surface). I don't know what you have to protect, but since you are doing your computing in the cloud you should not only ask yourself how to communicate with your cloud application, but how the application itself is secured, that is ...


3

This is a type of timing attack, leading to a username enumeration vulnerability. Whether this is a threat or not depends on the design of your system. If usernames are supposed to be private them it is a concern. Some systems are written in such as way that the enumeration of users fits into the design, such as email providers, as email addresses are ...


2

Pre-Snowden, I would have dismissed this question as being in the "tinfoil hat" category. Unfortunately, the NSA's pervasive misconduct (not to mention that of its "Five Eyes" junior partners, e.g. GCHQ, CSIS, and whatever the Australian and N.Z spook agencies are calling themselves these days), does indeed raise a troubling question. The specific ...



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