I'm using pywallet.py --info --importhex --importprivkey PASSWORD to create my own Bitcoin addresses. I'm thinking of using a long password HJNKND/678J***?¡\bhkbfNCHgv&%$bvd_ and add a counter for each new address.
For example:
Address 1: HJNKND/678J***?¡\bhkbfNCHgv&%$bvd_1
Address 2: HJNKND/678J***?¡\bhkbfNCHgv&%$bvd_2
etc
Is this secure? Or does it have and obvious flaw I'm not aware?
Thanks
pywallet.py is secure enough, but basic security steps is also required of course. Depending on Linux distribution you're using if your machine is desktop/connected to network then nobody can guarantee that there's no trojans.
Most experts recommend having isolated machine not connected to the Internet to generate wallets & other activities like that
Related
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
I'm the administrator of a growing corporate network and we will shortly be providing guest WIFI access.
I have been to various places before where the receptionist has generated a random username and password which has then given me access to the web for a period of hours. If I wanted more, I'd go back to reception and they'd repeat the process.
I would like to implement a similar process for our network.
Does anyone have any pointers towards suppliers/makers of the software that could do this? I imagine it'd run on a Windows PC, and connect to our Active Directory in order to create such accounts under the appropriate policy.
Thanks.
A lot of routers have the ability to communicate to a Radius server. What you would need is a front end to generate usernames and passwords for the radius server that expire after X amount of time.
I'm trying to set up a server that will be logged into by people paying for a service I offer, but I want to make sure that only those people who I want can access it. I obviously can't simply give each one a different user account because they could simply share credentials with other people. Is it possible to restrict SSH access by MAC address or RSA Key or something like that? By IP doesn't work either because multiple people can sit behind a single router.
Yes, you could use a RSA key, using RSA's PAM modules. http://www.rsa.com/node.aspx?id=1177
No, there's no real effective way to tell programmatically who's sitting at the keyboard (which is effectively what you're after). Without more details on what the service is, it's hard for me to offer exact suggestions, but one good bet might be to design the service such that it's less useful on a shared account.
If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
One of the goals of OpenID is to be resistant against the failure of any one corporation. This sounds good, but there is another problem: if the site your ID is hosted on goes down, so does your ID. I thought that there must be a login system that would be totally resistant to failure.
My idea is like this: I go to a website and I have to login. I give them my public key. The website sends me back some random data. I sign this data with my private key and send it back to them. If the signature is valid, I get logged in. This has the advantage that my ID is just my public key, so I don't rely on any external site.
To make it so that users don't have to remember there keys, the system could also optionally allow an OpenID-like system where my keys are hosted on some server and the original site redirects me there to login, and that site signs the data and sends it back to the original site, and I am logged in. This method would work similar to OpenID, but would allow me to back up my keys so if that site goes down, I can use another site.
Is this a practical system? Am I just wasting my time? Should I not reinvent the wheel and just use OpenID?
Identity cards, like Windows Cardspace, are a good alternative because they are stored on your computer and can be backed up. This is technically called the Identity Metasystem or Identity Cards.
This is different from a centralized identity service like OpenID. The good thing about the OpenID system is that the chance of everyone's identity server of going down is pretty small. However, individually, each user can possibly experience an outage.
The InfoCard system by Microsoft is a good solution, although it has not been very popular.
This is not a new problem-- email signing and encryption is a similar solution to private/public key system. GPG actually does have keystores where you can post your public keys so that people can verify your signatures.
If you're really wanting to avoid any possibility of an identity server being down(a pretty strict requirement), use CardSpace, or some other private/public key system where the users themselves have the keys, and only have to demonstrate that they have them by some challenge-response hashing algorithm.
Also, the cardspace solution is not strictly a Microsoft thing, there are plenty of applications for all operating systems. I believe it is a public standard.
This is very similar to how HTTPS works.
With your idea, you need to take good care of your private key. What if your comnputer crashes, etc. Also what about logging in from someone eleses computer? Would you trust putting a thumb drive with your private key on it into someone elses computer?
This is also very similar to what the military does with ID cards with private keys embeded on a chip that they issue to service members. A member needs to put his ID into a special reader as well as logon with a unique ID and password that must be changed periodically. This is to take care of the case where a member looses his ID and someone else trys to use it.
So I guess my answer is yes, you have a good idea, but perhaps you just need to refine it some more.
Use OpenID. It's so easy to set up and you don't have to debug it.
Windows CardSpace supports something like this. But it hasn't really taken off.
The problem with your system is that if you lose your key due to hardware problems or a system crash, you lose your only way to get to the sites you use that key for.
I would say OpenID is sufficient.
I see a couple issues with your system
I need to have that key to login. If I go out, and don't have the file on my person or hosted remotely, I'm out of luck. I also may not be able to enter it on my cell phone or some other device.
You will also need to protect the key from loss. Which likely means password protecting the key, which takes away alot of the convenience of the system.
What needs to happen for OpenID to be more resistant to ID provider failure, is for sites to allow multiple OpenIDs to be associated with an account, just like SO does. So, your idea may end being workable, but I think the effort to get it working and adopted would be much greater than the work to get widespread adoption of sites allowing multiple OpenIDs.
Also, check this link for a description of TLS Client Authentication