How to use password encryption function of magento at the time of login in admin panel using java-script so that nobody can see the real password in HTTP headers of different browser?
You cannot do this.
Usually attacks on web-sessions include active / man-in-the-middle attacks. That means that even if you send a secret or public key to the JavaScript in the browser that that key may be replaced by an attacker. So the best thing you can achieve in JavaScript is obfuscation.
What's missing is a trust framework (for now anyway, there are several crypto API's under development). As the certificates of the browser are not available to JavaScript, there is no good method to establish trust with the webserver. So in the end you cannot authenticate the other party.
This is why TLS is a strict requirement for any browser based security; TLS can make use of the certificates stored with the web-browser and it is therefore possible to know which server you are communicating with. The encryption and authentication of the data within TLS allows the password to be send in plain at the HTTP level in HTTPS.
Related
I am trying to understand the purpose(s) of client secrets. Is it to prevent someone from creating a fake server that pretends to be my server? If not, what is it? And does it protect against anything else?
The client secret is used to identify the application that requires an access token in order to access a resource on behalf of the user. Only clients registered in the authentication service can request access. Not only will user authentication be necessary, the client application must also be legitimate. Otherwise someone could impersonate the client application.
This type of client authorization should only be used by confidential clients ([OAuth2 Client Types][2]).
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
When using flows with clients that cannot guarantee the confidentiality of this secret (i.e. implicit), the identity of the client cannot be verified. In those cases it can be verified by means of the redirection URI. As an additional measure, it should limit the exposure of refresh tokens.
Officially it is no longer recommended to use the implicit flow for security reasons, the recommendation for this type of clients is Authorization Code + PKCE extension. [See OBBA document][1]
For authorizing users within a browser-based application, the best current practice is to
o Use the OAuth 2.0 authorization code flow with the PKCE
extension
o Require the OAuth 2.0 state parameter
o Recommend exact matching of redirect URIs, and require the
hostname of the redirect URI match the hostname of the URL the app
was served from
o Do not return access tokens in the front channel
[1]: https://datatracker.ietf.org/doc/html/draft-parecki-oauth-browser-based-apps-02)
[2]: https://www.rfc-editor.org/rfc/rfc6749#section-2.1
Sometimes you have some ApiResources which called by Clients and there is no any user in the flow. for example fetch instagram's post using instagram's api. now instagram wants to control client behavior so client should be authorized for instagram befor any api call. in this situation you need define some secret for each client to identify them.
This an example of client's secret usage.
I'm relatively new to this area of securing API. Most of my career was in developing internal products for the use of the organization, or joining a product that has already implemented security (which usually does not change)
When reading about JWT and Identity server, I understood the role of signing and the need to separate authorization and authentication. But, one thing strikes me as odd:
If my user is about to get a signed token and use it to authenticate himself, and there is a "Man in the middle", listening and copying that token, could he impersonate my user? (I believe the answer is yes)
So my best option here is to use SSL on every call to my API. The token being temporary and all is not much less of a threat to security.
So, my question here is:
If I end up using SSL on my API calls, what is the signing good for? with SSL the traffic is hidden anyway and no one could tamper with it. The browser can possibly use the username and password as plain text and they won't be exposed.
What am I missing here?
I think all boils down to what purpose JWT serves in OpenID Connect protocol (OIDC).
In OIDC, ID token is a JWT. And if you go through RFC7519 - JSON Web Token, then you come across Trust Decisions section.
The contents of a JWT cannot be relied upon in a trust decision
unless its contents have been cryptographically secured and bound to
the context necessary for the trust decision
From OIDC perspective, trust decision is to authenticate the end user based on claims contained in the ID token. This can be only done if validation adhere to JWT specification. So basically it is a requirement by OIDC protocol and JWT specification.
Now about SSL. OIDC contains several other calls required to obtain final token response. These calls contain client identifiers, secrets and authorization code (depending on the flow). OIDC is built on OAuth 2.0 and OAuth 2.0 mandate SSL (TLS being the new name). Thus OIDC too require SSL.
In combination, SSL (TLS) prevents attacks during request and responses flow in wire. And JWT's signature guarantee token's authenticity independent of how it was received or which component of your application process it.
I have ws working for sending user login details through a websocket. However I know that someone sniffing packets could capture the password, so I wanted to use wss instead. However I now understand, through playing around with my back end, that firstly a certificate is required for it to connect properly, and secondly, if i cause the self signed certificate warning to sho0w, afterwards the websockets will work with wss, but that is not good enoyugh for clients. From googling this issue, I have found that A self signed certificate will probalby not be good enough.
And all I want is to provide a user with a safe way to login.....
So anyway I am now thinking it would be better to avoid having to use wss all together. I could use a conventional servlet for login but that will probably require a certificate too for https and I don't want to have to start paying people loads of money for certificates when my business might not even be that successful.
I have been thinking about other ways I could send the users password securely. One way might be to generate a hash in the browser. I know I could use some king of challenge along with a salt sent to the browser but I am not exactly sure how to do this and how safe this would be. I have the conventional login working with a salt, generating a hash with AES. Any suggestions?
I just want the users login details to be safe and I don't want to go down the route of certificates, it's annoying and unreliable.
Login should always happen through HTTPS. Not only the POST sending the user and password, but also the GET getting the login form, so the client can be sure is getting the right form and that his information will be posted to the right place.
You can send login details either by HTTPS or WSS if you want security. If you use a self-signed certificate you will provide transport security, but as the certificate is not signed by a CA, the client cannot be sure that the server with which is interacting is the right one, and that is why the browser shows a warning.
So, if you want security for your clients, you should get a signed certificate and use it for HTTPS and WSS (you can get them from 10 bucks per year in some places). Anything that you do in the browser is insecure by default, starting by the user not having certainty of being interacting with the right server and not a spoofed one.
Found this blog helpful even though it's directed to the raspberry pi and python/nodejs. http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html
Good concepts on security and authentication. I would recommend ALWAYS using ssl and not rolling your own crypto.
I have an api deployed to Heroku. It is currently open for everyone to see. I only want known android phones to be able to modify and access the api.
I don't want the user to have to login every time they use the app.
Can I add some sort of certificate to the phone to verify that it is credible?
Is OAuth the best approach for this?
Is there a better way to do this so the user doesn't have to login every time?
This is a fairly broad question (and hence there are several approaches). Without knowing the language/framework you are using it's also hard to give specific advice, but:
Your server can issue a cookie or token that the client can store locally for a duration. These tokens should include a timestamp and be authenticated (use a library that does HMAC authentication) to prevent clients from modifying tokens.
Clients should present this token or cookie on each request to your server via a HTTP header or the standard Cookie header.
You will need a login system to support the initial issue of the token/cookie.
Clients could also OAuth against your server (complex) or against an external service (GitHub/Facebook/Google/Twitter), but you will still need a way to track that state on the client (hence a token/cookie).
Cookie support should be included with the standard Android HTTP client, and most server side frameworks have support (or a library for) authenticated cookies.
Is it good enough a protection if my site is serving on https with secure session cookie and redirects any attempts for http urls to https?
What kind of security holes can i be exposed in this setup to for which i cannot live without setting the HSTS header?
This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack.
The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.)
In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user.
The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.
Wikipedia has a fairly good discussion of this, which I think is somewhat clearer than the discussion in the RFC.