I have 2 servers. One with mail (server:webmail.test.com, path: mailErmo.nsf). And another with xpage (server: xpage.example.com, path:testXpage.xsp).
Im trying to open webmail in iframe or in new tab from xpages. Username and password are the same on both pages.
Edit:
I need to reenter username/password. Want xpage to do this for me.
This really isn't an XPages question. Its more of a server question. What you want to set up is single sign on for multiple servers. Once you authenticate against server #1 you will receive a token / cookie that will allow you to be authenticated against server #2 as well.
Now, granted, you actually can send credentials to the server to authenticate the user fro them, but it is bad design, as you would have to get / store the password (even if you are just storing in ram) which is insecure.
Use the pre-defined methods given to you by domino to accomplish (multiple server SSO).
Related
I have a web application (let's just refer to its address as 'xyz.com' for security purposes) that I want to be accessible only to users of a WordPress website. In the WP site, the logged in user can click a button that opens 'xyz.com' in a seperate tab. xyz.com is a Node.js application, created via MeteorJS, so it has both a client side and script and a server side script, but no PHP.
I want to make it so that accessing xyz.com will be denied, or at least limited, if the user directly goes to it without first logging in through the Wordpress site and accessing it via the button. I'm trying to figure out a relatively secure way to do this. I would also like to be able to distinguish between each username, as this is needed for a feature in the application.
The method I was considering is to place the button in a form that gets the current logged in Username, then send the username through $_POST data when you click the link, which then checks to see if there is a username in the $_POST data (via XMLHttpRequest or something similar), and what the name is.
However, I'm not sure how secure that would be, as the code is mostly client side, meaning couldn't someone look at the code and determine that they simply need to send a username through a $_POST data form? Is there a way to authenticate that the data is coming from the Wordpress site? Am I just overthinking this and this is an unlikely scenario for a simple website to be attacked like such?
All,
I'm currently designing a user account system in ASP classic...don't judge, it's what I'm comfortable with ;). I have several of the components built already, including the UI, database table, CRUD database ASP pages and a generic mailer. I'm curious as to some of the best practices for implementing secure login systems for ASP. Searching the web yields a ton of "simple ASP security" solutions, which I've used before, but this is my first time time building a robust and truly secure solution. The final implementation will be used for a job application system, so it definitely needs to be secure due to the content.
So far, I have:
Password recovery/reset goes only to the e-mail account on file
Hash stored passwords in the database
Do not set an expiration on session cookies so they are only stored in memory (read this somewhere today)
Get a certificate for the server and use https
A couple general questions that I have...
Submitting the password in a form passes it through the query string. Do I need to hash this somehow prior to submitting the form?
On a related note... If I am using https, since it is already secure, can I do the hash on the ASP page that handles the write to the database? I'm using AJAX to parse the query string from the sending form and pass it to the ASP page which connects to the database and does the CRUD operations.
Password recovery/reset goes only to the e-mail account on file
Make sure your send a reset link expires after a certain time or after it has been used whichever comes first
Hash stored passwords in the database
Use salts instead of plain hashes. Hashes of most common passwords are as simple to break as a google search.
Do not set an expiration on session cookies so they are only stored in
memory (read this somewhere today)
This will make sure that the cookies are wiped out when the user closes the browser. In addition to this, also consider a timeout on the session cookie on the server side which will timeout the user session after x minutes of inactivity.
Get a certificate for the server and use https
At the minimum, the login credentials absolutely need to be passed over SSL. It will also help to have the entire website on https instead of just the login page. SSL is no longer computationally expensive anymore. Having the entire site over SSL prevents any sslstrip attacks. Make sure your server doesn't support SSLv3 to prevent the recent poodle attack.
Submitting the password in a form passes it through the query string.
Do I need to hash this somehow prior to submitting the form?
Please don't pass credentials over querystring. Login form should always be POSTed. It'll get cached in server logs (and any proxy logs) if tacked to the URL as a querystring.
If you are posting the form over https (which you absolutely should), you do not need to hash before submitting the form. If you are not using https, there is no way to pass the credentials to server securely.
On a related note... If I am using https, since it is already secure,
can I do the hash on the ASP page that handles the write to the
database? I'm using AJAX to parse the query string from the sending
form and pass it to the ASP page which connects to the database and
does the CRUD operations.
Hashing should ALWAYS be done on the server side. If you hash the password on the client side and send it in plain text over http, a MITM might not be able to reverse the password from the hash, but he can always use the same hash to log on to the user's account. The hash essentially becomes the plain text password of the user in this case.
Always use HTTP POST with SSL for sure.
Protect your asp code against sql injections.
Storing a local cookie with an encrypted token to keep your users logged in after they close the session/browser - or use asp sessions for a single login that could expire in 20 minutes after last request or when closing the browser.
Protect your cookies for cookie/session hijacking. (http://en.wikipedia.org/wiki/Session_hijacking)
Also, you can use finger prints of your users by requesting/storing/validating the server variables like (a part of) the user agent.
I am developing a small website with a custom admin page that allow to simply modify and insert contents.
This is how it works: in domain.com/admin there is a page with an autentication form. Of course the only user that know the password is the admin (not me, my client). If the password is right, server send an html page that allow to modify the content of the website. How? Dynamic information are stored in a mongodb database setted up on localhost of server. So, using simple CRUD operation like insert, update and remove, the content of the website will change. In the clientside i simply do same "post" requests to the server, wich makes CRUD operations.
I need to make this system safe. Do i need https for autentication? Do you think that a simple autentication password for admin would be enougth? And what about the way i check if the passwords matches? I was thinking to store the admin password in the database (that have a password too) but maybe is unuseful. i could simply compare two strings cause the password is only one, there are no other registered users different by admin. But i'm not sure, this seems unsafe :D Any idea for the best way to do it??
I'm using node js (NO express). I have a dedicated root VPS.
https will be better, and you can just keep the salt and hash code in database instead of keeping the password directly. likely most of website have a feature to reset password not find the password, they don't keep password directly in file. when someone know the salt and hash code , they can't reverse the password.
My experience is that using .htAccess to password protect a directory, it brings up a modal dialog box. And for some browsers (FF and Chrome) don't show the checkbox for "remember" this password.
Is there a way to that a password protect a directory and have the user fill in the username and password within the web page?
Or, is there a way to force the browser to remember that password?
tl;dr: No.
We are talking about something called Basic Authentication.
Unfortunately, these things are features of the browser, and cannot be controlled from the server side. Some browsers have the ability to remember your password forever (usually in the form of a "remember my password" checkbox). It is debatable whether this is a good idea, but at least the user makes the call; forcing this choice from the server side is really a bad idea and I don't think any browser would allow that. Why? The user probably don't want to store his credentials if using a shared device (for example, in a public library).
That said, using an Apache .htaccess file is not the only way to do basic authentication. Using any dinamic content framework (PHP, ASP, etc), you can store a session cookie after the user has authenticated and only send the 401 response and basic authentication headers if the user has no authentication cookie. Since you talk about .htaccess, I assume you are on a LAMP stack; take a look at:
Basic authentication: http://php.net/manual/en/features.http-auth.php
Sessions: http://www.php.net/manual/en/book.session.php
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.