Protecting against piracy when developing desktop applications through product keys, obfuscation, or similar client-side protections is pointless (plenty of stackoverflow posts regarding that). The only real way to prevent piracy is to create a client-server communication where important code is only on the server.
That's what I'm attempting to do with my software, require a login in order to authenticate requests to the server to process some data. Throw in an easy way to change the password and IP session tracking and it's pretty foolproof. However, now the user must enter a username and password when they want to use it, and they could enter someone else's credentials very easily.
Then thought then crossed my mind, what about embedding the username within the application when a user downloads the client software? Only a password would be required from the user's point of view, speeds things up a bit. Yes it's still possible to edit the program to someone else's username, but now it's less obvious.
So that's my question, are there any security risks or design flaws with having the username hard coded into the program? And secondly, how does one begin to implement the username embedding and C++ compilation on say... a Node js server application?
Thanks for your time.
You're missing the point of server-hosted software, and that's this:
You always have control over the server. You never have control over the client.
So when you say:
the user must enter a username and password when they want to use it, and they could enter someone else's credentials very easily
What you really mean is:
When someone enters someone else's credentials what can I do?
The answer to that is to limit or cancel access for credentials depending on access patterns. If you see suspicious access, like coming from IPs in different countries, you may want to investigate and possibly ban the account.
You're not powerless here when you control the server. Lock people out if you must.
You also don't want to embed information in the executable because legitimate owners, your customers, will want to verify they downloaded the right file based on a cryptographic hash like SHA2. If you modify each file they can't do this, and every version looks "hacked".
Instead, if you must, create some kind of encrypted access or license file that can be supplied to the server and decrypted with a key that's only stored on the server. Sure, they can share that file with someone else, but you can identify the unauthorized access and handle it accordingly.
Related
I'm writing C++ desktop application that allows users to sign in on some web service. By technical requirements, user can check 'remember me' checkbox and after he close app and run it again, app should re-sign in with email and password user input first time.
I know that it is not safe and strongly not recommended to store passwords on disk but i have no idea how to remember user's password in safe way. Is there any best practices or advices for such case?
Note: my application is for Windows/Ubuntu/MacOS so it will be cool to know about OS-independent ways. My app is C++11/Qt5.4 based.
The way that you're supposed to implement this kind of design is to issue the user a SessionID that is stored locally, and which is used to authenticate and access their specific interface. Then, if they wish to log in again at a later time, simply use the stored SessionID, and if they wish to log in as someone else, clear the SessionID and then log them in like normal, issuing a new SessionID. That way you aren't storing sensitive information on their computer.
I'm looking at scripting parts of my workflow, which involves interacting with some web-services via SOAP and XML-RPC queries. I'm scripting using bash and python.
I need to authenticate against these web services, and I'd ideally like to do so
without having to type in my password for every request (typing it once per login would be fine)
without hardcoding it in my scripts
without storing it in plain text anywhere on disk
in a way which isn't specific to one flavour of Unix
The OS X keychain (via the 'security' command) is one possible solution for the Mac OS X case, but there are issues with using it from a script as noted in a related question, and I'm hoping for a more general solution.
I'll have a go at answering my own question.
I could do either or these, or a combination of both:
Store the password in a file with 600 permissions on an encrypted partition
Store the password in a file encrypted with a passphrase, and read that passphrase into an environment variable interactively, once for every shell I'll be calling the script from
Combining these approaches seems sufficiently paranoid.
I'm trying to wrap my head around your architecture, so I'm not sure which thing you are trying to authenticate. Are you trying to:
- check the web service caller
- check the web service provider
- both
And is the thing being authenticated a human using a program or the server itself?
And do you have to pass the service calls around and authenticate them at multiple points or is this strictly point to point?
And what is your assessment of risk? What bad stuff is the authentication preventing?
If you do your proposed #1, your authentication problem moves from the message to the server - if your server is physically protected and your authetication credentials to the OS are "strong enough" you're probably decently protected in where you've stored the password.
I'm confused on #2 - if you are reading in the passphrase interactively, why not read in the password interactively and not store the password at all? If the passphrase unlocks the password, handling the passphrase should be as careful as if you are handling the password.
The bigger concern with any password is where is it going, and how is it protected along the way. Using passwords within the web service will be risky if you are sending your web service messages in the clear. Also where are passwords checked on the other end, and how are they distributed to the server for storage for #1 and #2? This is just stuff to consider for any password based authentication mechanism.
Also - how often should passwords be changed and do you have a procedure for it?
And how much do you repeat the password? If you have exactly one password shared across every machine, the risk is much higher than a different password for each server/script or user, since you can disable them one at a time.
Maybe a technique like ssh-agent.
I have a website (the basic gist of which is described in this question), and I want to have some way to store the username and some information about the user consistently while they use the site (ie, upload and download data).
Right now, given a successful login, I was returning the hash of the password as well as any associated information. Anytime a user tries something, their username, hash, and so forth must match what's in the database. If the user logs out, their local Sinatra session has all information flushed.
I realize that this is a very naive approach. Is there a better way to handle user session information? The wikipedia entry on cookies mentions that a session uid is used instead of this other information; what is the advantage of that approach? I suspect that this approach is also vulnerable to other attacks, but since I verify everything that's done as it's done, I'm not sure what attacks I'm leaving myself open to.
Also, if/when I implement ssl, will these transactions be 'automagically' encrypted, or will I need to do something else to make sure that the strings are protected, if they need to be?
This is actually a very complicated issue. Just to illustrate, you have the problem of account lock-out: If you lock out based on failed attempts, how easy is it for an attacker to DOS your website?
I'll list a few best-practices to get you started:
Store Passwords Salted and Hashed alongside the Username and UserId. (You should also store the salt next to the hash.)
Disallow frequent bad-password attempts. (More frequent than once every few seconds).
If attempts are failing for any given user or any given IP address (more than 3 times a minute) require some form of human-validation, like a CAPTCHA. This allows you to prevent total DOS attacks.
If implementing an auto-login system, use a token authentication system.
For token authentication systems, use a Secure random number generator, send the plain token to the users, but Salt and Hash the token at the database.
Use TLS/SSL if possible, but don't rely on their security once the data is off-the-wire.
If your website is built in asp.net then you can use dot net securities.. which is really very good. and you can also use principle classes in it to make it more secure..
A Note
I have a very good understanding of sessions and the theory of secure web-based authentication, etc., so please don't start with the basics, or give ambiguous answers. I am not looking for Best Practices, because I am aware of them. I am looking for the real risks behind them, that make the Best Practices what they are.
I have read, and agree with the principals that nothing more than a Session identifier should be stored in a Cookie at any given time.
The Story
However... I've inherited a rusty old app that stores the Username, Password, and an additional ID, in a Cookie, which is checked throughout the site as verification/authorization.
This site is always (can only be) accessed via HTTPS, and depending on your stance, is a "low-risk" website.
The application, in its current state, cannot be re-written in such a way as to handle Sessions - to properly implement such a thing would require, essentially, re-writing the entire application.
The Question
When suggesting to the-powers-that-be that storing their user's IDs/Passwords in plaintext, in a Cookie, is an extremely bad idea, what real risks are involved, considering the connection is always initiated and manipulated via HTTPS?
For example: is the only obvious way to compromise this information via Physical Access to the machine containing the Cookie? What other real risks exist?
HTTPS just protects against a man-in-the-middle attack by encrypting the data that goes across the wire. The information would still be in plain text on the client. So anything on the client's computer can go through that cookie information and extract the pertinent information.
Some other risks include cross-site scripting attacks which can enable cookie theft and who knows what kind of browser vulnerabilities which can enable cookie theft.
A given browser's "cookie jar" might not be stored securely, i.e., an attacker might be able to read it without physical access to the machine, over a LAN, or from a distributed filesystem (e.g., if the machine's storing user homes on a storage server, to allow for roaming), or via an application running on the machine.
Some browsers keep cookies in a file that can be displayed on the computer. IE6 comes to mind.
It seems to me that cookies are not all that restricted to a single site. Lots of advertising uses cookies across multiple sites. If I go to NextTag and look for a Nikon D700 camera then
I see NextTag advertisements on slashdot.org. This is an example of a cross-site cookie. Most users use the same password all over the web so if you store the password to one site and make it even a little easy to get to then malicious folks will sooner or later get to it.
To summarize this would be a very very very bad idea. On sites that I work on we don't save users passwords at all. We convert them to a hash key and save the hash key. That way we can validate the user but if we loose the content then there is no exposure of passwords. And this is on the server side, not the browser side!
Most cookies are limited time credentials. For example, session identifiers that expire after a couple hours or are forgotten when the browser windows. Even if the attacker gains access to the session cookie, they are guaranteed neither continued access to the account nor the ability to prevent the original account holder from logging in. Preventing long term account compromise is one of the reasons users are asked for their old password before being allowed to enter a new one.
A cookie containing a username and password, if disclosed, is much longer lived. Also, many users share their passwords between websites. As others have pointed out, the cookie could easily be disclosed via Cross-Site Scripting.
Finally, is the cookie marked with the "Secure" flag? If its not, an active network attack can easily force the browser to disclose it, even if HTTPS is used to serve the entire site.
People here already mentioned the "man in the middle" attack. The thing is that even with https it is still possible. There are different ways to do this - some of them relay on physical access to the network some of them do not.
The bottom line here is that even with https it is still possible for somebody to insert itself between your app and the browser. Everything will be passed through and will look from the browser exactly the same EXCEPT the server certificate. The intruder will have to send his own instead of the real one.
The browser will detect that there are problems with the certificate - usually it will either be issued to a different dns name or, more likely it will not be verified.
And here is the problem: how this violation is presented to the end user and how end user will react. In older versions of IE all indication of the problem was a small broken lock icon on the right side of the status bar - something which many people would not even notice.
How much risk this introduces depends on what is the environment and who (how trainable) the users are
Two two main vulnerabilities are cross site scripting attacks and someone accessing the user's machine.
Have you thought about just storing a password hash in the cookie instead of the raw password? It would require some coding changes but not nearly as many as swapping out your entire authentication system.
I want to get the various user account passwords which are stored in my computer programatically using Visual C++. Are there any APIs to help me do this?
There is no way to retrieve windows passwords nor passwords to most other programs via Win32 APIs.
For Windows passwords you typically have to ask the user to enter their username/password and verify it, all by using LogonUser.
For other programs they are usually stored on disk encrypted by the host application.
This is most definitely not allowed on Windows.
Consider the consequences of letting any given program obtain passwords. That would mean that programs like Solitaire would be able to get your password and use it in any number of nefarious ways. Worse, the program could use the password to access other machines in resources.
In short, it would throw security out the window
No. That would be a security hole. See this article.
It depends what passwords are you trying to get?
Some passwords can not be retrieved, like the Windows login passwords. Some other password are stored (plain or encrypted) somewhere in the disk or registry, depending on how the application stores them.
The Win32 API CredEnumerate, for example, can give you the user credentials (login and password) for some of the applications (Internet explorer passwords, ... etc).
You can only recover the hashed password, not the password itself.
I have no personal experience with this but I was once told that there are utilities out there (usually found on .ru sites ;)) that will do this sort of job for you. And that it's appalling to see how this happens, makes you paranoid. I can't however suggest a particular tool for doing this, but would like to oppose to all those that keep saying it's not possible.