It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
If /usr/bin/passwd was not a set-UID program, what capabilities would it require for a normal user to still be allowed to change his password?
It would need to be able to modify /etc/passwd, /etc/shadow and/or various other files (depending on how authentication is configured).
So CAP_DAC_OVERRIDE would seem to be sufficient, however, it is trivial to root a box with CAP_DAC_OVERRIDE, because any binary can be replaced (such as /bin/sh which is often executed by root cron-jobs).
On some systems, privileges are not required to change passwords because a daemon is used already, e.g. most decentralised authentication systems (nis+ etc)
Impossible unless you want to destroy the security of the system.
If the "passwd" utility can do its job as a normal user, then any user could write their own version to change the password of any other user. (That is, take the source code to the utility, modify it to skip asking for the current password, compile, and run.)
I suppose you could create a "password daemon" that runs as root and listens on a socket in order to service password change requests. Why you would want that instead of a set-uid /usr/bin/passwd is beyond me, though; the security implications are identical.
But no matter what you do, changing the password database can only be allowed for some trusted process. Otherwise anybody can change anybody else's password, which kind of defeats the purpose of a multi-user OS.
You'd need to be running as root. passwd requires read/write access to /etc/passwd and /etc/shadow, and those are files that only root can directly manipulate.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I just want to know if having 2FA on your login can actually mean that you don't need to worry about it if someone steals your username and password?
I know there is a problem if someone steals your phone, and can access an authentication app like Google Authenticator or Microsoft Authenticator and just enter the app and read the generated codes. But what are the odds of anyone actually being able to get access to your phone and accessing that such an app?
I am using 2FA in most of the services I am using because I feel much safer that way. But is it worth implementing it in your own services if your encryption system is not so good? Will it be critical if someone manages to break into my service and read everyone's usernames and passwords in the hypothetical situation where everyone is using 2FA and unique passwords anyway?
A few thoughts:
Security tends to be better when there are more "layers" of it. A combination of username and password is one such layer. 2FA is another. Adding 2FA will no doubt improve your security, but you should still strive to keep your username and passwords secret. Consider what happens if someone steals your phone, but is unable to get hold of your password. Use both.
Related: Logging into a system is not the only threat; information about an account is too: What if a user does not wish it to be known that he has an account in your system? If someone can access your database of usernames and passwords and the data is published, the whole world will know who your users are; perhaps this is not critical in your case, but it can be in certain other cases, and it`s a good principle to adhere to in any case. So strive to keep both usernames and passwords secret, if possible.
I realize you already know this, but your hypothetical situation is just that - hypothetical. You should never assume that all your user's passwords will be unique to your service. Some users will do stupid things. That may not be your fault, nor your responsibility, but it is still considered good practice to do what you can to help them stay safe.
If you are aware that your encryption system is "not so good", then you should obviously try to improve it.
2FA may not always work, or may not be an option for everyone in all cases. If it is not critical to your service, you might consider making it possible to opt out of. For some customers, choosing to accept a little more risk may be worth it for a slight reduction in "hassle" when logging in. For others, this minor "hassle" may be an insignificant price for better security. In any case, you should offer 2FA as a possible improvement in security, and not as an excuse for lax security in other areas.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For a while I have enjoyed poking around all devices I can reach, and routers are no exception. By now, I have analysed 4 routers supplied by my ISP, and all of them have posed serious security flaws, aside of the poor default user/password scheme that most vendors seem to follow.
I find some of them particularly worrying, for example:
Some Comtrend routers allow configuration via telnet. Most of the commands are read and run by an interpreter, but others are dispatched to sh, using 'sh -c COMMAND'. So if anyone types 'sysinfo && ls /', will see the root folder listed just after sysinfo's output. Someone "attempted" to patch that, in my current device if I type "&" in a command, it is invalidated. But I still can type 'ping || ls /', which should be a very ovious flaw, once they noticed and patched the first one. Why would anyone use 'sh -c' instead of fork/exec? (given that the telnet daemon is a binary, likely written in C)
Comtrend Router CT-5624, an unauthorised user can access /password.cgi, which is the password change form, and that contains in a plain html comment the current password for each user. (Cannot find a CVE number, so refer to https://www.exploit-db.com/exploits/18101/)
Once an admin has logged in a ZyXEL Router P-660HN, anyone is allowed to enter the administration panel. Again no CVE: https://www.exploit-db.com/exploits/32204/
CVE2012-2765 Affects a number of belkin devices that directly give away the MD5 hash of the admin password in the main admin page, the hash is directly used for logging in.
A quick search will reveal lots of security issues like these ones.
I am far from being a security expert (I haven't even completed my bachelor) but even I can , which leads me to think that people who wrote this firmware don't really care about security at all, or actually care of doing things glitchy.
Is there any good explaination for these devices to be so unsafe?
I think the main answer is that horribly-insecure firmware doesn't hurt sales, because the general public doesn't know, and doesn't have the background to understand the problems. So there's little profit in paying your engineers to do anything but the most straightforward "get it to work" implementation.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I want protect web-application for administrator/other with physical access to server.
Any ideas?
Thanks
How physical is physical? :P
Your webserver (let's say Apache) needs to access your files. It runs under a user account (www-data or apache or something). Ergo: the files for the webapplication should be accessible to this other user.
An administrator (root user?) can impersonate any user, and has access to all files, so if you're dealing with a very smart administrator he can always get to your files.
You could run your webserver on a different account, and encrypt the part of your disk where the web application files are running. But since the webserver needs to decrypt it, the decryption key has to be stored somewhere, and the administrator has access to it.
So, I'd go for obfuscating your web application with (in case of PHP) something like Zend Guard, this makes the source unreadable. With a license manager on top the source is quite useless outside the server. (Not completely unbreakable though).
The only way to make really sure your sources are safe, you should be the only one with access to the root/administrator account.
Physical access can only be prevented by hosting your own server in a secure data center...
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
how to minimize threat on website?can u list the way to minimize that problem?
This is an extremely broad topic, and can't really effectively be answered in one answer. But here's a few common vunerabilities you should be researching and learning about.
XSS (Cross-site scripting) attacks - A method by which the security of your users can be compromised by allowing arbitrary javascript to be executed on your page.
SQL Injection - By allowing arbitrary SQL scripts to be executed on your database, you can give attackers the ability to retrieve senstive information from your database or even destroy data.
Password Security best practices - There's a whole host of information about the proper way to deal with authentication and storage of user information in your database.
There are a handful of universal things to employ:
Good password policies
Avoid SQL injection vulnerabilities
Secure the server itself, not just the website
This list can, and does, go on just about forever. It's a little vague, but then so is your question really.
It sounds like you're asking "How do I do secure web programming?" That's just too broad for this site. You're asking us to impart years of industry knowledge about a very diverse subject into a few paragraphs. It just can't be done.
You're much better off getting some books on the subject. You can start with the Web Security Testing Cookbook. But there are a lot more places to go from there.
Keep in mind that two big parts of "securing a website" are:
Designing it with security in mind from the beginning. Retro-fitting security isn't very reliable. (As an old network admin I worked with once said, even if you put your cotton candy in a steel box, it's still soft and squishy.)
Knowing how to exploit security holes, so as to better test your own implementations.
As others have mentioned, this is a broad topic.
Personally, I would start here: http://www.owasp.org/index.php/Top_10_2010
The OWASP Top 10 list is the basis for PCI compliance, and considered the gold standard by many as far as web applicaiton security. OWASP offers general guidance, as well as specific guidance for any number of platforms. I've learned more about security here than anywhere else.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!