Mozilla claims someone can sit at your computer and get your passwords for each site in 15 seconds. I learned while writing a Firefox extension for the first time that I could access any file in a users directory (given that it was owned by the user). If the passwords are decrypted and written somewhere in the users directory, then they are accessible during a session by a malicious extension or site that uses web code that may access a users directory. What is the process the Software Security Device uses in Firefox that ensures site passwords are really secure from such malicious code?
Decrypting passwords to the hard drive would be insecure because other processes could read them. Does the Software Security Device decrypt them to the users directory?
If not, then does the Software Security Device decrypt them only in ram? If so, then what are the possibilities of another application reading the application space of the Software Security Device?
Please describe.
Describing the process shouldn't be a secret, because secrets are an indication of vulnerability and weakness, instead a true secure method requires brute force to break. An open policy about the encryption process gives a wider audience, which increases the potential for more secure solutions.
I bring this up, because it's not described in the Software Security Device explanation or Master Password explanation on the Mozilla site, leaving me wondering if we are really secure using that feature.
The passwords are stored in the SQLite database signons.sqlite in user's profile directory. By default they are not really encrypted - extracting them from this file and "decrypting" is trivial. To have some security here the user has to define a master password (on the Security tab of the Firefox options), this one will be used to encrypt the passwords in the database. If that has been done then extracting passwords from signons.sqlite is non-trivial, one has to guess the master password.
But Firefox needs to decrypt the passwords to use them of course. If some browser code requests a password (via nsILoginManager) a master password prompt appears - the user needs to enter the master password to allow decrypting his passwords. The decrypted passwords are never written to disk but the browser (and any browser extensions) will be able to access them after that.
Firefox doesn't do anything to prevent extensions from accessing passwords because it would be pointless. The only way to prevent a malicious extension from getting to your passwords is to avoid installing a malicious extension in the first place. Even if nsILoginManager were not there, a malicious extension could still sniff on your communication with the web page when the password is transmitted. Or it could listen to what you type when asked for the master password. Or it could fake a master password dialog and get the master password directly. There are tons of possibilities - an application cannot possibly beat another application that is running with the same privileges.
PS: Software Security Device is for certificates, not passwords - entirely unrelated. But it uses the same master password, hence the confusing dialog.
Related
I'm working on a android application that writes, in some parts, in a FileZilla server. In my code, I provide the login and password for the FileZilla so that the client could send some pictures and videos to it.
The client later on needs to read the FTP content (Display it), but for that purpose, he needs to enter the login and password, which I can't provide him otherwise he could write whatever he wants in my server.
Is there any way to require a login and password for writing in the FTP server, but not in the reading ??
You can setup two accounts on the server. One with read-only access, and one with write access. Provide the client with password to read-only account. Or you can allow even anonymous read-only access to the server.
EDIT: Also, be aware that it would not be a problem for a hacker to retrieve the hard-coded password from your Android application binary. Make sure you restrict the area, where the account can write to, ideally to a single folder only. You should also set disk quota for the account, so that the hacker cannot fill your server's disk. And you should definitelly monitor the writable folder for an unusual activity.
Is there any more securely way to protect and store a password than Windows DPAPI do?
My program needs to store a secret (something like credentials) to do automatic logins on Windows, and this secret have to be shared with other users accounts because the program can be run on different accounts but sharing the credentials.
I need to protect this secret from tampering to avoid an attacker to inject his own credentials and take the control. If the attacker has phisical access I know that there is nothing we can do, but.... currently, what is the best way to store and protect this secret?
If you want to secure something against tampering, you are probably better off with a multi-level approach. The drawback to this is that gaining access (even with all secrets) is an astronomical feat and will bump up your login time on this.
Keep in mind, however, that a system is only as secure as its weakest point; you can have a file in a hidden encrypted volume behind even more layers of custom encryption, but if you have the passwords on a post-it note by your desk at work, odds are that it wont be secure for long.
The same applies with security on windows. ACLs and encryption are only as strong as your administrators' accounts. For tips on security, try Server Fault.
As for the system itself, implementing public-key cryptography (asymmetric encryption) through keys or digital certificates somehow and giving every user their own individual keys/IDs is a much safer alternative with far fewer risks.
Windows has supported pubkey infrastructure since at least windows server 2000; you can even use a smartcard logon if you have the hardware for it.
Consider the following:
1. An attacker obtains a private key (with protection on it) from a user. This can be broken #2048bit in an hour or two on average hardware. With this example, you need only remove the public key of the user and have them re-generate a new key.
2. An attacker obtains a user's digital certificate, then you have two options:
1) Remove their certificate from the Active Directory store, ACL or other certificate store.
2) Issue a revocation on the certificate, and forceably expire it. This assumes your are acting as the certificate authority.
In short, this answer states one thing: If you are worried about password security that much, then you should not be using passwords. If you make your system take forever to break, then the alternative route is a botnet bruteforce of a password.
I work as a student web developer for my computer science department and I've been asked to look into a modification of our password reset procedure for linux accounts. Currently users will log in with their university credentials (via Active Directory) and after being authenticated they get a temporary password through email which they are forced to change as soon as they log in. This way eben if the temporary password it intercepted there is a very short time span in which it could even be used.
Now the idea has been posed that instead of using a temporary password that we might allow the user to pick a new permanent password and set it directly through the web utility. It is my understanding that https is more of "the best we have" than "a great way to secure information". Are there any other avenues I can explore for securing the new password so that we can feel comfortable implementing such a system?
Basically, if you communicate with a server over HTTPS and the private key of the server isn't exposed to someone else, you can be sure that anything you transfer (e.g. the new password) can only be decrypted by the server. Additionally the server certificate assures, that the server you are communicating with, really is the server you want to communicate with.
So, using HTTPS provides authentication and prevents eavesdropping.
If you are working with Active Directory, it is my understanding that the Password Modify Extended Operation (which requires the existing password) is not supported. Therefore, the password must be changed with the LDAP modify request. One solution would be to use the UnboundID LDAP SDK with a web application to execute the LDAP modify with the new password. The modify request should be transmitted over a secure connection, or a non-secure connection promoted to a secure connection using the StartTLS extended operation.
see also
AD password change
Using ldapmodify - this article is about the command line utility ldapmodify but the concepts are useful.
If I uncheck the "Enable anonymous access" checkbox in IIS, so as to password protect a site, i.e. by restricting read access to designated Windows accounts, does the resulting password dialogue which is then presented to all anonymous http requests, represent a security risk in that it (seemingly) offers all and sundry an unlimited number of attempts to guess at any Windows account password?
EDIT:
Okay, not much joy with this so far, so I'm attaching a bounty. Just 50 points sorry, I am a man of modest means. To clarify what I'm after: does disabling anonymous access in IIS offer a password guessing opportunity to the public which did not exist previously, or is it the case that the browser's user credentials dialogue can be simulated by including a username and password in a http request directly, and that the response would indicate whether the combination was correct even though the page was open to anonymous users anyway? Furthermore, are incorrect password attempts submitted via http subject to the same lockout policy enforced for internal logins, and if so does this represent a very easy opportunity to deliberately lock out known usernames, or alternatively, if not, is there anything that can be done to mitigate this unlimited password guessing opportunity?
The short answer to your question is yes. Any time you give any remote access to any resource on your network it presents a security risk. Your best bet would be to follow IIS best practices and then take some precautions of your own. Rename your built in administrator account. Enforce strong password policies. Change the server header. Removing anonymous access, while a password guessing risk, is a very manageable one if used with the proper layered security model.
When you choose an authentication other than Anonymous, you certainly can be subject to password hacking. However, the account that is uses is subject to the standard account lockout policies set in Local Security Policy and your Domain's security policy.
For example, if you have a local account "FRED" and the account lockout policy is set to 5 invalid attempts within 30 minutes, then this effectively prevents account password guessing, at the risk of a denial of service attack. However, setting the reset window to a value (15 minutes?) effectively limits the DOS.
Basic Authentication is not recommeded for a non-SSL connection since the password will travel in plain text.
Digest Authentication requires passwords to be stored on the server using a reversible encryption, so while better than Basic, Digest has its flaws.
Windows Integrated Authentication
includes NTLM and Kerberos.
The IIS Server should be configured via Group Policy or Local Security settings to disable LM authentication ( Network security: LAN Manager authentication level set to "Send NTLMv2 response only" or higher, preferred is "Send NTLMv2 response only\refuse LM & NTLM") to prevent trivial LM hash cracking and to prevent NTLM man in the middle proxy attacks.
Kerberos can be used, however it only works if both machines are members of the same domain and the DC's can be reached. Since this doesn't typically happen over the internet, you can ignore Kerberos.
So the end result is, yes, disabling anonymous does open you up for password cracking attempts and DOS attacks, but these can be prevented and mitigated.
You should read about differnet authentication mechanisms available: Basic, Digest, NTLM, Certificates, etc. The IETF compiled a document that dicusses the pros and cons of some of these (NTLM is propriatary MS protocol).
Bottom line is: You are not done with just disabling anonymous access. You definitely have to consider carefully what the attack scenarios are, what the potential damage might be, what user may be willing to accept and so on.
If you introduce authorization you need to address the risk of credentials being compromised. You should also think if what you actually want to achieve is confidential transport of the content: In this case you will have to instroduce transport layer security like SSL.
I am by know means a hosting guru and I imagine there are ways and means of doing this but my personal opinion is that what you are talking about doing is defiantly an unnecessary security risk. If this site is to be available on the internet i.e. it will have public access then you probably don't want to disable anonymous access in IIS.
Please remember that the idea of being able to configure the anonymous access for a site in IIS is so that you can create a user which has specific permission to read the relevant files for a particular site. What we are talking about here is file access on a physical disc. For one thing a public web server should be in a DMZ and not part of your companies domain so users should not be able to log in with their domain credentials anyway.
The only reason why I could imagine that you would want to switch off anonymous access and force users to input their Windows credentials is for a site which will only be used internally and even then I would probably not choose to restrict access in this manner.
If you want to restrict access to content on a public website then you would probably be better of writing something which handles authentication as part of the site itself or a service which the site can consume. Then if someone were to obtain user credentials then at least all they will be able to do is gain access to the site and there is no potential for a breach of your internal network by any means.
There is a reason why developers spend allot of time writing user management solutions. You will find plenty of advice on how to write something like this and plenty of libraries that will do most of the work for you.
What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.
On a unix system, I would just echo the password over stdin but the service has no stdin.
Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.
I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.
Thanks
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on
startup and wait for the required
password to be supplied (maybe embed
an SSH server in there, so that the
password cannot be snooped over the
wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read
the password from a configuration file
(that can be secured to the minimum
readership) or registry setting
(again, sufficiently secure such that
only your service and administrators
can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
You can use kerberos mutual authentication. There are few options and examples there.
But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.
DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...
What exactly were the problems that
are beginning to be troublesome? Maybe
we can just solve those...
Currently, the application runs as the Local System account.
Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.
Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.
By the time the application is installed and started, we're heavily dependent on that account.
We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.
We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.
You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.