I'm having to store a user account locally on a machine, what would be the best method to store this? (Needs to be reversable encryption rather than hash)
I'm accessing a UNC share as mentioned here:
Accessing UNC Share from outside domain for file transfer
Using this suggested method:
http://www.codeproject.com/KB/IP/ConnectUNCPathCredentials.aspx
This will be an automated process so no option of human entered credentials.
I'm currently encrypting the details and storing them in the registry using TripleDES:
http://www.devarticles.com/c/a/VB.Net/String-Encryption-With-Visual-Basic-.NET/4/
With the key and initialization vector hard coded within the application.
Can anyone suggest a better method or changes to the above to secure the credentials as much as possible?
You never ever need to store user credentials. If your process needs to access a network share then it should be run under proper credentials, using runas or service account properties. If the network credential is not in a the local/current domain it should use runas /netonly. And that's all there is to it, no excuses, no exceptions.
As a side note, Windows applications store secrets locally using DPAPI, exposed in .Net as ProtectedData class. The link has fully functional examples of encrypting data with DPAPI in .Net. However, the point remains that storing user credentials in applications, even under DPAPI, is fundamentally broken.
Related
I'm wondering what the view on this particular use of localStorage to store a password is. I have an Angular SPA I am developing to be used as a machine interface.
Currently it is relying on a mix of ASP.NET and 3rd party serving, both locally on the machine. I'm using the 3rd party to authenticate and authorize right now to simplify design although in the future I will likely completely remove the reliance on this part once I can backfill other parts I use it for. On the machine (localhost) there is an access point (browser running in kiosk mode) and at this point alone I would prefer that there be a fallback user with some credentials.
I have thought of 3 main ways of solving this.
Store the fallback in localStorage of the browser on the machine. I know the thought is never store user/password in localStorage but this would only be a slightly elevated version of the default credentials and from what I understand the largest threat here is if the machine storing the password is compromised in which case they would already have access to the physical machine
Some form of filtering requests through the ASP.NET and passing fallback credentials in the cookie. This likely involve passing a plain text password because the SPA would need it in plain text to send to 3rd party for authentication (possibly it could be encrypted but any such encryption could be reversed with the code of the SPA)
Using some sort of browser/native app communication to pass the fallback credentials to the app.
The 3rd seems like it could be secured the most but both the 2&3 require a fair bit of work and I'm not sure that it is even necessary as I stated by the time someone were to access the localStorage they would have already compromised the machine and so would no longer have any advantage
Are there step by step instructions anywhere on how to generate a "ticket" for an iCloud user given their username/password. I'd like to build a service that access iCloud data (server to server) without having to store the iCloud username or password.
My understanding is that you use the username/password to generate a Kerberos ticket from iCloud. That's based on the answer to How does Sunrise for iOS use iCloud credentials to access our calendar? . But I haven't found instructions online on how to do that.
Does anyone know how to do that? Thanks!
Let me start by pointing out that by default iCloud app storage is "sandboxed" in containers. A signed application can only access its own container without having the API key to authenticate to other application containers. You can make multiple applications share the same container, or use multiple containers in the same application if needed, but essentially you have to be the developer of all applications or have explicit permission to do this. Check out Incorporating iCloud into your app and Enabling CloudKit for more details.
Other (non-appstore) applications and services can authenticate to use an application's data via CloudKit Web Services:
Authenticating to iCloud (redirect based, so credentials still are never revealed and are known only by the user and iCloud server itself);
Further authenticating with your application API key;
The process is described in detail here, as already kindly pointed out by Adam Taylor.
All the above being said, If I understand correctly, you want to have access to all of the user's iCloud data. I think, you won't be able to do so for multiple reasons:
Data is protected by application key, so you need to have this to access a container in addition to the basic credentials;
I'm sure that Apple has a design policy to never ask for user credentials in plain text. Asking the user explicitly for credentials will be against their policy and even if it turns out it is not, having the credentials won't help you much, because you have to enter/send them somewhere. But all iCloud authentication mechanisms are designed to ask for authentication only by the end-user.
This is why I don't believe it is possible to just use user credentials and get access to all of their iCloud data. Now, my 2 cents on why Sunrise works:
As far as I understand, the Sunrise application works, because the calendar data is designed to be shared via CalDav, that works on a concrete URL, so you can import and link your calendar in various calendar client applications. The URL can be found out with a bit of investigation. CalDAV is kind of similar to IMAP and POP3 for mailbox access.
Be so kind to elaborate a bit more on what kind of data you're trying to extract (apple application specific, developer application specific, documents, key-value pairs or something else) and me or other users might help you further.
I am building a multi-tier application that will have multiple smaller apps apart from the main app to achieve certain goals.
Example:
I have a login class on my main app, asking for username and password. This class then does all the work, and then returns the login, with credentials, if any, or failed login state.
I want to re-use this code in my smaller client side app. Its precisely the same code, and outcome as in the main app. Therefore I want to re-use it, multiple times if necessary.
First Concern: If I use .net remoting, what security is applied? Would I have to encrypt my username and password initially, then send it through the remoting framework, and on the other side, decrypt it. And then back to the client again? I am worried about something sniffing out my username and password, and even if encrypted, can some clever hacker not just call my remote DLL with the encrypted "sniffed" credentials, as my remote DLL is expecting the encrypted format?
I am essentially trying to not make any DB connections from my smaller client app. Am I better off just putting the code in a local DLL (to the client app) and update the client app when my main DLL changes. If so, what security does MS SQL provide me for transmitting a SQL query containing the username and password to my remote SQL server?
I would appreciate any and all ideas regarding best practices and industry standards. I have always developed for an application server or desktop, so I never had to consider the security issues when sending data remotely.
Thanks in advance
I have since determined that remote access to a DB is just plain too slow to be usable. I am restucturing my solution to include a tcp middle teir, that sits next to the local db. This way I can have my business lgoic in the middle teir, and send appropriate updates to my conencted client.
I am working on an application where all user authentication happens in a ColdFusion application (based on CFWheels), but interactions with the file servers happen through a Node.js application. I need to make sure that the user who is logged in on the CF application is allowed to access the files in the node server. I was thinking of setting a cookie with a CFToken or something that the node server can read and pass to ColdFusion asking "Hey can this token access this file"
My only problem with that is I wasn't sure if CFTokens are re-used eventually, and if they are what should I use instead?
If other people have other ways of doing this sort of thing where authentication needs to be reusable across multiple engines I would love to hear your strategies.
That sounds like a fine way to do it.
But, I would just use CFCOOKIE to set a cookie of your own devising.
The two servers will have to share a domain name, of course, to be able to read the same cookie. You will also have to set the cookie to be a domain cookie.
One clean way to architect this would be to create a whole CFC devoted to the security.
It would have methods for generating and validating login tokens.
Your CF application would use this to generate the token, and you could have your node.js application call this via a webservice using the
http://server.com/path/security.cfc?method=validateToken&token=whatever
An even more efficient way to do this, assuming they have access to the same datastore, would be to use the same algorithm to generate/decode (if needed) the tokens in both systems, and let the node.js app directly access the datastore.
When I needed to do this, we stored the "session" tokens in mongodb, and directly accessed the datastore from each application (CF, Java, and Rails). The CF system was responsible for the initial authentication. The other two systems did no authentication, just validated the token, and if it was not found/invalid/etc, responded in the appropriate way.
Yip, what you want to read up on is SSO (Single Sign-on).
OpenID is a popular one that works with multiple platforms including CF.
If you're feeling adventurous... With a little tought, it is fairly easy to devise your own mechanism for sharing logins - usually around sharing some token via a cookie or header or could also be via RESTfull (or any) form of webservice call too.
I am starting a service for students at my school which requires them giving me their user account information for our school's web system so that I can automate some annoying tasks for them. I will be logging them in using CURL but I am having trouble figuring out how to store their passwords in a secure method. With most web services, passwords are encrypted then stored and when logging in, we only compare the encrypted passwords. This is much different though. Since I will be sending their passwords via HTTP requests, it's required I am able to decrypt their passwords back into original text. How would you recommend I go about storing and retrieving them?
That might not be the answer you are looking at, but if you are going to store user's credentials for a third party service, there is no way to secure the storage with software only. As you mentioned it yourself, your app needs to be able to retrieve from that store the original credentials, in order to impersonate the user. And if your app can do it, so can any other code running on that box.
Thus, the only real solution is to ensure that only your software is running on the box. That assumes physical security as well, limited access to the machine, full audit and lowering the attack surface as much as possible, by turning off all unnecessary services.
On a separate note, if the school services support access delegation (through OAuth for example), you should consider going that route, and get out of the credentials storing business.