I am trying to access my drupal site and an authentication requirement pops up. It asks for a username and password and i don't have any login credentials associated with the site
When i try to cancel it displays a 401 authentication error
It seems your document root is password protected , you can find .htpasswd file your server, may be in your document root. remove that file also check your .htaccess file and update accordingly. thanks
That password protection is not part of the site it self, but provided by apache web server. It's mostly used for protecting staging servers, i.e. from search engines trying to index the pages. Basically in your site root you have ".htaccess" file which defines settings for apache server. Some of those settings are related to password protection and they should look like:
AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /path/to/.htpasswd
Require valid-user
This code defines authentication and "AuthUserFile" parameter defines path to file where your pair of username/password is stored. Password is not plain text but it's encrypted (you have free online tools for encrypting htpasswd passwords).
So, you can see username in that ".htpasswd" file but you can't see the real password and if you want to keep using this protection and can't get the password from other sources you must generate new one to replace old one.
But if you just want to remove this password protection edit .htaccess file and remove this code related to authentication.
You have nice explanation including path to password encryption online service here:
http://www.htaccesstools.com/articles/password-protection/
Related
Is there anyway that we can give security measures for nifi, like any username and password for the nifi UI page. And also anyway to give storage for the configuration made in the NIFI UI page.
Need some suggestion on this issue.
All user authentication and authorization mechanisms are only available once TLS is enabled. This was an intentional design decision because entering sensitive user credentials over a plaintext HTTP connection is unsafe and exposes the user to many opportunities to have those credentials, which unfortunately they may reuse for other services, stolen.
After enabling TLS for the NiFi application, LDAP, Kerberos, OpenID Connect, Knox, and client certificates are all available as authentication mechanisms.
With the default settings you can point a web browser at
https://127.0.0.1:8443/nifi
The default installation generates a random username and password, writing the generated values to the application log. The application log is located in logs/nifi-app.log under the installation directory. The log file will contain lines with Generated Username [USERNAME] and Generated Password [PASSWORD] indicating the credentials needed for access. Search the application log for those lines and record the generated values in a secure location.
The following command can be used to change the username and password:
$ ./bin/nifi.sh set-single-user-credentials <username> <password>
I'm working on a web portal where a user is authenticated by LDAP through a perl CGI form. The authentication process uses the Net::LDAPS module. When logged in, the system keeps the user's authenticated status and creates a CGI cookie and the user can perform various actions through the portal, mostly interactions with a database, until the user logs out.
On the same server there's a directory with some files. I want a user to be able to log in to the web portal and then browse the file directory and be able to download those files.
The simplest way I can think of is placing an htaccess file with "Options +Indexes" and ldap authentication into the directory, but that would require another login that's not linked with the web portal.
Is there a way to link the web portal cgi-based ldap authentication to htaccess file?
You mention that the user can log out and then no longer use the portal. But there is no portable way for logging out a user with basic authentication. They will be able to continue browsing the directories.
Instead of your CGI script that authenticates the user, you can simply configure LDAP authentication for both the data directories and the portal. Ugly, but it would work.
The better and cleaner option for you will be to provide access to the data directories not directly but through the portal only. If you use Apache's path info feature (https://httpd.apache.org/docs/2.4/de/mod/core.html#acceptpathinfo) you don't even have to bother about checking the path for malicious "../../.." constructs and the URIs will look very natural to your users.
I have a web app set up with Microsoft Azure. Right now, I'm using FTP to copy files to the server.
My question is, given that the FTP password is a very short randomly generated string (that I don't seem to be able to change) and the username is literally the name of my website, how secure is this method of deployment?
Would it be possible for someone to brute force the password and wreck havoc on my server?
You can use user or site credentials to access FTP, as explained here.
But your statement "the FTP password is a very short randomly generated string" is incorrect.
If you use user credentials, you choose the password and it can be anything you want,
If you use site credentials, the generated password is extremely long, and looks like TbxwnfdldajYrmNyKNB2Amz8cqxaK19mihKMNtY3dxMPgxK8xl2HLxRkZpDt
Also, you should use FTPS instead of FTP. Both are supported and FTPS is more secure.
Bottom line, there shouldn't be any issue here.
When I use the appcmd list appool <ApplicationPoolName> /text:* command, it shows me the application pool identity passwords in clear text. I am able to view the passwords in clear text using Get-WMIObject in PowerShell as well. This can be a serious security threat as a user with correct access credentials can easily view the passwords.
The Application Pool in IIS (v7.5) is configured using domain user account/password. In the applicationHost.config file, the password is encrypted using IISWASOnlyAesProvider encryption provider. Still, the password is shown in clear-text when I use any of the above two methods.
Is there any way to encrypt passwords in such a way that they are not shown in clear-text when I use the above two methods?
Unless something has changed, the answer is no. The principal is best stated by Raymond Chen:
'It's like saying that somebody's home windows are insecure because a burglar could get into the house by merely unlocking and opening the windows from the inside. (But if the burglar has to get inside in order to unlock the windows...)'.
The point in summary, is that anyone that can get to your IIS server or can execute a WMI command remotely against your server, or can execute a powershell command against your server has access.
They are assumed to be admins, and are assumed to be trusted, as occassionally admins would need to pull passwords for recovery purposes, or adding nodes to a shared pool if proper notes or password management wasn't done [mainly needed when doing basic authentication on a domain cluster needing shared passwords].
The passwords are only decrypted if you run appcmd as Administrator. If you run as a normal account, you get back the encrypted string.
This will be something like [enc:IISSomethingProvider:…:enc], just as you find it in applicationHost.config.
I have a virtual directory setup on my server. The main website is public on port 80 but I have a /subfolder virtual directory that I want to ask for a username and password (not a ASP page, standard username password prompt).
Any ideas?
You can set the permissions on each directory separately, so you can leave the main site open to everyone (allow anonymous access), but then restrict the subdirectory (turn off anonymous access and turn on something else, such as basic authentication--just be aware of the security implications if you use basic authentication over HTTP instead of HTTPS). Select the directory and then click on the Authentication option to change these settings.
See also http://technet.microsoft.com/en-us/library/cc733010%28WS.10%29.aspx for more info on the pros and cons of various authentication options and the things you should consider.