Using C# to log into RoR (Devise) app - c#

I have a RoR web app that currently leverages Devise for user authentication. From what I understand, passwords are stored using the BCrypt algorithm and include both a hashed password and password_salt, which is stored for each user in my users table.
In conjunction I have a Microsoft Office add-in that was developed in C#. I need to be able to log users in from the add-in by calling to the users table and validating the password they entered in the add-in against the hashed password stored in the users table.
Unfortunately when I attempt to use BCrypt via C#, I'm unable to successfully log into the app from the add-in. I've looked all over for examples on how to achieve this, but have come up short.
Could anyone point me in the right direction? And/or do I also need to parse the password_salt? Thanks in advance for your time and assistance.
EDIT: I see that BCrypt no longer requires a separate password_salt.
EDIT2: I'm using devise-encryptable, and in my initializers/devise.rb, I have: config.encryptor = :authlogic_sha512
and a config.pepper, which is set to a long hash. Should C# now use sha152 instead of BCrypt?

I would suggest that you add an API to your application that allows your to send username/password pairs over HTTP and receive an authentication token when successful.
This would be much easier than attempting to interface with the database directly, as devise has already done all the hard work for you.

Related

Jwt authenticaton in c# wpf application

I started learning c# two days ago so I don't have much experience with the .net framework. I want to create an application where the user can input a username/password combination and the login information will be sent to the server for verification. I thought of doing it in the following way by using a PHP script but its not really efficient/secure since everyone will have access to the script.
1) client->Get username/password from user and send the username to the server
2) server->Find out if the user is in the database and send a random number back
3) client->Create an MD5 hash out of the number then create an MD5 out of the passwordMD5+numberMD5\ and send it back to the server with the number
4) server->Create and MD5 hash from the numberHash+passwordHash and compare it the hash received by the client
The other problem with the authentication above is that I want to periodically check if the user is authorized to access the application after it has sign in and I don't want to keep asking for numbers from the website every time the user wants to access something in the application. I did some research and found out about JWT authentication, but the issue I'm having now is implementing JWT authentication in an efficient way. If the user signs into the application it will send the username/password to the server but it doesn't seem safe to send plain passwords the the server. I also want the tokens to have a time limit after it is created. I was thinking about creating a new database for expired tokens and another one for valid tokens and check those database every time the user tries to access information from the site. I was about implementing some kind of API with asp.net core but I found out the host I'm currently using does not support .net. Now I'm thinking about using a server(maybe azure but I'm not familiar with it) just for generating the keys and when the client tries to contact my website I check if the key exist in the invalid key database and block the connection otherwise if its not in the valid key database insert it.
My questions:
1) I there a better way of achieving this other than the way above.
2) If not then what would be the best way of checking the keys to give client access the website database.
Have you possibly looked into using Auth0 for protecting your server and your WPF application? Check out https://auth0.com/docs/quickstart/native/wpf-winforms for more information as you can probably implement this using the free tier they offer.

Storing credentials in an encrypted file

I'm working on a couple of projects that need to store user credentials for third-party applications, such as Paypal, Facebook developer creds etc. I've read a few books about different kinds of coding, including ASP.NET, WPF, jQuery, and all have nice examples on how to access the preceding services with own secrets, and also all of them use the exact phrase "in a real project you would store these in an encrypted file". None, however, give an example how to do so.
I have little (read: none) experience in encryption, but based on my understanding, I would need to encrypt a username and a password using some sort of key (salt?) and save them in a file. I would also want to be able to use these credentials on my apps so I would need to store the key (salt?) in my code.
Now my question is: How is it safer to store the decryption key, which is still plain text, in the program code, than the actual credentials?
Wouldn't the malicious user be able to decrypt my password-file as soon as he gets the key?
--EDIT--
I really mean my own credentials I need to store to log in to third party applications, not credentials of my users. For example I need to identify my self and/or my app to Google, so that users can log in to my app using their own Google account.
--EDIT 2--
To clarify, this is what I'm talking about. This screenshot is from asp.net PayPal tutorial:
Any quick pointers on good practises here?
You misunderstood the part about storing encrypted password* + salt: this is done when your system needs to validate someone else's credentials. In this situation storing password hash and the salt is more secure than storing the credentials, encrypted or not, because an attacker would have no way of getting the password back, even if he manages to get his hands on both the hash and the salt.
Storing decryption key in plain text is never a good option, because an attacker would get your users' passwords as soon as he gets access to the key.
There is no good solution to persisting your own credentials, encrypted or not. Your component that talks to 3-rd party services should use developer APIs from these providers. For example, PayPal provides two sets of APIs which you can use to access your account without having to store your password.
If you need to store a small amount of secret information in an encrypted form, use registry APIs to store the data in a key known to your application, and accessible from the user running your server-side component. This secret would be safe, as long as hackers do not hack the password for the account under which your service is running.
* Technically, password is not encrypted, it's hashed, i.e. there is no reliable way to turn the result of conversion back to the original value.
Your suspicions are correct. If the user has access to the key they can just go and decrypt the username and passwords themselves.
The two options you have are
Make it difficult enough to get the password that the reword of getting the password is not worth the effort to find it. This approach is done via things like Code Obfuscateors, I would not recommend this to someone starting out. Its not easy to get it right and it only takes one person who things it is "worth the effort" for it to break.
Don't give the user the information ever. Instead of storing the usernames and passwords in the program have your program call out to a server you own, then that server is what makes the request using the credentials. This approach is the more reliable one and is "unbreakable" (as long as your server is secure) but costs more because you now need to keep a server up and running that can handle the load of your entire userbase.

