Tag Info

Hot answers tagged

74

As you noted, the main three are: Something you know Something you have Something you are I'd argue that there are others: Something you can do, e.g. accurately reproducing a signature. Something you exhibit, e.g. a particular personality trait, or even neurological behaviour that could be read by an fMRI. These are not strictly "are" features, as ...


37

In the typical case, something you are and something you have can only be true for one person at a time. If you lose your token, you know you have lost it. Something you know can be copied by someone without your knowledge. If someone has your password, you may not be able to tell that they are actively exploiting that knowledge. That is one reason to ...


34

Burp Suite in proxy mode is able to decrypt HTTPS traffic of any systems which trust it. It does this by generating an own certificate and use this cert to register itself as a certificate authority on the system it is installed on. When it then proxies a request to a HTTPS webserver, it does the HTTPS handshake itself, decrypts the traffic, issues a ...


30

Absolutely! Somewhere you are is quite widely used in corporate IT. In many environments, if you are on an office network, you can login using only a password, but if you are out of the office you must use an additional factor, usually a token. The current time is arguably another authentication factor, a classic example being a time delay safe. Office ...


24

Passwords, or more generally something you know, are often relatively weak, because users cannot remember high-entropy secrets. As a result, passwords (or anything you need to memorize) usually ends up being a low-entropy secret, which enables random guessing, offline dictionary search, and other attacks. While it's possible to create and remember a pretty ...


22

