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
Related
I have received a request, and I cannot find a secure way to implement it. If you know a secure way to do this, please let me know.
I'm developing www.abcd.com with ASP.NET MVC. The client already has a xyz.abcd.com domain with an authentication system. They want me to create a page on www.abcd.com, where user can enter a username and password, then by hitting the login button, I open a xyz.abcd.com/login page in a new window and populate username and password with what the user has typed in my page.
I cannot find a way to do it from server-side.
If I want to do it on the client-side, I think it's against "same-origin policy" and also, I'm not sure running both www.abcd.com and xyz.abcd.com on SSL is secure enough to do such a thing.
Could you please let me know, if there is a secure solution?
I think the subdomain application (on xyz.abcd.com) should have explicit support for this to be possible, like for example populating its fields from request parameters or maybe a cookie (though I would rather not do that, especially not in case of the password).
If the subdomain application does not support this, I think you can't populate its fields, not even from abcd.com, let alone from another domain.
Please note that it would be a vulnerability (and against the best practice of course) to auto-populate the password field, which should even be set autocomplete="off" to prevent even the browser itself from filling it in.
Without knowing the context to these applications, I suspect you need some kind of a single sign-on to achieve your real goal.
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.
I am learning PHP, and I am obsessed with learning security. I know a few about some kind of attacks likes injections, session theft, etc., but I would like to code my own CMS with a perfect security (if possible).
Reading I drop on .htaccess security in directories. This is a good option because all my CMS files are in one directory. I just read this in a website:
HTAccess is the most secure method of password protection, as it relies on the Web server, so the valid usernames and passwords are never shared with the Web browser or stored in the HTML like they can be with other scripts.
Is this true? I mean, it is "unhackeable"? Of course with extra security (like hidding the .htaccess file).
If this is true, I mean, there is no way to hack a site with .htaccess security, how can I use a form (instead of the popup window) so I can log in my CMS? Is there a way to use a "Forgot Your Password" option?
Any help will be apreciated, as examples and links for reference.
HTAccess is the most secure method of password protection, as it
relies on the Web server, so the valid usernames and passwords are
never shared with the Web browser or stored in the HTML like they can
be with other scripts.
I'm a little scared of the person who wrote this sentence originally.
Usernames and passwords would never be shared with the web browser or stored "in the HTML" except in the cases of the most rank disregard for hygienic programming practices. That someone would even present that as an "option" as a straw man argument is troublesome. I recommend finding a better guide.
The htaccess mechanism for server security is also a bit of a misnomer. The .htaccess file in directories is really intended to be a mechanism for clients on shared hosting sites to have some degree of control over Apache configuration variables -- which is a complete non-starter for "totally secure CMS system" (as if such a thing were a possibility. :) You should expect to have complete and total control over your Apache configuration, including all authentication and authorization and access control mechanisms. The .htaccess files are re-loaded, re-parsed, and re-configure the server on every single request but the site-wide Apache configuration is loaded once, parsed once, and configures the server once.
The server-based mechanisms rely upon either HTTP basic authentication (which is roughly akin to shouting your user name and password in a crowded room) or HTTP digest authentication (which is significantly better and if your users pick good passwords, probably even vaguely safe). Tunneling either one through TLS would be wise. (Heck, if you really want "security", you might even go to the effort of using client certificates.)
Note that these mechanisms ask the browser to pop up a dialog box for authentication. If you want to integrate the username and password into your web page in a "beautiful" way, then you will need to do all the username and password authentication checks via a form submission, storing session information, and checking your internal security mechanisms to provide authorization whenever it is necessary. You will be responsible for everything. (And, again, TLS is the way to go.) The web server cannot help you at all. (And you further won't be sending usernames, passwords to the browser in HTML... sheesh. That still scares me.)
is this what your looking for? this will allow you to use a php form to login through htaccess
<?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo 'Text to send if user hits Cancel button';
exit;
} else {
echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>";
echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";
}
?>
reference
I'm building a Flex client against a Struts backend and I have to find a way to transmit the session token without relying on cookies, because I can't use cookies in a Flash movie.
I'm looking at putting the token in either the message body or the URL. Putting it in the URL has somewhat of a bad reputation, security-wise. However, I just read up on session hijacking, CSRF and XSS, and I couldn't really see why it should be worse than cookies. If anything, not having a cookie that is transparently sent along whenever you access a particular domain is more secure, or is it?
Basically, the only reason I can see is that the token is visible in the request and might be leaked via the browser history, a web server log etc. How bad is this really, and are there ways to mitigate risks? What other risks might there be?
How bad is this? Well, one of our competitors had a link from their internal (session based pages) to our site and I saw it on the server logs. Quick copy and paste with the /sess/sess_34984923_34423423/ type stuff and I was logged into their system with full access permissions of that user (luckily, they weren't an administrator and it wasn't anything "super secure" like a bank/email etc: but still).
Also, depending on how exactly you implement it, the full url (including the session token) could be cache by proxy servers and even by Google (if people use the Google toolbar).
The way I've done this Flash session interactivity is to send a session identifier in the Flash parameters (in the HTML) to the Flash which then sends it back to the server. I've found most browsers/Flash combinations also send the cookie which I further authenticate against.
I have an anecdote for you. I was filling out some paperwork for a well known company in the US. They printed out a confrontation page generated by a web application, how do I know? At the bottom of the page Window's print manager included the URL which had the JSSESSIONID.
Let me be clear, the employee just handed me a sheet of paper that would allow me to login immediately as if I had their username and password. DOAH!
I suggest you further read on a very severe security topic called Session Hijacking which allows a malicious attacker to impersonate to a user once he have his session id.
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.