Store key file as embedded resource (how unsafe is it?)

If I have a stored key file used to decrypt the encrypted input coming into my application, and I store that key file as an embedded resource so that it is embedded in the assembly when deploying, how difficult would it be for someone to reverse engineer the application and retrieve the key file?
Also, the application is deployed through ClickOnce "Online only" mode which I imagine would also make it more difficult to reverse engineer? (I'm not exactly sure of the workings of ClickOnce but I wasn't able to find the dll's/assemblies on my local machine after running the application in online only mode...).
Update:
As Ralf essentially answered the main question below in his comment (answer: it's not really safe at all), here's some more information so that you knowledgeable people can possibly suggest a better security model.
The encryption will be used to encrypt the login password for my application, to be used in a SSO setup (the user will first sign on to a different system and then by clicking a link will be able to directly open my application without having to enter in their login details).
The encrypted data will be sent as a base-64 string URL parameter in the link that will launch the my click-once application.
I will also be developing the application that will create the encrypted data for the URL parameter (clarification: not the first application the user will sign in to for the SSO, I will only be creating a small tool to convert the plain text password into an encrypted base64 string).
It's only an internal application so bullet proof security isn't essential and ease of deployment is more important, but it'd be nice to know what the best practices and different options that are available.
Whether in clear text or encrypted, you don't want to store the password. When you get a password, all you should do is pass it to your server app where you compare it against the salted hash of the password you have in the DB. Even if you don't think security is that important, you need to take care with the password because people frequently reuse passwords across different systems. I know they shouldn't but they do.
If you want to implement a single sign on (SSO), create a sign on token on the server side and pass it back to the client, either encrypted or signed (HMAC is a good choice for signing). This is an unforgeable token because you need to know the encryption key or shared secret for the HMAC and that data is only known on your servers. So you have your SSO and all data involving the SSO is managed on servers so there's no data leakage or chance of spoofing.
As long as the aplication can be launched, the files have to be somewhere on the computer. You just have to know where to look. The reverse-engineering may be ugly but it is always possible. The computer has to be able to understand what he is supposed to do so you only have to extraxt the information one is looking for. Therefore the security of your application should never depend on the difficulty of reverse-engineering! I believe that a secure application should be open-source anyways.
You propably need a diffent security model. The important thing here is that you know against what you want to protect the data. If you simply want that you know the data is sent by the server and not somebody else (man in the middle attack) you could use digital signatures instead.
If you do not want anybody to read any data sent between server and client you should use some sort of ssl implementation to create an encrypted channel. Then you only need to watch out that the public key of the server is not altered on the client. This may be done by an certificate of an official CA but unfortunately those are usualy not for free.

Securely Upload files C#/PHP

So I have no code at the current time but I haven't quite started because of the following issue.
I want to have a website (written in PHP) that allows users to upload files but I'd also like to have a C# app that runs on a Windows desktop and can automatically upload the files. My question has to do with security.
Firstly, from the PHP perspective is simply hashing and salting with MD5 or something similar really safe for accounts on a website?
Furthermore, how can I safely STORE and preserve the credentials of the user LOCALLY within my C# application? Almost like cookies except I'd be managing it myself. I'm looking for a high level answer as well as what specific tools I should use (or what I should read about before fully pursuing this).
Thank you in advance for your time. :)
To answer both questions...
Firstly, hashing and salting with MD5 is no longer 100% secure as people can use a rainbow table to quickly hack the hashing. You might want to look into something that generates a longer hash to prevent rainbow tables attack.
If you want to safely store a authentication token on the client end (like a "remember me" check box), you can have a table in your server that stores a random string every time the user accesses the php page. To make it more secure, you can hash in a unique value of that PC, like the network card's MAC address.
What this does is...
1) When the user first logs in from the c# app, you will create a record that stores the user id, the MAC address, and a long random string in that table. You then return this random string to the c# app to store in the local file.
2) When the c# app access the web page again, it will pass to your PHP app, the MAC address and the random string stored there. If it matches a record, then we know the user id of the c# app.
3) The php side should then re-generate another random string and send it back to the c# app to overwrite the existing locally stored authentication token. This will ensure the token changes a lot and people cannot simply make a copy of the file storing the token, and be able to access the server.
Hope this is clear enough.
A salted sha256 hash will be fine. Salt it with something that isn't stored in the database. Having the data come from two different sources will make it even harder to brute force.
It depends on the C# app. If it's only going to have one user then transfer the files over SSH using your public key. If something goes awry you can always revoke the key.

Xml file (on a server) Based Authentication for a desktop application possible?

I am developing a Desktop application using c#. This application would require users to login before using it .
I plan to have an xml file on a server (which is not public to view) .
When the user logs in to the application using a username and password it would check with the xml file Online for the information and allow the user to proceed .
This is my approach and have not started coding it yet .
I would like to know if this is good enough an approach or are there are any other approaches that are better and more feasible ?
Please change the tags associated with the question if anyone feels they are not the right ones ..
thanks
EDIT 1.
I would add another level of username password to use that xml file online .. One that only the application would know
You can create a WCF Service around your XML-File to authenticate the users. That way, you don't need to expose the file to the public.
It could be, depending on your exact scenario and requirements. A couple of things you may want to think about:
Consider storing hashes of the password in the database rather than the password itself. (And then send the hashed password over the wire rather than the password itself.) That way, if either your database or connection are ever compromised, you won't be exposing passwords.
Consider sending the authentication data over an SSL connection so it cannot be seen by eavesdroppers. (Especially if you choose to send raw passwords over the wire.)

Categories