user A and user B download an open source app built on a DHT. The app generates a bitcoin keypair for each user. The app demands that if user A requests user B's data, user A has to pay user B a small micropayment. A problem arises if the app is open source and p2p -- user A can simply remove the snippet of code requiring him to pay user B before requesting user B's data.
Any thoughts on a solution that would force user A to pay user B for their data?
A problem arises if the app is open source and p2p -- user A can simply remove the snippet of code requiring him to pay user B before requesting user B's data.
The specific problem you state only arises because B does not trust A.
Since you do not state that there is any problem with A trusting B the answer can be as trivial as B withholds the data until A's payment has arrived.
If neither party trusts the other you would need something consisting of several layered zero knowledge proofs and locked bitcoin transactions.
A slightly less heavyweight approach would be using a trusted 3rd party for escrow or A committing their payment first, B sending the data and then A and B agreeing on successful delivery, with the risk of leaving the coins stranded if A defects after delivery.
You probably should ask further questions on http://bitcoin.stackexchange.com
Related
I got a request as a developer to develop a bitcoin exchange site like https://mypatricia.co/ or https://instantcoins.ng/ I am to leverage on third party API like Coinbase, blockchain, it could be anything reliable API.
Users will be able to buy and sell bitcoin. For instance USER A makes an offer. USER B is interested in USER A's offer. When USER B clicks a button, with be a switch from USER A's wallet to USER B's wallet. Before the EXCHANGE is done. USER B is prompted to make payment in local currency.
I have been looking at https://developers.coinbase.com/api/v2#introduction https://api.blockchain.com/v3 I dont know how to go about it.
Is there any other better ones to work with?
There will be some other endpoints like
Where users get list of their orders
check wallet etc
I will appreciate your contribution
This is a very broad topic, so I'm just going to tackle few key points.
Dependency on third-party blockchain data
You can get rate limited
You might be a subjet to a man-in-the-middle attack
The source might (intentionally or unintentionally) send incorrect data.
The data is usually delayed
You'll most likely need to use another tool to create deposit addresses (since the third-party tools will allow you to create only limited amount of addresses on your account).
It's very risky and unreliable to use a third-party data. It's an industry standard to run a full node for each cryptocurrency you work with and access the blockchain data from your own node instead of a third-party API.
Escrowing the offered amount
As per your example, you need to make sure that user A is actually going to transfer the BTC. Since there are no smart contracts in BTC, you need to act as an escrow.
So you need to accept the BTC from user A to their deposit address (only your site should have the private key to this address) before you even allow them to pass their order into the queue.
Order list
Since you're going to be storing the order list on your side, you need to create a separate database and CRUD endpoints to maintain the order list.
first of all, I don't really know if this is the right place to ask this, if this should be moved, please do so or let me know.
I'm building a mobile app (using phonegap) which is kind of a banking app, hence, I need a really secure method for resetting a lost/forgotten password.
I do not want to use email links or sms codes to proceed to the resetting part because:
Email address can be already compromised.
(Where I live) Phone can be stolen (most likely) and the email could be linked to phone, so SMS would be pointless as well.
So after a bit of reading I have come up with the next idea, inside the app when user clicks forgotten password:
Ask user email of registration.
Ask which country, state and city were selected when registration occured.
Ask if the user had login successfully in the last 3 or 7 days (maybe less is better?).
Ask the last amount of money received (if any).
Ask the last amount of money sended (if any).
Ask the date of the last transaction known (sended or received before or during the last successfull login).
If all that information proves to be correct, let the user set a new password. Else just show a message telling the user that something in the information was wrong, never ever specifing what was wrong.
Those are a few question but I'm writing this as it just occurs to me. There will be more question based on the user expirience using the app.
My Questions:
Is this secure?
Which are the weaknesses of this idea?
Does this effectively replace the email/link combination or phone/sms?
Thanks in advance.
Updates:
I dont like setting security questions during registration because most people forget the answer or type carelessly and then they are trapped with a forgotten account.
I will not be using any bank account or credit/debit card information.
All operations will be in effect inmmediatly.
Maybe I should use questions only related to the use of the app?
This method is relatively secure as password recovery goes. However, it is not very user friendly, and it is very likely that the user can get locked out. On the other hand, a thief may easily still recover a password. Taking all the questions one by one:
Ask user email of registration.
An thief who has stolen a phone has access to this (most likely).
Ask which country, state and city were selected when registration occurred.
This will also be easy to retrieve if the thief searches in the emails of the user. Even if no such info is displayed there, knowing the name of the user, the thief can look in whitepages websites or Facebook and get valuable info.
Ask if the user had login successfully in the last 3 or 7 days (maybe less is better?).
A lucky guess with 50% chance can get the thief past this. A legitimate user might also not remember, which causes the first usability problem of this method.
Ask the last amount of money received (if any).
This is very hard to remember, especially if this does not happen a lot, or happens all the time and the amounts vary. A thief who knows the bank account of the user (maybe info like the IBAN is in the emails) can also transfer a small amount to that account and get past this stage.
Ask the last amount of money sent (if any).
If this involves transactions as well (paying using a credit card), a thief can follow a legitimate user and observe the money spent in the last transaction. If not, it is still a big usability issue, as the user is not likely to remember. The thief can also check the emails of the user and see if there were any goods bought online (Amazon for example sends a confirmation email) and input this as the amount.
Ask the date of the last transaction known (sent or received before or during the last successful login).
Again, this is very hard to remember for the legitimate user. Especially when it comes to receiving money, it can take days, so even if the user knows that a payment to him/her was due at day X, there might have been a delay of a few days.
If I were you, I would put email, username, last password that the user remembers, and 2-5 recovery questions that the user has to set up in the beginning. I would let the user try a total of 3 times, and all these events are logged and the bank notified. Otherwise, the user has to contact the bank in order to change it. Calls are recorded, and personal info is requested, along with a phone banking password. If the user fails again, he/she has to go to the bank with some form of photographic ID.
Response to updates: If an app is not being used on a daily basis (banking-like apps are the case for many users), it might not be a good idea to ask questions regarding the use of the app.
Regarding security questions, maybe if you set a message that warns the user that they might get locked out of their account if they forget them, might convince them to be more careful. Maybe you can let users choose both questions and answers (just make sure the questions and answers are different each time, and they are longer than 1-2 characters).
Context
We have an application A that guides our customer consultants throught a workflow based process. Part of this process has been outsourced to a own webapplication - lets call it application B.
Wenn calling application B the certificate of the current user is used for the HTTPs connection (since it just delegates the HTTP GET to a new browser window).
Application A has the required data to autorize users to perform certain actions while application B expects the autorization to be done once a URL is called.
Application A must as well deliver certain data such as IDs to enable application B to know for example what customer is beeing processed.
Requirements
That application B can expect the autorization to have been done it must be ensured that only application A was the source of the call and the user has not changed the parameters of the URL (which he can as it is his certificate that is used for the HTTPS connection).
What have we done
We thought of building a hash over the parameters, encrypt it with the private key of application A and submit it as additional parameter with any request. Application B uses the public key of application A to decrypt the hash, build a hash over the received parameter and check that parameters have not been changed.
My Question
What would be other possibilities to ensure the source of the call was application A and the parameters have not been changed by the user?
(If not clear please leave a comment i am currently painting some grafics and can overwork the question).
Regards
JBA
So A signs the parameters for B, which is a step in the right direction.
A few more things to consider:
Replay attacks. A malicious user of B might observe a desired set of parameters signed by A. He can replay those anytime in the future, along with the valid signature from A, even if A did not intend to call B with those parameters anymore (say the authorization information changed). To mitigate this, a nonce or a timestamp should also be signed in the request and checked by B when validating the signature (the nonce should be checked for uniqueness, the timestamp for not being too old).
Participants (who's messaging whom). When A signs the message, the signed data should contain the intended recipient, so that an attacker cannot take a message from A to C, and send it to B. Of course if all of your components have a single instance, that's less of an issue, but still A should include something like the message is for B's url, and B should check that the url signed is actually the right one. Similarly, A should include the information that it was signed by A (his own url or IP address for example), and B should validate that the apparent and signed sender are the same.
Not creating a signing oracle. You should make sure that a user cannot use A as a signing oracle for making signatures. The less data a user of A can choose himself for A to sign, the better.
By the way (and apart from all of this), wouldn't it be simpler if B could just query A over some kind of an API request for all the information it needs? That way you wouldn't have to bother with all the relatively complex crypto stuff and would not have to pass sensitive info through the user.
Below is a proposal for dealing with a situation of website security. I am wondering whether it seems feasible, from both a technical and usability point of view. I want to make sure that the proposal does contain any glaring errors.
A. THE WEBSITE
The website in question is a school website where students may purchase various items. These students get an account on the website with a username and password, which they can use to login. Once they login, they have access to protected pages with private content which are unavailable to the public at large.
B. THE SECURITY CONCERN
The owners of the website wish to prevent a situation where a single student signs up on the website, obtains a username and password, and then circulates those credentials to a circle of friends who are then able to login to the website and illegally view the private content.
C. THE SOLUTION
The central idea we have come up with to deal with this security problem is to permit each student to login to the website on two devices only. Once a student logs in on two different devices, they are restricted to those two devices. If they then attempt to login on a third device, the system would simply not permit them to do so. It is our understanding that other websites offering private content, such as Netflix, use such an approach.
D. IMPLEMENTATION
Two ideas come to mind to implement the above security measure: a. IP address. b. Cookies. We rule out IP addresses, which can change, and choose cookies. Websites such as amazon.com allow their customers to login once, and then whenever they return to the website, they are always recognized. This is almost certainly achieved through cookies.
Thus each time a student logs in, we will store on their device a cookie. And we will also store this cookie in our database under that student's account. Thus each time a student logs in on any device, we will check whether the device they are currently logging in on contains the cookie we have stored for that student. If it does not, we will know that the student is logging in on a different device. We will thus be able to know how many devices the student is trying to login on.
E. DRAWBACKS
We have identified at least three possible drawbacks to this approach:
Clearing Cookies. People can, for a variety of reasons, choose to clear the cookies from their computer.
A bona fide person may occasionally not have access to their usual device, and wish to login on a different computer.
People do purchase new devices from time to time.
These are examples of situations where a bona fide user, for legitimate reasons, wishes to login, but will be unable to, due to the website's security restriction of two devices.
We have some ideas as to how to build logic into the system to deal with such situations, which we may implement in the future, but for the time being, we feel that such situations are sufficiently rare that we do not need to handle them programmatically.
Rather, for now, in the event that a student is locked out, they will get a screen with a message explaining why we have not allowed them into the system, and a button which they can click on which will automatically generate an email to the site administrators.
The email will inform them that a student wishes to login on a third device. The administators can then contact the student, and, if they are satisfied that the need is bona fide, they will be able to take steps from the CMS to allow that student in.
The size of the student body is sufficiently manageable that the above approach should be feasible.
F. FAIR WARNING
We will inform the students of these security measures when their account is activated, in order to prevent unpleasant surprises.
This is a typical example of trying to fix via IT a real-world policy problem; in this case, forbidding students to share their credentials.
The solution you are proposing limits usability (for the reasons which you already listed under Drawbacks) and does not ensure security because cookies - and especially content - can be copied around. In short, it is feasible, but can easily be circumvented. It's up to you to decide whether it is worth to implement it. It would probably be better to enforce the "no sharing credentials" rule e.g. set up random checks and send any student caught violating the rule to the Dean.
Been reading up on MitB attacks and some things worry me about this.
From WIKI:
The use of strong authentication tools simply creates an increased level of misplaced confidence on the part of both customer and bank that the transaction is secure.
One of the most effective methods in combating a MitB attack is through an Out-of-Band (OOB) Transaction verification process. This overcomes the MitB Trojan by verifying the transaction details, as received by the host (bank), to the user (customer) over a channel other than the browser
So if I get this straight, that the only real safe method is a non browser confirmation method. (like a phone call or some other external tool)
Would an email count as a OOB Transaction? Or could the MitB send a fake email?
Is there a way to prevent MitB with only code?
EDIT: I'm asking this because our local banking system are employing a physical keygen system for which you have to push to get a number and then enter that number into a field in the transaction form.
I have no idea if that is considered safe, since it looks like a MitB attack is just making it look like everything you did is safe and correct but what actually happened is that the form data was changed on submit and is now transferring to some other bank account. So it would have access to this keygen number.
Would an email count as a OOB Transaction?
Given the prevalence of Web mail services like GMail, I would say No. Even if the target of such an attack isn't using Web mail, an attacker that has control of the target's browser could fire off a fake email, just as you suggest.
Generally speaking if your machine is infected then you are vulnerable no matter what.
A physical token or "out of band" token is designed to solve the "identity" problem and gives the bank higher confidence that the person logging in is the person they say they are. These sort of mechanism normally involve using a "one time code" technique so that even if someone is recording the conversation with the bank, the token can't be reused. However if the malware is intercepting in real-time then they can maliciously control the account after you have successfully logged in, but often banks require a new 'code' each time you try and do something like transfer money out of the account. So the malware would have to wait for you to do this legitimately and then modify the request. However most malware are not real-time and send data to a 3rd party for collection and later use. Using these "one time token" techniques would successfully defend against this post processing of the login data, because the recorded data can't be used later to login in.
To answer your question, there is no way to defend against this only in code. Anything you do could be specifically worked around in a piece of malware.
In the article which is the subject of (and referenced by) that Wikipedia article, step 1 in the "Method of Attack" is stated as:
The trojan infects the computer's software, either OS or Application.
The answer to your question is therefore "no": once the O/S is infected then the malware can (theoretically at least) be intercepting your email too.
As an aside, some client platforms (e.g. even mobile phones, not to mention dedicated point of sale terminals) are less susceptible to infection than others.
I suppose you could use critical pieces of the transaction information as part of a secondary or tertiary transaction verification step. That is, if I thought I told the bank account #12345 and it heard #54321 because the data was adulterated by that type of attack, the secondary verification would fail the encryption check. It would also be possible for the bank to echo back something that was more difficult to alter, like an image containing the relevant information.
The thing about these types of discussions is that it can always get more complicated. Email is not valid out of band step because, I have to imagine I have a rootkit ... if I stop that, I have to imagine that my OS is actually a guest OS running in an evil virtual machine ... if I stop that, I guess I have to imagine it's the matrix and I can't trust anything all to protect my visa card with $200 of available credit. :)
This is my point of view for the man in the browser. The man in the browser is as if:
The victim stands up, leaves his computer, and move his back to his computer, so he can not touch the keyboard, move the mouse or even see the screen.
A hacker sits behind victim computer.
If victim wants to work with his computer he must ask the hacker to do it for him. If he wants to see any result, he must ask the hacker to read the data on the monitor.
The hacker does his best to convince the user that he is doing what he asks for and repeats what he seas. But try to make the benefit of this situation with no mercy !
As a simple case:
Victim may ask hacker to fill a transaction form data as transfer 500USD to mom.
The hacker instead can type transfer 10000USD to Jack. ( Tamper form data before send)
The system may display, I have transferred 10000USD to Jack but the hacker says that the 500USD has transferred to Jack. ( Tamper result HTML)
The victim asks to see his account balance, to make sure that the transfer is done.
The hacker can say that the the account balance in correct ( This can be done for example, by removing the last line of balance table and changing the balance amount in HTML)
As for email:
You are waiting for an email, and ask hacker do I have a confirm email from bank.
As you can not see the monitor, he say yes you have. (Technically he can generate a fake email easily).
(even if you sit on another clean computer, a fake email can be sent to you again)
The image generation can not prevent attack.
You ask the hacker, my bank should shows me an image which must display the transfer information, could you see it, what does it says.
The hacker reply: Yes I can see it, it says "You are transferring 500USD to mom" (The image can easily created by the JavaScript or hacker can point the image url to a server, which generates a dynamic image with appropriate data to cheat user)
The very dangerous situation may happens as the man in the browser change the flow of the site. In this case even an OTP or kegen system can not prevent the attack. For example:
You ask hacker that you want to see your balance
The hacker goes to transfer account page, and fill a transfer account form to transfer 10000USD to jack ( but you don't know what is he doing at all, you are just waiting) he come to a page that asks him for a key. This is the key you which you must give him.
Now, the hacker says : Well, the bank ask me if you want to see your balance you must enter a key.
You think, well a key for balance seems strange, but any way lets give that key, I trust this guy !!
The hacker switch back to transfer form and use the key to do the transfer.
So as you can see there is no server side solution for a Man in the browser you can:
Use a out of the band solution to inform critical information to user. ( This is as if you take a mobile in your hand and although your back is still to your computer but sensitive information are sent to your TRUSTED device and you can see critical information)
Use a hardened browser to make sure that no one can change its behavior. ( Sit back to your computer :) )
Good samples of what can be done by MITB can be found at: http://www.tidos-group.com/blog/2010/12/09/man-in-the-browser-the-power-of-javascript-at-the-example-of-carberp/