In this post, we're going to switch it up a bit (again). Everyone knows security is important, but not many people actually use strategies to keep their coins safe from trivial bugs and compromise. Let's talk about not only what you shouldn't do, but how to do it better. It's not about being completely safe, that's not how it works. It's about reducing your risk and being safe from attacks can be easily prevented and then one can build up from there.
This is a continuation from part 1
https://steemit.com/crypto/@thescoop/cryptocurrency-user-security-tips
If you haven't read it we recommend you do, but they don't need to be read in any particular order.
Short answer: yes, according to Signal Support, the latest beta releases (at the time of this writing) allow you to enable a Registration Lock Pin which will be required in order to register your phone number again with Signal.
Other than that, it's seamless encrypted messaging for you and Signal friends, and works fine with non-Signal, regular SMS users as well. Not really a reason not to be using Signal these days as it integrates super well and looks like a native messaging app. The Signal team is founded by a trustworthy team and you can be sure, more than any other company, it's not secretly snooping on you.
Get it now, it's easy and works:
There are carrier attacks. Just use Google Authenticator where available (most places), it works and isn't vulnerable like text messages are. Or confirm's via email as they hack to hack your email first, one more 'thing to do' for attackers, if you will. But yet I don't hear anyone screaming that...
Age old question which one really doesn't get much out of for asking, honestly. It's like saying, which is more secure, Android or iPhone, Toyota or Ford, sunglasses or baseball cap? Mostly it depends on who the user is, what their security goals are and risk tolerance and what kind of environment they'll be exposed to. For example, many people say "Android security sucks", but Android having roughly 80% share of the entire mobile device ecosystem means they have to worry a lot more than anyone else, including i* Devices. Does Apple's security model overall happen to be work better in the real world? Maybe, but the scale and ecosystem is way different to produce an accurate comparison.
If you're a spy, your threat model is different than a troll on the Internet. If you're a company, you'll have different risks than someone who casually browses Reddit. Which one of these actors should use Windows and which should use Linux? Doesn't make a lot of sense to ask that knowing the context now, right?
Windows is produced by the Microsoft corporation, whose goal is, rightfully so, to make money for it's shareholders. It's almost completely closed source (save for the recent github stuff and leaks throughout the years) and their model these days to is make more money via ads and connect everything to the cloud.
Linux comes in many different distributions, some of which contain apps that don't have their code public and others which the mantra is strongly "everything open source". The most popular distros for regular users being Ubuntu, Fedora and Mint (I guess) and for companies/servers being the likes of RedHat, Ubuntu and CentOS.
If you're a user, your threat model looks something like this...
That's the major ones at least.
Windows and Linux both provide a security model and a ton of protections for each. Windows has by far the majority of market share, so attackers write exploits and post-compromise tools such as trojans and backdoors much more often and to a highly quality for it than anything else. Maybe you hear Windows get mentioned in the news for security bugs all the time. Sure, it's true and there's plenty for them to improve upon, but no one is targeting iMacs and PCs running Linux relatively speaking, so they don't get many headlines. Which is good news (pun intended) for them, but again doesn't paint an accurate picture of the the security between the two.
Windows has more attack surface due to it's infinite features and new ones added all the time, but also has many more advanced security features than Linux, mostly because it's obviously funded well and the mitigations are needed to keep customer trust. There's merits to arguments that OSS has more eyes looking at it, so it's easier to find and fix security issues. But the stats for that don't quite add up the way you'd think. Although if Windows became open source tomorrow, you see a ton of new security bugs found the following day. Not as easy to reason about as you might think, right?
One could go on for days with many valid points for and against each OS. I'd say if you use Linux, you'll be less targeted by malware, but not gain much for an attacker who really wants to own your box. If you use Windows, there's tons ways to reduce your attack surface and maintain a fairly plan to mitigate threats that pertain to your model. The OS doesn't matter nearly as much as doing what you need to do to make yourself less vulnerable to common attacks. All the other topics and strategies covered in both part 1 and 2 should be the real focus.
That's not how that works. Just think about the fundamentals of an application: it allows someone to access something. That's it. There's not some magic that ensures someone else can't access your stuff, it's just code. Code is written by humans, who aren't perfect and make mistakes. Therefore code has bugs, it's a fact. And the more complex code it is, the more bugs it has, whether someone spots the bug today or 5 years from now, it still exists.
So, assume if you can access your stuff, the app is just one or two bugs away from anyone else being able to access your stuff. Just because you don't know about the bugs doesn't mean they don't exist. Even though you've never been to the bottom of the ocean, you'd still believe it's there, right?
Security isn't something tangible you can buy or build, it's just layers of risk the dev chooses to opt-in to or, more often than not, not opt-in to. All those ads for 'security in a box' stuff is, for the most part, garbage. Anti-viruses, while detecting malware from time to time, actually add a bunch of other crap that should never be there and increase your risk.
Just google for it:
https://www.google.com/search?&q=antivirus+exploits
Not saying AVs aren't useful, but it's also a fact that they can do more harm than good depending on your environment and risk level.
But that puts one into a no-win situation, which is uncomfortable: there is no security and no matter what I do, there will always be bugs which present risk to my stuff. Sorry, it's better to know an uncomfortable truth than a convienent lie. Somebody said that once.
Ok, really though, what do I do if security doesn't really exist, it's just a concept of risk levels? Well then, you reduce your risk. This blog along with Part 1 of it is full of (NOT FINANCIAL) advice on how to do that.
It's a horribly insecure language which makes simple tasks hard to get right security-wise which makes it easier for attackers to compromise your website.
Not convinced?
~3.5 million search results for 'php vulnerability' -> https://www.google.com/search?&q=php+vulnerability
Do you want anyone to be able to deface your website, delete your server or gain access to your email accounts or database info? No? Then don't use PHP; there are plenty of better, more modern languages for building projects and webpages that support many security features by default, such as Ruby, Node.JS, Go and even Python.
More information:
http://technosophos.com/2015/08/22/time-for-an-alternative-to-php.html
Also avoid CGI scripts, Perl and ASP.NET while you're at it. The safest website is one that is HTML-only and no user input. Once you've removed the web content attack surface, focus on your server, make sure you use passPHRASES and not passWORDS and everything is up to date.
"But this new project is in PHP and it's so cool" --> why? Just because it's not a fork doesn't mean it's a great project. Writing a project in a language that universally should be deprecated isn't what many would call a solid ground. There's always better ones out there and quoting it's interesting specifically because it's written from scratch in PHP is like saying, "This car is so cool, it's made of steel and runs on diesel and has those manual locks, so quaint!".
Then why do people use PHP? Because maybe they know it, or they're bored and it's relatively easy. It's also easy to get rekt. Don't get rekt.
If you're posting eth addresses on your website for people to send funds to during the ICO exchange, your #1 priority should be that the website is as secure as possible. If anyone manages to be able to change the content on the website, or redirect users to another site that looks the same (phishing) but shows them a different deposit address, it's game over. Don't let that happen!
How do you secure it? See the section above first of all. Notably, as it mentions, use a HTML-only website (no fancy JavaScript where possible) and don't allow any user input of any kind. If you need an email sign-up form, make sure to strip all special characters and only allow alphanumeric chars, @'s and .'s and nothing else. Harden that code as much as possible.
Make sure the server you host it on is ONLY running the web server and SSH or a simple remote access program if necessary. Make sure all passphrases are long and don't share them around. Each person who shares access puts another weak spot in the chain.
Make sure the server is running SSL/TLS. You can verify this by a green 'Secure' bar on Chrome and https:// is in front of the website's URL. This prevents, among many other things, snooping and man-in-the-middle attacks.
Unfortunately for almost all programming and scripting languages, security isn't implicit. Secure by default isn't yet a widely adopted concept. So when you ask most people, "Is your code secure?" they often answer, "Yes, of course". But how can that be true? If they aren't a dual dev and security expert, how could they possibly be writing secure code?
Naturally devs have egos, it's part of the rinse-and-repeat, this is my baby, I'll finish this project work ethic that allows them to type on a keyboard for hours in the first place. They all think, or want to think, they write good code. It's all relative, but it's also healthy to take a step back and constructively question quality, the security of the code and implement code reviews. Professional developers do this. We should strive to be more like the pros, right?
The basics are quite simple. If there's an interface, field, format or otherwise input area that takes data from outside the program (from a user or other app) and does any kind of operation on it (display it, add it together, concatenate it, log it, etc),
it should be hardened.
Now for a simple exercise: once you've identified these functions or files that use this input, ask the following questions:
Those are a few of the major things to check for, but the list extends based upon the context and environment of your code.
One can simply error-out and reject the malformed input if so. It doesn't mean your users are directly trying to crash the program or get the system into a bad state, but maybe they are, or maybe other-meaning users that are unknown to you are trying to. Who knows, so better to invest in hardening the interfaces beforehand when it's cheap than to get randomized later fixing bugs after potentially cleaning up a compromise of the platform too, putting your users and project reputation and potentially funds at risk in the meantime. Invest in hardening and doing security now to save time/headache later.
The folks are Trail of Bits, Block Audit, NCC Group all have experience doing professional security work on crypto products. Much cheaper and wise to invest in security on your own time before you find out stuff is broken and deal with all the exploits.
People say this a lot without much thought, but the fact is most of the time you cannot verify. Think gmail isn't secure? What would happen if you emailed their support and asked for records of internal bug fixes vs open issues, pen-test reports, diagrams for exactly how they encrypt and where they keep your data? They don't usually make that stuff public and for good reasons, but the point is you don't know and you can't really know, so you can't verify. You must trust certain sites and services which make your life easier. Or don't and create your own, but that's expensive, or just have a life without the benefits they provide which is respectable as well.
Protonmail vs Gmail? Eh, either way. Protonmail is obviously more secure, but Gmail is easier. But there's not a lot of day-to-day difference it's going to make unless you're super paranoid and encrypted services like that are actually necessary to mitigate the risk of data loss and give you comfort. But have you audited Protonmail? Maybe there's some critical bugs they have, yet no one knows about until it's public (or not). There's tradeoffs each way.
Just don't give you data out when you don't absolutely have to. Giving it to a (legitimate) exchange for ID verification, it's best it's accurate. Giving some rando or airdrop or otherwise your real email? Nah, no way. It's too easy to make new ones just use disposable email options and plugins for the browser, like the one from dispostable.com.
Just downloaded a new wallet? Run it over virus total, isolate it on an untrusted VM or just forget it, trade the risk for keeping it on the exchange if you can stop yourself from trading it later. It's super easy to put a new backdoor that isn't detected in a wallet and drop it on github or whereever. Don't think because a virus scanner said "ALL GOOD" that it's really the case. So now you're going to go 'read the code and check it for backdoors', right? That's probably going to fail too as only experts with tons of time to devote will actually do that job the service it deserves. Truth is, it's hard to mitigate this risk. Best to just not download and run the wallet, or put it on a throw-away VM where you don't care if it gets compromised and just monitor it for suspicious stuff (opening ports, sending network traffic to other hosts you don't recognize regularly, creating txt files, using protocols that aren't part of the spec, etc).
And that's your scoop!
Don't forget to follow me on InvestFeed (Twitter+Facebook for Crypto nerds):
https://steemit.com/@thescoop
