I want to write a library for my media files. Since I am using a few SAMBA-shares i was wondering how I should save the passwords, since I need them to access the share. Is there any other possibility to store them than just plain text?
I am using postgresql for the data. The end-product will be a web app.
The difference to other password saving questions is, that i need to send the password to other services. That's the reason why I can't save hashes.
If you store the NT hash you should still be able to NTLM authenticate to Samba. This isn't a bulletproof solution since the NT hash is as good as the password itself to servers that accept NTLM authentication, but assuming that your Samba server is well-protected on a private network it's still an improvement. Among other things, it makes it less likely that someone stealing your password database can use the contents to compromise users' accounts on other systems where they may use the same password.
Related
This question already has an answer here:
Automatic Login from one web site to Moodle web site?
(1 answer)
Closed last year.
I have an user details stored in my web site database and Moodle database. I logged my website with that credentials , Moodle also auto login with that credentials is there any way? Or any Code is available?
If you're handling credentials correctly (and Moodle does), you DO NOT STORE THE ACTUAL PASSWORD! Instead, you store a salted hash of the password.
When someone tries to log in, you salt and hash the attempted password using the same salt and hashing algorithm. This will give you the same result as the value in the database, and so instead of comparing passwords directly you now compare hash values. In this way your users are protected from having their passwords leaked if someone breaches your application.
If you're not doing it this way on your own site, you're doing it WRONG and need to fix it ASAP. This is big deal!
Here's the thing: the two web sites aren't necessarily using the same hashing algorithm, and certainly aren't using the same salt. Therefore the user credentials you have saved for your web site are NOT the same credentials saved in Moodle, even if all the users have the same password.
But what you're really asking about is SSO (single-sign-on). There are (safer!) ways to support this. SAML, CAS, Shibboleth, and OAuth come to mind, and Moodle definitely supports these. You can also have Shared (as opposed to Single) Sign-On, where both your app and Moodle use a third party such as AD or LDAP for identity verification, so the username/password credentials are the same but you still have to sign into both applications separately.
Unfortunately, you will need to build this into your own app, as well, and perhaps even add an additional authentication portal server to your organization to act as the trusted intermediary between each of these applications. There are a number or products you can use, including some that are open source or may already be included with other licensing, so you don't have to start from scratch or necessarily make an expensive purchase here.
The good news here is these products generally also put you into a good position to start supporting Multi-Factor Authentication, which is also an important feature to provide.
I have a problem where I can't seem to find any solution.
I have a web application which uses webdav so I can connect to it via windows explorer and edit files. This works.
Now I want to use authentication with this folder. I already did this via a servlet filter with BASIC Authentication and DIGEST Authentication which both work fine, when the password is at some point available in cleartext.
The problem is that my passwords are stored in a hashed format in my sql database.
With BASIC Authentication i can compare the user pass with the database because it is transmitted in cleartext. I don't want that.
When I use DIGEST Authentification the pasword is transmitted in encrypted format and the password is needed in cleartext from the database to calculate the response. Since the password is already hashed there is no way to calculate a valid response.
I also checked Negotiate/Spnego/ntlm authorization but as far as I understand these are for windows users only and don't have anything to do with my sql database.
The database is either mysql, mssql or postgre.
Are there any other authentication mechanisms that work with windows explorer, where I can make it at least a little bit harder to decrypt the password so it won't be sent in cleartext?
Sounds like what you want is Forms Authentication: http://msdn.microsoft.com/en-us/library/7t6b43z4.ASPX
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.
I'm currently thinking how I could protect my REST API which is used only by my mobile application from being used by other applications?
Could a API-Key be a good solution, because just me know the secret API key.
Is there a better solution?
Leon, you keep mentioning "someone else using my API with another application". So, you want to tie your API to be used only by one application? So, you don't want to give access rights to a user, you want to give them instead to an instance of your application running on the user's mobile device.
In essence: You don't trust the user!
Well, in that case you need to make sure your application is closed source, need to code your credentials into your application in such a way that nobody can retrieve them or store the credentials for it in a specially encrypted manner on the device, the decryption key for it being readable only by your application. In a way, you need to implement a form of DRM to prevent people from doing stuff with data on their mobile device. And you need to hope that nobody can reverse engineer it.
If your app becomes popular / interesting enough, count on the fact that people who are very, very good at this sort of thing will look at your application and will break your encryption before you know it. Maybe, if you put the same amount of effort into it as Skype has, maybe then you can ward them off for a while.
But ask yourself: Why bother? Why don't I trust my users? Is it really worth it to jump through hoops like this to prevent some other application from using my API?
Just lead your user through a registration process in which each app instance gets a unique key from the server (or a unique HTTP auth password) and stores that somewhere on the user's mobile device. Then, to access the interesting features in the API, require the presence of this key/password. But don't go through extreme length to obfuscate or encrypt the key when you store it locally, it's not worth it. If you every detect misuse later, you can always revoke the access rights for a particular account on the server anyway.
Use HTTP Authentication. REST is all about using the facilities available in HTTP, so the native HTTP auth should be used. With basic authentication you’ll have to use HTTPS though. If you cannot do that use HTTP digest auth or NTLM.
All of them have different strengths and weaknesses, and not every one of them might be supported by your HTTP server and client library.
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.