202

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


60

This is a really good example of insecure authentication, justified on the basis that if the site is compromised it is not possible to identify the person. If that's the case, why do we even need a username? just give each student a secret access code. Here are some of the flaws: Scale of breach - The entire site will become compromised by someone ...


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


38

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


30

"Never store passwords in plain text" is not a rule. It is a best practice based on common security breaches on naive implementations of password protections. In that sense, the question: Is this scenario an exception to the rule of never storing passwords in plain text? really has no answer in the sense that no one is enforcing anything. All we can ...


29

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


19

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


16

Be consistent Some may say this is unnecessary (and not too long ago I would have agreed) but these days, with so many auth protocols, if we use the Authorization header to pass an API key, worth informing the type too because API keys are not self-descriptive per se 1. Why do I think it worth it? Because nowadays supporting different authentication or/and ...


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

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


14

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


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


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


12

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


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

Based on the new build "Insider Build 17063" permissions for files works differently now. In short you need to do: sudo umount /mnt/c sudo mount -t drvfs C: /mnt/c -o metadata This will make permissions for your ssh folder work as you need. Then procced as OP suggests in his answer. Relevant links: https://github.com/Microsoft/WSL/issues/3181 https://...


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

In Short: No If you forget your password, you ask the professor, who can look it up I see no real reason in the question to ignore the secure authentification guidelines here. Many (too many) people think that breaches only happen to others and that "it's allright for me, no need to secure things to this point", but unfortunately it's not the case. This ...


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

These are intended for scenarios where you have a token issuing authority that is not the same as the application that is the intended recipient. This may not be different for your application. But consider a large scaled application. You might have an OAuth or SSO server that's issuing the certificates, and an application that wants a token that shows the ...


9

The short answer is no. There should not be any problem because email is a valid and registered public claim. I have a user DB where each user's unique ID is their email ... Well, there's a protected claim for users' ID. The claim sub. 4.1.2. "sub" (Subject) Claim The "sub" (subject) claim identifies the principal that is the subject of the JWT....


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