So this is my first question on SO and this is my issue...
I have made a widows form app in visual studio for the Client of an organisation application(Like JIRA but not..). I am using a SQL server DB to save data and signal-r to communicate. A user must open the application and be hailed by a msgbox asking for name and pw. Using these creds I need to verify that the user is in the database and that the creds are correct. At the moment I send the data to the server and then check that the creds are valid and then return a bool indicating if it was successful or not, but I'm sure that's not the best way to do it... I've done near to no security(i just started as a junior dev) and have no idea where to start from a security stand point. i would like to save the users names and pw's in the Database as well as the connection id, but I'm not sure what to use. there are lots of examples out there (OAuth,certificate, etc.. (those might be the same thing for all I know right now)) Maybe a few examples would help, I've googled most everything I could think of and have come up with very few examples that are relevant to what i need. Maybe I'm just asking the wrong questions, but some/any help would be nice.
Thanks
LegenBerry
As you have mentioned that your are using SignlR I assume you are using OWIN to host the application.
You should be relying on ASP.NET Identity to perform authentication and authorization.
You may follow the steps documented at https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/ to write a simple cookie based authentication.
Related
My imagined problem. My c# .net wpf app needs to validate user credentials against azure-ad. Im not using asp.net. I cant ask for the credentials and verify myself so this needs passed off, which in this case requiring oauth to do the work is fine.
All I need from this login is was it successful, and what is the username/email.
My solution to this for wpf is popup a browser window to my websites azure-outh endpoint.
This works great and i can get what i need, however the broswer conveniently saves the password, so next time 'anyone' trys to log in the user name and password autofill.
Looking at the oauth docs, i didnt see anything regarding this (maybe i missed it).
Googling doesnt seem to turn up anything either.
Im not saying this is the only way to do it. All i need is for a employee or customer to use a .net c# wpf exe to verify their credentials against our client/tenant and return back, yes this is indeed a real login.
Also yes this is an answer, but i dont control the oauth page, so thats not valid.
Another answer is using ropc which requires my exe getting the username/password, which only really want to do that as last resort. i dont know what the more valid solutions are. The other problem, is 2-step auth can be enabled which oauth handles nicely.
Any help / thoughts / suggestions / or complete freaking reworks to get that information would be appreciated. Also if im completely off my rocker, tell me (and give a reason why and what i should do ;) )!
I have a question,
Is it possible to use Google user accounts for authentication in WinFormsAPP?
I need to write an application in C# Winforms that reads user-specific data from a database.
Is there an easy way to authenticate using Google?
I might be able to store a list of valid Google users in my database, or maybe I can even define a list of valid application users in Google?
Is there perhaps already a sample project for this case somewhere? I actually can't believe that I am the first developer with such a requirement...
I am grateful for any help or suggestion!
Have a look at:
Integrating "Sign In With Google" Functionality To An Application
Login using Google OAuth 2.0 with C#
Introduction
Okay so I've got a website (PHP) with a database (MySQL). You can create an account on this website and edit your details and so on (let's say date of birth, real name, address, and so on).
Now, what I wanna do is to create a desktop application (most likely c# with WPF) that interacts with a REST api (in PHP) from the website, which will allow to :
Create accounts directly from the application
Log in to your account
Be able to edit your details directly from the application
As of now I only want to do a desktop application, but it might evolve into a mobile app. I don't think that is relevant though.
Creating accounts and logging in
I'm struggling with the create account / log in part. I want it to be as secure as possible. On the website, I'm using password_hash(PASSWORD_BCRYPT) with a cost of 10 to store passwords in the database, and password-verify to check log ins.
Regarding the application, I imagine the way to go is to pass the username and password to the REST api and do the encryption directly on the server side. But sending the password itself sounds terrible so I thought about encrypting it with a secret key that only the application and the website know, so the website can figure out the password and encode it correctly in the database.
If I'm right, what encryption algorithm should I use? If not, how should I do that?
Edit your details directly from the application
I'm thinking about doing the following : Let's say the user has logged in through the application. If the authentication is successful, the server randomly generates a token (I'll probably use ircmaxell's Random-Lib) and send it as a reply to the application. From then onward, when the application wants to make a request to the api, it adds the username to the datas string, and generates a hash (sha256 for example) with the data string plus the token; then the server can repeat the exact process using the token stored in database to make sure the user actually has the right to access/modify his details, and nobody is trying to pretend to be an user he isn't.
I feel like the problem is, if someone listens to the first api reply after the authentication, he gets the token and can use it to act as if he was the user. Would encrypting it with the same process used for the password be enough to make sure this can't happen?
Last but not least, if I want the user to be able to be directly logged in the next time he starts the application, I guess I have to give the token a permanent durability and store it in a file or something on the computer. But that doesn't sound really safe because anyone could just read the file content and figure out the token.
Final questions
So. What do you think ? Does it sound good or am I completely off the tracks?
The website hosting is in http://* so I guess using HTTPS communications is not an option here. I know that's a big problem to create something really secured, but I'd still like to make something as safe as possible with what I have.
Thanks a lot for your advices. :)
Btw I tried to make this as clear as possible, hope it worked. I have close to pretty little knowledge of security, encryption, ... so you'll have to speak like to a 3 years old to me.
I think the first, most important piece of advice I could give is to never try to roll your own security code, unless you are an absolute expert. You'll want to put together a solution based on the frameworks that .net provides for you.
First things first - your REST API. I'd suggest building on top of ASP.NET Web API. HTTPS is mandatory here - if your hosting provider can't give it to you, you need a new hosting provider. It also conveniently takes care of encryption for you.
There are various security options available for ASP, I'd read this for a detailed overview: https://docs.asp.net/en/latest/security/. Using the existing ASP options will also take care of your requirements around user account creation and self-service.
I've built an application that utilizes a database hosted with Amazon. I'm trying to find a way to connect to this securely and overall, I've been assured that I have no idea what I'm doing.
My original intent was to store my database credentials in my application with encryption, but I've been led to believe that using a web service would be a better option as nothing stored local can be really secured. However, I have no idea how to use a web service for this and or why it would make a difference.
In using a web service, would I be building a Windows Server and deploying this "web service" to it to connect to, which would then connect to my database? That almost seems superfluous, though I still consider myself to be an amateur. Even then, how would I authenticate to it securely?
The end-game for me is to be able to store DB (and PayPal seller credentials) somewhere that a user cannot access in any case, but my program can. It seems much more cut and dry than people here and elsewhere have made it seem, but again, I'm a newb.
Any direction would be greatly appreciated! I'd like to deploy this, soon outside of our organization for testing and such.
Thanks, guys!
To me, it's unthinkable to give your "application" -- which I assume means an "app" deployed on people's devices or maybe some kind of a desktop application -- direct connectivity to your database, unless the thought of putting the key to your car in a paper envelope and sticking it to the window seems secure.
The application should have an extremely small number of very specific things it can do to the database, and should be leaving a trail of exactly what it does and from where and on whose behalf. The app can make requests to a service, such as a REST API, running on your application server -- the "web service" -- over https, and your application server would then mediate the requests and fetch values from, or send updates to, the database, as appropriate... only after the app has convinced the application server that it indeed represents the particular user that it claims to represent.
It's a fundamental principle that anything you don't control, you can't trust.
"Why it would make a difference" is the difference between "Ha! I hacked one user's password" and "Ha! I stole your database." The application server can authenticate any request as being legitimate for the particular end-user credentials presented... while the database is, in large measure, ill-prepared to do anything of the sort.
The end-user (not the application) would authenticate to the application server, the application server would validate those credentials against the database, providing no hints as to why authentication failed... user not found, password incorrect, we don't know, we don't care -- sorry, login failed. Give us your e-mail address and we'll send you a support email, or if that's not an e-mail we have on file, we'll pretend that we did. Hints help hackers.
store ... PayPal seller credentials
Well, you'll want to be sure that's not among the things that are prohibited from "collect, capture, use, or store" in section 10.1.2 of the Paypal Developer Agreement.
So, how do you do this? That part of the answer takes us a little bit out of scope, because there are many options, the landscape shifts, and it's largely a matter of opinion as to the "best" way but I'd assume ASP or PHP would be the most straightforward.
Think of it as building a database-enabled web site without the hassles of making it pretty, because nobody's going to see it except that back-end of your app... and there's your "web service".
I've been assured that I have no idea what I'm doing
That puts you way ahead of the terrifying number of people who don't realize that they don't know what they are doing.
If your database is mysql, then you can use: Connector/Net from mysql. Credentials for the db are usually kept in web.config of your application. Also I see no reason of using web service in your case. Web services are used when you need to transfer data from one system to another, not to provide better security for database connection.
EDIT:
As Michael kindly explained this approach is for the web application which is hosted on the server. As for the client application, keeping the database credentials in the app (encrypted or not) is very bad idea. In this case additional web application should be developed, which will provide the way to authenticate users using web service (over https), and transfer the data to users from database.
What is a good approach for credential checks for windows mobile app. Knowing that it is an occasionally connected device.
Should I keep the user credential into the local database? If the credential doesn't exist in the db, try to see if it has internet access and do the check through a web service?
If both fails then display an error message ?
If logins is successful then store the credential to the local database store then upon next login go against the database first?
Is this a good approach?
It's difficult for us to tell you what is a "good" approach because it depends highly on what your requirements are, your device, your network and a lod of other things. Your process seems reasonable for an application that needs to authenticate with some remote server. Just a few things to consider:
How will you store the local credential? An MD5 hash or something else?
Are you authenticating back to something like a server where the cred needs to be NTLM or are you just doing a local app authentication?
If the user loses the device and someone else finds it, how does that affect your auth procedures?
How do they get the very first auth if they have no network?
How secure is your web service? Does it even matter?
I'm sure there are other good questions to ask - these are just the ones that come to mind right now. The point is that only you know what level of security your app needs and what the use-cases are going to be so the best person to judge if an approach is good is going to be you.
I have a similar situation in mobile software we use, we use the following approach:
The first login on the device needs a connection to verify credentials.
It will store the last used username and a hash of the password locally.
The next login, using the same username will hash the entered
password and compare it with the local one. If they match, the user
is logged in without the need of an internet connection. If it fails the
user gets two more attemps, at which point the software asks to verify
the credentials through the master server.
The next login, using a different username will always use
an internet connection to verify. And if it succeeds, it will follow
step one again.
Obviously, you need to be aware of the fact that this approach is vulnerable to a brute force attack. There is no way you can prevent a hacker from doing a lot of attemps. You can only try to slow them down (using a slow hashing algorithm and other nags). If you are really worried about such attacks; using a connected login verification method is your only way to go.
There are other things to consider by the way. Is the device connected frequently or really infrequently? Do a lot of different users login on the device while a connection is not available? Answers to such questions could lead you to a single login implementation.