203

A private URL is somewhat weaker than authentication with credentials, even if the bit size of the URL is the same as that of the credentials. The reason is the URL may more easily "leak". It is cached in the browser, logged on the server and so on. If you have outbound links, the private URL may show up in the referrer header on other sites. (It can also be ...


91

First, I don't think it's realistic to expect users to have JavaScript disabled on the modern web. So let's take a look at what Panopticlick can gather through JavaScript alone, along with the uniqueness score of my particular browser: User Agent (1 in 4,184) HTTP_ACCEPT Headers (1 in 14) Browser Plugin Details (1 in 1.8 million) Time Zone (1 in 24) Screen ...


48

Note: A lot of people seem to be confusing a "private" URL with authentication. Also, there seems to be some confusion that sending the link via a trusted entity is an attempt at two-factor authentication. To be clear, we're talking about a publicly accessible resource, albeit one that is sufficiently hard to guess. When using a private URL, you should ...


37

I agree that the naming of the different concepts is confusing. When talking about authentication in a web context, there are several aspects to consider. What information does the client send when authenticating? A session id. This means that the server has a session storage which contains the active sessions. Sessions are stateful on the server side. A ...


32

Never trust anything. Every request is an attack. Every user is a hacker. If you develop with this mindset, your application will be much more secure, stable, and less likely to be hijacked by a malicious user. All it takes is one clever person to find a way around your security for you to be in serious trouble with your data (one of your most valuable ...


28

You choose not to encrypt the payload for the same reasons that you choose not to encrypt anything else: the cost (however small it is) exceeds the benefit, and a lot of data simply doesn't need to be secured that way. What you mostly need protection against is people tampering with the data so that the wrong record gets updated, or someone's checking ...


22

This sounds like a case of authentication versus authorization. JWTs are cryptographically signed claims about the originator of a request. A JWT might contain claims like "This request is for user X" and "User X has an administrator roles". Obtaining and providing this proof through passwords, signatures, and TLS is the domain of authentication - proving ...


20

Using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header. From http://tools.ietf.org/html/rfc7235#section-4.2 : The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) ...


17

So as Telastyn commented I added symlinks in WSLs ~/.ssh/ to the id_rsa and id_rsa.pub using: > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa > ln -s /mnt/c/Users/MyName/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub Using the same technique to instead link the symlink directory as suggested by tripleee, I had issues until I saw that the trailing slashes I ...


16

Your API session is a thing which should not exist in a RESTful world at all. RESTful operations are supposed to be stateless, session contains state and thus has no place in a RESTful world. The JWT should be your only way to determine whether a user is still eligible to access an endpoint or not. A session should play absolutely no role in it. If it does, ...


14

It sounds like there are two goals: Easy for end-users to authenticate with their existing social accounts Easy for developers using your webservice Authorizing people to use resources on your site makes OAuth2 a preferred mechanism due to the popularity and availability of client libraries. 1. Easy for end-users to authenticate with their existing ...


14

Using another word for "Authorization" or "Authentication" isn't helpful for writing documentation. Even though they're obscure, these two are already the most common words for those things, and any one-word synonym will make your text even less understandable. Instead you should use phrases to express the same meaning. Authentication means proving to the ...


13

if you are going to allow your users to change an email address you need to verify the new email address and send a notification to the old email address. The verification of the new email is more optional, but since you verified the original address not validating the new is an inconsistency, that can turn known good information into potentially useless ...


13

You pass username/password to the login method of your RESTful API and it returns access-token. That access token is just some unique (for the system) string. Device stores (persists) that access-token. Each time you send RESTful request to the server you put that access-token in header of HTTP request. Server finds the user by access-token and on success ...


13

Authentication and authorization are always good topics I will try to explain to you how we deal with authorizations in the current multi-tenant service that I am working. The authentication and authorization are token based, using the JSON Web Token open standard. The service exposes a REST API that any kind of client (web, mobile, and desktop applications)...


12

HTTPS (SSL) isn't user authentication FYI. It just provides encryption between 2 endpoints. But yes, there is a teeny tiny bit of overhead from it (though not enough to warrant a change in plans/hardware). See here : https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose


12

To summarize: You have an API key issued to you by a vendor so you can use their API, and you have an obligation to prevent this key from being known by anyone else You are making calls to that vendor's API (which require the API key) in your application code You are deploying the application to systems where customers have access to the binaries and thus ...


11

Browser fingerprinting relies on a very heterogeneous browser/device-ecosystem. One thing to consider is that we are moving towards a more and more homogenous ecosystem as more and more surfing is done on smartphones and tablets/pads which tend to be a lot less fragmented in this sense. IPhones/iPads will for instance all look essentially identical.


11

First of all, try to understand how SSL (HTTPS) and HTTP authentication works. The usual HTTP authentication methods (Digest, Basic, and any forms+cookie based authentication scheme you can implement on top of HTTP) are all insecure by themselves, because they send authentication information more or less in clear text. Whether the data is in POST fields or ...


11

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web ...


10

Is browser fingerprinting a sufficient method for uniquely identifying anonymous users? No, at best it can uniquely identity a Computer. There is no way it can differentiate between 2 new (and like) computers on the same network (Same IP) with out a cookie\session. What if you incorporate biometric data like mouse gestures or typing patterns? This ...


10

In general, no. SMTP is a protocol with a fixed set of information that can be exchanged, and "How long has this address been active?" is not among that information. (In fact, due to the continuing battle between mail infrastructure providers and spammers, it is getting progressively harder to get reliable answers to the much simpler question "Is this ...


10

The task as stated is impossible. You might be able to come acceptably close depending upon your ability to compel evidence (ssn, drivers license, birthdate, etc). But unless you're a govermental site, most people will just go elsewhere.


10

What my concern is someone can figure out the API, and start hitting with different combination of OTPs for mobile number and gain the access to an account This is a frequent question related to the security of web applications. Once our APIs are public, they are exposed to all sort of malice. Besides the https, which should be mandatory, here some ...


10

If you use Authorization, be consistent Some will argue that the following is unnecessary (and not too long ago I would have agreed with them) but, these days, if we use the Authorization header we should inform the type of the token, because API keys are not self-descriptive per se 1. Why do I think it's necessary and why I do think it's important? ...


9

While I really wanted to answer issue by issue, I think I'll hit this topic by topic: Authorization/Authentication OK, first things first. For your example, you need both: Authentication - proof that the user is who he says he is. You've choosen PKI, with the implied proof of private key as your authentication. Authorization - connection of the user ...


9

I've been trying to address a similar issue. My users need to be authenticated for every request they make. I've been focusing on getting the users authenticated at least once by the backend app (validation of the JWT token), but after that, I decided I shouldn't need the backend anymore. I chose to avoid requiring any Nginx plugin that is not included by ...


9

Yes. Asp.Net Membership is a bit outdated. Asp.Net Identity was introduced a few years ago to help solve some of the pain points with the older system. It supports third party OAuth through Google (and custom OAuth providers), 2 factor authentication, and easily extending the default schema via Entity Framework code first. It's really quite nice out of the ...


9

Yes, anyone can easily find the key. The simplest method would be to use the .net development tools (available for free download from Microsoft) which contains a decompiler. Aim the decompiler at the program and look for any strings, not to many will look like keys... If that fails because you were a smart cookie and encrypted the key. They could still ...


8

The problem is called "identification". The token uniquely identifies a person and you want to prevent people from obtaining multiple identities. The best solution we have for that are government passports and ID cards, or rather the methods used to distribute them, which mostly rely on cross-checking public records, especially birth records. But it's ...


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