Most wallets have an option to manually sign a message to prove ownership . I do not see the option in any waves wallet.
When I say manually sign, I mean take a piece of arbitrary text, paste it in wallet and get signature response.
Am I just not seeing it?
There is currently no such option inside the waveswallet.
You however have a call inside the node api to sign data (with your node PK)
OR you can use library's such as pywaves to get data signed.
But inside the client this isn't available.
Related
I have a REST Api with following path for user to register:
send verification code (/phone-code) -> 2. verify code (/verify) -> 3. enter personal information and register (/sign-up).
On the second step I mark phone as validated if entered code is correct and on the third step i check if phone is marked as validated. But imagine one person verifies the phone and another (let's say a hacker) tries to skip first 2 steps and triggers /sign-up with first person's phone. As the phone is already validated, a hacker registers successfully.
So the question is how to make /sign-up safe? One idea that comes to my mind is double-check code on the second and the third steps. But that comes with a coast of increasing the duration of validation code which is not very safe. Could you advise me something better?
Use some kind of session system on your service that uses cookies. When you sign up and verify, you remember the phone number and whether it was verified in the session.
You shouldn't have to ask for the phone number again, because the phone number should be known and in the session.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
I am building an GWT application with lot's of forms. I am using gwt-platform with its dispatch module.
The next step in my mind is to prevent double-submits ON SERVER SIDE. The problem is that I don't know how to do it exactly...
I thought of something like this:
When application loads the server gives some generated token to the client
The server stores the token inside HTTPSession
When the client submits a form it will send the token from (1.) along with the form
The server checks if the sent token == token inside HTTPSession
In the answer to the client it will send a new token
Is it safe to store the token inside HTTPSession? Or should I simply create a HashMap on the server that maps from SESSION_ID to generated token?
Or maybe there is already an implementation of that in GWT or gwt-platform or somewhere else?
Thanks
The question you'll have to ask yourself first is: What is the kind of problem scenario you want to avoid?
The user accidentally (or out of frustration, ...) clicking a button twice.
A resource that is available only once (like a reservation for a certain seat in an airplane) being consumed twice.
Don't just say "I want to avoid both". Even if you do, you'll have to deal with the two problems separately.
Problem 1
This is better solved on the client side (e.g. by disabling the button once it is clicked).
It can also be solved on the server side (by checking sequence numbers or tokens or maybe the hash code of the contents, ...), but I don't really see the point. If the user really wants to submit twice (e.g. by manipulating the JavaScript such that the button doesn't get disabled), then just let them: Problem 1 is not about security.
Problem 2
This must (except in very specific situations) be solved on the server side. It's chiefly about security. But when you think about it, this problem can't be solved by double-submit prevention! Why not?
Let's look at our example: A seat in an airplane must be reserved only once. This can be violated in multiple ways:
By double-submit.
By the same user submitting at the same time e.g. from different browser windows.
By mutliple users trying to reserve at the same time.
The clean way to solve the problem is to check for availability of the seat atomically with reserving the seat. It doesn't really matter, if a violation was caused by double-submit (accidental double-submits are covered by problem 1).
... and Problem 3
If you have implemented some auto-resubmit mechanism, then you might also encounter a third kind of problem:
Let's say the user wants to add an item to his shopping cart. The client submits, and doesn't receive a response from the server before time-out. So it sends again automatically. The server however receives both messages, and tries to process them both - so it adds the item twice to the shopping cart.
The best solution to avoid this in my opinion is generally not to use actions like "add one item to the cart", but "set the target count of items to 1". Again, you could also work with sequence numbers etc.
I have a C++ plug-in for MetaTrader 4 that allows me to create new accounts in it for trading purposes. I would like to be able to dictate to MT4 the account number when creating the new account. Might any one know whether this is possible and how it might be done?
The account number is generated by the broker upon account creation - So the simple answer is No; you cannot control it. The only way would be to generate an account number, and based on it anticipate what the next account number will be. This is only possible if the account number algorithm is broker-specific. This would surprise me though. I am willing to bet that account numbers are generated by MetaQuotes server with a one-way-function.
You can specify the account number in the login field of the UserRecord struct your are using in the call to UserRecordNew method. If the account already exits you will get an error from the method as apposed to RET_Ok.
If you use any API, you can manually enter the account number. If the specified account number exists, the system will reject your request. Is there any particular reason you want to enter custom numbers while opening the account?
It is not possible to control the account number. The justification of this is the fact that the account number is developed by the broker upon the opening of an account.The only way that this would be possible would be if one was to generate an account number and use this number to anticipate what the next account number will be. This approach is however, possible if the account number algorithm is broker-specific.