What are ways an adversary can get hold of a password hash of a router remotely, that is not the default admin password using Linux?
Does the hash of the admin password reside in certain files?
Are exploits needed to gain access to the file(s) containing the password hash?
Purpose of this is to increase my knowledge, and improve security of devices in the home.
This very much depends on the router. If the router is based on Linux (which is often the case), access to the hashes is limited to the OS administrative user only (root in general). This administrative user will usually be different from the administrator account you use to connect to the router.
You therefore need to have vulnerabilities which allow you to attack services run by root or try to "elevate privileges", that is to use a vulnerability to have effective root rights going from another account.
This is to say that you should always have an up to date device. Unfortunately the vendors are not always quick in releasing patches when a vulnerability is discovered (often not in their devices, but in a library they use).
Related
In my company we're developing a product powered by an ARM processor. We are using Buildroot to make a Linux system for it.
For debugging/maintenaince purposes, SSH access will be enabled using ethernet and the device will have an UART for Serial TTY. The product will be sold to companies, and likely only workers will have physical access to the device.
I would like to know what strategy must we follow regarding user password and private key storage:
Password: what user password must we choose? Choosing one password for all doesn't seem a very good idea. If someone find out this password, he will have access to all our devices, and we can't update them since they're offline. Do we even need to choose a password? Is there any other solution that is secure and doesn't rely on passwords? Something similar to SSH keys, maybe...
SSH private key: I'm considering to generate a key pair and add the public key in authorized_keys file of all devices. This way, any member of our company that have to do maintenaince can import the private key to his computer and directly have access to all devices. But how we could store this private key to keep it reasonable secure (and don't loosing it)?
Security is not critical in this device, since it is not likely to be an interesting objective to hack, its function is not important at all, it is offline and physical access to it will be reasonably restricted. Knowing this, I would like to have answers to points above so we have reasonable security without overcomplicating everything.
Some things I have thought about SSH keys:
Writting it in a paper and keep it in our office: I don't like this very much because I don't trust it not being lost, destroyed...
Saving it in our private Git repository in Bitbucket: I don't dislike this one very much because the same people that have access to repository should be allowed to have the private key, but I don't know how much I must trust in a cloud service for this
I remember that security requirements are not high in this case, but still want to have reasonably good practices.
You should absolutely not set the same password for all devices, or use the same ssh key. Having the ssh key for your company in authorized_keys would effectively be a vendor backdoor. Don't do that. It's also a huge reputational risk for your company, if that key ever gets compromised, your product is probably out of business.
Depending on the actual usecase of your devices, a few relatively secure options you can choose from:
Upon setting up the device by (or at least at) the customer, a new keypair or password could be generated or entered. This secret would then remain with the customer and your company would eliminate the huge risk of storing a master secret for all devices.
You can pre-generate a random password for each device, set it as the password, print it on a piece of paper and stick it on the device. Your company then forgets about that password, and the client should of course be able to change it. This way, there is no master secret for all devices, and an attacker needs physical access to read the password. Note that while something like the mac address sounds like a good candidate for the password, it is not, because it is far too easy to guess. It should be a real random password with sufficient entropy. Also note that this requires that only authorized people have physical access to the device - that's usually the case, but you have not specified what kind of device this is.
Both of these require a one-time setup phase for the device at the customer though.
I am developing a new app that target Windows 8 upwards. It generates and downloads sensitive documents which should only be accessible from the app after logging in.
Since the Windows filesystem is open to Explorer, is there a way to only allow access through my app?
I have already read a bunch of blog posts that talk about how the app is limited in a sandbox so that it can't affect the wider OS, however none have discussed having a secure directory that is not accessible from outside the app.
As a first note, if you allow users to download data to devices they control, and your program can access it, they will be able to access it. In your context, you would want to worry less about benign users accessing it, and worry more about malware and malicious users. With that in mind, you have two goals:
Restrict access to files such that only my application can access them
Restrict access such that my application only has access when the intended user is using it.
There are likely several viable methods of attaining those goals; but as a crypto geek, I of course recommend cryptography. In brief, you can use cryptography to attain these goals in this manner:
When your program initiates, have it generate a random key and store it in an accessible location on disk. Before storing it, use some user-specific secret (like their password) to encrypt the key itself.
When a user downloads a file, encrypt it with the key you have stored. When a user accesses a file, decrypt it with the aforementioned key.
This ensures that the plaintext of the documents is never stored on disk, only in memory, and that an attacker cannot simply steal the key along with the documents. Note that, however, the plaintext key and documents will exist in memory, and a sufficiently sophisticated attacker could be able to retrieve them if they had access to the system while a legitimate user was using your program.
It seems like every application I create needs to be able to send the occasional email. E.g. status emails. For this question, assume my application is a backup tool, locally installed on many windows clients, and each installation needs to send daily status mails. It could be installed on an organization's server or on a private computer.
I am asking the user to provide the credentials to an email account he owns (STMP host, port, username, password, from-address). I copied this approach from applications like Atlassian Jira/Confluence or JFrog Artifactory. Where and how are they storing the SMTP passwords anyway?
My current understanding is: Salting/Hashing approaches do not apply here as I need to be able to retrieve the plaintext password to actually send the emails. I don't want to store the passwords in plaintext, so it's got to be some kind of encryption/decryption approach (right?).
I can tell the user not to use his main email account, but to use some secondary account or, even better, setup a special email account just to be used by my application. If the user is an admin of an organization, he might be able to setup an email account on his exchange server or configure SMTP relaying. But, I know me, and I know my private users, some of them will just use their main email account anyway, so I want to do everything I can to keep their credentials as safe as possible (by that I mean "follow best practices").
Preferrably I would like to store the encrypted password in the application's database.
I've spent hours and hours reading through questions on stackoverflow, but I cannot see a consensus (like there is for user account login credentials). I find this surprising, as I expect basically every developer to be confronted with this problem sooner or later.
There must be some best practices to follow, some established way to go about this, but I haven't found it yet.
Please point me to resources on SO/the web that explain how to tackle this problem. If at all possible written by some specialist in the field.
Some SO questions I have looked at:
Protecting user passwords in desktop applications (Rev 2)
Windows equivalent of OS X Keychain?
It would be good if you would have provided more details on the operating system and the programming language...
However here are some general advices:
The most important thing you have to know is: If your application is able to decrypt it without user interaction (e.g. a password by the user or a hardware token) any attacker will be able to do it. All measures you implement will just increase the complexity of gaining this password.
Of course you should raise the bar as high as possible. For Windows, the DPAPI will be your friend. You can find some Information on how to use it for example here: http://www.c-sharpcorner.com/UploadFile/mosessaur/dpapiprotecteddataclass01052006142332PM/dpapiprotecteddataclass.aspx with C# (I don't know which environment you use).
You can also implement your own configuration and encrypt it using a RSA with a key stored in the local key container - see http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider%28v=vs.100%29.aspx.
Maybe some other people can help you with other operating systems, but the concept there will be the same.
What also may be possible is to use some kind of SSO authentication like Kerberos or NTLM or ..., but this means modifications on the mail server.
Suppose I need a login mechanism for a program in a Local Area Network in a company, my guess is to store a file with username/password pairs on the local server, but would the Java program be able to read/write information to the file from a local PC? It's my first time dealing with such a task so I am a bit confused about this. Also I want to store only the passwords for the program, not the PC user.
Hmm, you should do it differently imho.
Write a service to authenticate against. The service is the only application allowed to read the password-file and runs on the server. The clients authenticate against that service. Once the user is authenticated, pass him an identification token that is tied to his machine and can expire after a period. Also, the machine needs to transmit some sort of digital signature to verify its integrity in an asynchronous manner. If you do this, you can verify that only authenticated users, who really are who they claim to be can access services which require the authentication token, including the authentication service itself.
BUT: I strongly suggest you get something that has already been built for such tasks. There're things like Kerberos which have been built for such tasks. I am not a sysadmin, you might ask again at serverfault or so.
Additionally, I'd like to state that MD5 is not the toughest hash anymore. AFAIK blowfish is the way to go today, I might be wrong, though. It's tougher than MD5 anyway, which is prone to collision-attacks already.
I'm writing a cross-platform TCP/IP server and I need to authenticate users before servicing them. Requirements stipulate that I use "native" authentication of the platform and not create my own authentication mechanism.
For Linux/Unix OS family I use getpwnam to authenticate users and the most reliable way I know to make sure this works is to start my service as root. There're no other reasons for the service to run as root and I wonder what my options are? Can I call getpwnam while not being root w/o compromising security? Or, if there're alternatives to getpwnam, how portable are they and how "administrator-friendly" in a sense of "what configuration effort they require? The reason why independent authentication mechanism is off the table is exactly that it creates "too much a configuration effort".
Have you taken a look at PAM authentication?
Use SASL, for example Cyrus SASL. No root privileges required and all popular Linux distributions support it. I'm using it to authenticate users of intranet site served by Apache and written in Python. Among others Sendmail and Postfix use it for authentication.
Using getpwnam() does not require root privileges.
Trying to get information from the shadow password file, or AFAIK using PAM, does require root privileges, and that presents some problems. However, you might be able to start your process as root, initialize access to PAM, and then drop privileges. That is unconfirmed speculation, but is at least somewhat plausible.
Note that in most systems, getpwnam() does not return you an encrypted (or hashed) password. So, you need to consider carefully what you are planning to do to 'authenticate' the user.