3
Well, above all, in addition to the issue I will raise here, I would also like to raise a debate, the security standards for system authentication are not insufficient?
Context of the problem: I need to implement a user authentication system using Oauth and Bearer Authentication for the requests. Obviously, for user convenience, it won’t be pleasant to require a login screen for each request.
Problem:
Main impediment: Client does not use HTTPS protocol (as well as 40% of Brazilian domains, against 8% of the world rate)
In all the studies I’ve done on implementations and standards I’ve come to the following conclusions:
Never rely on any data that comes from the customer’s application (what is on the customer’s machine, gives full power of change by the customer)
UTILIZE HTTPS, is the only way to ensure safety in the transport of the request, even if it is intercepted by a "man-in-the-Middle"
Maximum care with all credentials
Well, as one of the client’s demands is that the user does not have to constantly send his credentials to the system, which is obvious, I started looking into ways of persistence of credentials. Next to the customer we have:
- webStorage (localStorage and sessionStorage)
- cookie
Main vulnerability involved in these forms of storage:
Script injection attack (XSS):
Allows the attacker to gain access to data stored by a domain in the browser
Example of JS that would get all localStorage keys for later
iteration on them to get the values:Object.entries(localStorage)So you can forge the headers of a request with the user’s token, passing through it.
man-in-the-Middle: Attacker intercepting requests while transporting them.
Solutions I found for these types of vulnerabilities: Cookies have two flags: httpOnly and Secure. httpOnly prevents the cookie from being accessed by any script next to the user, while it is accessible on the server. As if it did not exist for the user (Note: a differentiation of cookies from other storage methods is that they are sent to the server in any request of the domain that has cookies). Cure allows cookies to be sent only for HTTPS requests.
Given the limitations I have with my client (he only uses http), I am somewhat restricted to solutions, so I started working on the basic concept of security, to minimize the vulnerabilities. Well, as the Bearer Authentication standard is sent by the request header, I felt limited to realizing the only possibility that allowed me to see how secure implementation within my limits (cookies with httpOnly).
Implementation that I thought: Keep the token under double layer security. In addition to standard encryption to prevent user credentials from being exposed, pass "another layer" of encryption over it. The key of the second layer would be stored in a cookie with the httpOnly flag. The token would be stored in the localStorage, with this double layer. In any request the token would be inserted in the header and then on the server would be decoded with the key of the first layer that is in the cookie and would be generated through user information, and then the default decryption performed with the server key so that authentication is performed. I didn’t find any similar implementation, I believe it would solve the vulnerability problem for XSS but I have doubts about possible vulnerabilities and "default breaks". That would be the biggest doubt of the question
(Even if an XSS attack obtains the credentials stored in the localStorage, sending them without the key that is in the cookie that can only be accessed on the server, there would be no way to perform the actual authentication)
Now to conclude, just one vent: In the "client-side Storage" vulnerabilities research, I have always found several articles written by security experts and researchers who claimed to be completely unwise to store credentials with the user, but in none of them was presented a suggestion of alternative, while all implementations I found were made with these vulnerabilities.
And finally, a question that keeps going through my head:
The standards of storing and sending credentials through the headers of the requests is no longer somewhat old-fashioned?
I liked the +1 question, but when I stop to think about the title of your question it doesn’t seem to refer to your question itself. If I were to analyze the title of your question with the problem you are facing I would answer: "The security standards are sufficient, but if your client does not want/can use them is another story". Anyway, I’m no expert on web security, but once you don’t have a secure connection you can’t guarantee your client the security he seems to want. Otherwise, I’ll follow the discussion =D
– fernandosavio
@fernandosavio o Mega uses http by default in synchronism, and this does not hinder security at all, for the simple fact that it exists in another layer instead of in the "connection". I see unsubstantiated relationships in the post (and so far have not found the core of the question). It runs away from our scope a little, for more than one problem (in the sense of "non-conformity", not depreciation). Breadth and lack of specifics is kind of obvious, but it has a component of personal opinion, in addition to the lack of objectivity required by the site profile. Discussion works in forum, not here.
– Bacco
Really @Bacco , was reading the RFC 6749 which defines Oauth 2.0 and they advise TLS but there is no obligation. I hadn’t thought about the Mega case and it makes total sense anyway, but I wonder how easily this level of security is applicable or if I would have to have a whole team specialized to be able to implement in my projects. PS: I also think you have problems with the questions, but I liked the theme and discussion that it can provide
– fernandosavio
In any case, if one understands differently from this, one can take the question to the [goal] so the community can present the views and evaluate the situation more widely. One possibility would be to dismember the question in the specific subjects, and to treat each part separately, but always with the care to enable a quick understanding of the doubt and be capable of correct technical answer, independent of complex discussions or personal interpretations.
– Bacco
"Discussion works in forum, not here", OK the closing is fair. We are waiting for the issue of the question then...
– fernandosavio
Now I am in a difficult situation to edit the question, soon I realize, but already in advance, it is about issues of vulnerabilities and breaks of standard in the alternative approach that I adopted (above the sentence in bold)
– motorola
Let it be clear that I find the question valid and interesting the subject, but the format Q&A (or P&R - question and answer) we use is specific Bems, and has some formalities. In particular, objectivity and a question-only subject are fundamental. And don’t forget that you have the network chat, if you want to make a prior issue with colleagues before reformulating the post (in office hours has more movement) - there is much less binding the scope, you can talk about a lot of things.
– Bacco