Situation:
I'm creating inner API for my website (Node.js + Express). But I completely don't know how to secure it.
I have payments in my application, and I need to know when user makes it. I use XHR requests for transferring data between server and frontend.
Questions:
Is it secure to transfer user's time to a server (can I trust this information?). If no, how can I get it securely? I thought about transferring user's location, and then with help of mement.js get his time, but it's also not secure if a hacker can replace it with his data.
Can hacker make XHR request from developer's console to my server? If yes, how can I get his real time?
I'll be happy if you answer at least some of my questions.
First of all, I would suggest not writing the code yourself if you are not confident enough about it. Storing payment details is a big responsibility, and can get you in legal trouble if anything gets compromised. I would suggest using services like Paypal to handle the payment.
That said, I am going to answer your question:
You cannot trust ANY information you receive from the user. The time and location can be spoofed/altered very easily.
Yes, it is possible to make (modify) a request from the console (maybe some add-ons and technical knowledge will be required, but it is doable). It is not possible to know the real time of the user. It is only possible to know the session timeout of the server, and estimate the time of the user, relative to the time of the server, based on that. It is also possible to know the IP of the user and estimate the time-zone, but using a VPN or Tor, it is trivial for a user to alter it.
EDIT: Using Paypal would increase the security, compared to writing it yourself. Here is the API reference: https://developer.paypal.com/
EDIT 2: Here is a brief explanation of why you should never trust user input: https://www.enisa.europa.eu/publications/info-notes/the-dangers-of-trusting-user-input
Related
My parents own a wallbox for charging a electric car. The wallbox is controllable with an app which uses an authenticated API. I already did a MITM attack to get that traffic. I also have the login data, as it is the wallbox of my parents and they agreed that I do this. (If you are interested: I try to automate that the car is always charging when there is enough power from the photovoltaic but at the same time the car should never run low if there is not enough sun.)
I want to write a small Python script which controls the wallbox, but the only problem is, that I don‘t know how the authentication works.
Is there any way to find that out, without decompiling the app (which I found hard because it apparently uses React Native with the Hermes engine from Facebook which can‘t be decompiled as nicely as other Android apps)?
Is it realistic to find the used authentication method by just looking at the example I show below?
Or is the only way to understand the authentication with the decompiled app? I pasted an example of what I sniffed below.
If there is an easy solution to my problem, I am happy to take that, but if you say that I should look more into these and that, then I am also good with that, as I am kinda stuck at the moment.
Thank you very much!
Two messages from the API
They come automatically after opening the websocket connection.
{
"type":"hello",
"message":"Hello app",
"serial":"3215XXXX",
"devicetype":"deviceName",
"manufacturer":"companyName",
"protocol":2
}
The first token stays the same for multiple hours, even if you make multiple requests to the API.
{
"type":"authRequired",
"token1":"0dtOJ1LkCrMgaz5ri8MZmgHBcXXXXXXX",
"token2":"Ij10ETYSo2GJSVMJlDNzMGW9TXXXXXXX"
}
From the app
{
"type":"auth",
"token3":"b4eb9e8baae62429c577216aaXXXXXXX",
"hash":"cbc3d99391db59e59174ddb01073157581afb2ad1e392433c9107477eXXXXXXX"
}
Answer from the API
{
"type":"authSuccess",
"message":"Successfully authenticated"
}
It's not super-realistic to assess the auth method from that data, however, you can get some idea.
There could be multiple reasons why the server provides two tokens (rather than just one), but I'm going to give a "best estimation" example scenario. The auth method is possibly something fairly similar to this. It's possible that one of the two tokens is authenticating the server to the client.
One of the two tokens the server provides is likely some sort of challenge for the client: it may be a hash of current time or day, or a hash of a client-specific identifier, or just some random data used to prevent replay attacks.
The client response to the server is probably some hashed or encrypted combination of one of the tokens from the server and the client secret (your password, or username:password, or username:password:productID or something like that.)
The hash may be a protection against replay attacks by hashing the current time along with the client secret info, or possibly an authentication sequence number along with client secret info.
So as you can probably tell there are many, many possibilities here. It's possible the whole protocol is custom designed by the charging station manufacturer.
You might try sniffing some data again, and within the first token timeframe try to replay what your client sent. It will most likely not auth you, but It's possible you'll be presented with some error information that is useful and can give you more clues about what's going on.
Otherwise, the disassembler is probably going to be the way to go, and may be tedious, but should give you a much clearer picture of the correct auth protocol.
I am creating a unity game where users can post their high scores after a successful match, my problem is that some users can post directly to the api, without playing a match. How do i curb such an issue. I have read some articles about using native mobile encryption to help. but i do not know how this can be applied to Unity since it is a layer above native. what techniques can i use ?
Encryption will only solve a part of the problem, when users send fake requests to your API. But if I were you, I would perform server-side validation based on the parameters sent by the client.
How: Send one request to the server when a match starts, along with necessary details such as the user name. When the match is finished, send another request to the server, check the score against some heuristics based on how long the match took, and whether the score makes sense given the user's specific setup (levels and equipment, etc.) if you keep that information on the server.
Why: There's no reliable way to control what the user does on his client: he can change the values in memory, send forged requests, and so on. If the user meddles with the memory to give himself "100x damage dealt", your client may not know, and will dutifully record the (now tampered) score and send it to the web API. Encryption will not help you here since the request is just like the real thing except it contained a fake score to start with.
I have been following your project for quite some time now and am intrigued by the functionality of gunDB where it doesn't require a database in between and keeps security in check.
However, I've got some questions about GunDB which I've been thinking about for quite some time now before I can give Gun a go with a project I'm currently working on. In this project it is necessary that data is safe but should also be shareable once a group has been setup. The project is a mobile app project and ata is mostly stored on the device in a SQLite database.
I have been looking into Gun as it allows for better usage of the app in sense of collaboration. The questions I have, however, are:
User authentication
How is user authentication handled through private keys? So how can a user "register" with, for example, a username and password to login to the service.
For authentication I am currently using Firebase where it is possible to use username/password authentication and I would like to know how Gun approaches this case and how it's implemented.
Data storage
In the documentation and on the website it's stated that data is stored locally with every client and can be stored on a "node" or server using either a local hard drive or the Amazon S3 storage option.
What I am curious about is what data is actually stored at the client? Is this only the data he/she has access to or is this a copy of the whole dataset where the client can only access whatever he/she is granted to have access to?
Maintaining your data
When I've got a production system running with a lot of data, how will I be able to manage my data flows and/or help out my clients with issues they have in the system?
In other words, how can I make sure I can keep up with the system if I want to throw in an update and/or service my clients with data issues.
My main concern is the ability to synchronize their local storage correctly.
Those are all my questions for now.
Thank you very much in advance for providing some clarity on these subjects.
Best regards,
(Answered by Mark Nadal on Github: https://github.com/amark/gun/issues/398#issuecomment-320418285)
#sleever great to hear from you! Thanks for finally jumping into the discussion! :D
User Authentication,
this is currently in alpha. If you haven't already seen these links, check them out:
https://github.com/amark/gun/wiki/auth
http://gun.js.org/explainers/data/security.html
https://github.com/amark/gun/blob/master/sea.js#L23-L43
https://github.com/BrockAtkinson/login-riot-gun
If you have already, would love to either (A) get you to alpha test and help push things forward or (B) hear any specific questions you have about it. This thread is also a more at length discussion about alternative security API ideas: #321 .
Data storage.
Browser peers by default store the data that they subscribe to, not the full data set. You could ask it to store everything, but the browser wouldn't like that. Meanwhile NodeJS peers, especially if hooked up to S3 or others, would store all data and act as a backup.
Does this make data insecure? No, encryption should keep it secure, even if anybody/everybody stores it, the encryption makes it safe. (See [insert link to (1)] for more information).
Maintenance.
You would service your customers by deploying an update to your app code. It would not be ideal for your customers if you could meddle with their data directly. If they wanted you to do that, my recommendation would be that they change their password, give the new password to you, and you login and make any necessary changes. Why? Because if you have admin access to their data, their privacy is fundamentally violated.
Assuming you have registered your device with Google 2-step Verification, what information does it use to verify that you are on that device when you come back to the website?
Does it store something on your computer (like a cookie), or does it use some other algorithm to determine where you are logging in from?
It stores various bits of information about your conversation with the server. SSL cookies, session data such as your IP address and other information about your browser. As you change this information, a risk assessment value is increased as deviation from the originally known values changes. Once this value reaches a certain threshold, based on your country's online risk profile, that sets off a chain of events that invalidates your session.
When your session is invalidated, you need to log-in again.
It's more complicated than a cookie, but it involves cookies too.
There is a lot of debate in the security community as to whether it matters to add protection beyond endpoint and cookie verification and when it becomes a nuisance to the end user.
Just a quick follow-up on this question. A lot of people continue to view this question, but surprisingly, there hasn't been a good answer posted.
Since the original post, I did a lot of research to find out what technologies are used to determine a unique device, and I finally stumbled across the panopticlick project.
This website answered a lot of questions because it showed the exact metrics that a website can use to fingerprint your browser. Using this methodology, a site can really narrow down the exact device that you use to connect to a service, and therefore make it much easier to validate a 2-step verification.
Hopefully this helps someone trying to implement 2-step on your site.
I'm developping a web site for a broker (JSF 2 + richfaces + oracle 10g), and i wanted to have your opinion concerning HTTPS (because i think it's not necessary in my case, since the user won't give any important details).
So:
to enter the web site, the user has to authenticate himself (using JAAS)
there's a page showing Stock Market data (it's financial data, so it's not that important)
the user can buy/sell stocks : he gives quantity, price, the account ( not bank account) for which he will buy/sell
the user can see his accounts, what stocks he has, past operations, etc....
Is it necessary to use SSL in my case ?
Yes, it sure sounds like it. Authentication usually involves sending a username/password combination to the server. That should never be done in clear text, so that requirement alone would make SSL a good idea. Furthermore, buying and selling stocks sounds like something that you would want to do in a secure manner.
I don't even understand what your concern is. Having an SSL protected website does not mean that you have to write a single line of code. It's just a question of buying an ssl certificate and configuring your web server.
I think it is necessary indeed, as it involves real money. Even if the user doesn't give away any details, there still can be man-in-the-middle attacks between the user and your server, which would enable anybody to gain access to the server with his credentials.
If it doesn't involve real money (it's not clearly written out), then you won't necessarily need it.
If the user is passing anything sensitive (and I'd say the number for a stock trading account is hugely sensitive) then HTTPS is crucial, in my opinion.
The way I'm seeing what you described, you have a user identifying himself/herself, and then you're passing basically all the info about his/her account over the web. Definitely secure that as much as possible.
There is not "good" way to get authentication tokens securly (in your case passwords) without using HTTPS or a one-time-password system.
In any case, I would sure want this type of access to be HTTPS secured else I might not trust it.