Nope. There are three. All others mentioned here either: can be reduced to one of canonical three (e.g. "something you can do" is a personal feature, so classified as "something you are"; "someone you know" means you can present a proof of connection to someone - that's "something you have"!) are not part of authentication, but authorization (time, network ...


16

Security questions are an example of security theatre. You can consider them a very weak form of password at best, and they are often readily guessable. If you are going to use them, make sure they are ones that have the following characteristics: they have many possible answers (city names are terrible for this, especially in countries that have ...


9

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...


7

This is the result of the excellent marketing done by biometric authentication vendors. "Something you are" is sometime very easy for an attacker to reproduce, fingerprints and voice are especially easy to obtain, without the possibility for people to use credible strategies to avoid it (wearing gloves at all times and not speaking in public is not ...


6

Back in 2007 I wrote a whitepaper on how to evaluate security questions which you are welcome to read in full but I'll summarize my thoughts here. I applied five characteristics to evaluate security questions as authenticators, those being Usability Uniqueness Integrity Accuracy Affordability Affordability is pretty consistent across all security ...


6

The vulnerability is in the fact that the application enforces second-factor auth verification client-side. That is, the service itself does not require two-factor authentication, ever. But it is willing to process two-factor authentication if requested, and if the client app learns that account has two-factor enabled, then the app will attempt ...


5

It is possible to have a "something you know" which you cannot be forced to disclose. I read about a secure login system which presents a grid of 12 to 15 photos of faces, and you have about 3 seconds to touch the 3 or 4 that you have seen before. For this to work, there must be a database of many thousands of photos, and you train on hundreds of them. The ...


5

Well, it certainly doesn't make it more insecure. You still have your primary password, which we'll just assume is stored correctly. And in addition to this (I'm going to assume that you have to enter both, not one or the other; if that would be the case, this wouldn't be very secure, see the links @D.W. provided in the comments.), they have a secondary ...


4

The way I see it, even if it's random, it's just eight very, very, very low entropy passwords (1 character). Which will be super easy to break by brute force (as usual, we have to assume that attacker has the salts). Randomization of the challenge will be useless if the attacker knows the secondary password. But I think this will have additional security if ...


4

Usaually the user's browser stores some cookies with a random string identifying the user on the server. More secure variants of this additionally check other parameters as the browser version, OS of the user and approximate location. Basically, if you visit a webpage like facebook with a cookie, you get authenticated only with the random string in the ...


4

Could there be some miscommunication between you and the IT department head? As Xander had already pointed out, such a scheme does not work, and I would even add that it is ridiculous. In order to authenticate a user, a database lookup has to be performed on the login email address in order to retrieve the corresponding hash used for comparison: SELECT hash ...


3

The test you have: if (!username || !password) Checks if either username and password values are javascript falsey values. A falsey value in javascript is any one of these : null, undefined, 0, false, NaN or an empty string. An empty string in javascript is a zero length string so if it has at least one character in it (any character will suffice), then ...


3

While we assign authenticators into three common categories, it is important to keep in mind that these categories are somewhat loosely defined. Passwords are normally considered ‘what you know’ authenticators, but if you write it down and refer to the paper instead of memory does it become a ‘what you have’ factor? If a system authenticates using keyboard ...


3

This scheme is ok, but it's basically just a variant of a salted hash. These are generally considered old practice. Furthermore, this scheme is more complicated (more surface area for potential bugs) and relies upon multiple cryptographic algorithms being unbroken. Modern good practice is that passwords should be stored using a slow key derivation algorithm ...


3

Redirection the user after a successful login is common in the most webapps. For instance when the user try to access the dashboard directly within its url, the system keeps the requested url and brings the user to the login page, after user signed in he is redirected to the dashboard not the homepage or something.


2

This is a bit odd, usually the provider staff would have their own accounts with which to make changes to customer details. How it works isn't as important as providing: Accountability: all actions by staff accounts would be auditable (if it's implemented properly) Protection for customer accounts: the staff would not know customer login details Having ...


2

The two defences you list are meant to protect against two different attacks. Unique password for every login This is meant to protect against a leak of someone else's password database. Even if the attacker works out your password, it's useless as it only allows access to the single website the leak happened on (which you've probably changed by the ...


2

To the best of my knowledge the TeamViewer ID is provided by the TeamViewer servers. The attacker would have to emulate the entire TeamViewer protocol in order to spoof the ID. They would have to act as both the TeamViewer servers in the middle, as well as connecting client itself in order to make your system believe that it was a legitimate TeamViewer ...


2

Suppose I write you a check and you deposit it, but also produce a forgery that you deposit a few days later. Soon or late, when I reconcile my account, the forgery will be detected, I'll complain to my bank, and my bank will claw back the money from your account at Chase. Doesn't matter whether it's paper or a picture. If the forgery happens to overdraw ...


2

So the linked question How is Chase Mobile Deposit Secure? does answer this, just not explicitly. The important thing to remember for this specific scenario is that there is nothing magical about the piece of paper you're thinking of when you picture a check. Just because you get a nice little pre-printed pad of checks from your bank doesn't mean that ...


2

Why not just use an existing token-based authentication method like Kerberos and build off of it? So the user authenticates normally and receives a kerberos token. Then, you go to the API server, say "Hey I got this token!" The API server verifies it, and sends a copy of the encrypted data to the user, who can decrypt the keys on their machine? Seems ...


2

as the website service panopticlick puts it "How unique and trackable is your browser?" there are many things that especially via scripting can be found out about your machine. This uniqueness estimation can include browser type browser version geometrics (screen size) average cpu usage / calculation power via script trial fonts (are a especially neat way ...


2

This is called federated authentication. In the enterprise world, this is often accomplished with Kerberos (for non-web based systems) or SAML (for web-based systems.) In the non-enterprise world, far and away the most popular federation framework is OAuth 2.0. There is an extension to OAuth 2 called OpenID Connect (much different from the older OpenID ...


2

Your understanding is already pretty good. As you say, there are a variety of EAP protocols: LEAP, PEAP, EAP-FAST, EAP-TLS, etc. Each one works differently, but they all do the same thing: authenticate a user before allowing them access to a wireless network. You could call EAP a protocol, or you could call it a framework of protocols, where each variant ...


2

Probabilistic or statistical authentication are probably the best fit, the alternative to deterministic authentication. (Though technically, there's a degree of probability involved when password hashes are used, rather than plaintext passwords, let's just ignore that for now.) Biometric implies a probabilistic system, but the converse is not true, e.g. ...



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