Showing posts with label Privacy. Show all posts
Showing posts with label Privacy. Show all posts

Monday, February 26, 2018

Why you should consider using 1Password

Using an online password manager has its advantages. Let's review them.

This is a very good week for 1Password users. AgileBits reports that they have integrated the 1Password online password manager with Troy Hunt's Have I Been Pwned? (HIBP) service. I mentioned Troy in this blog a couple times and I always point his blog and his HIBP service here and to people who are somehow interested in their security online.

Have I Been Pwned?

HIBP allows you to search from 500 million passwords collected from various data breaches. Checking your passwords against this list is crucial to keep your data safe. Apart from passwords, ut can also check if your email account, a website you use or a domain has been compromised in a data breach. And there's a lot of data there. We're talking about half a billion leaked passwords.

So, HIBP has my password. Does it mean I was hacked?

Not necessarily. If it's a common password, maybe it was being used by someone else. If it was a complex one, probably.

HIBP tells me my email address has leaked, was I hacked?

Also not necessarily. But unfortunately, it's highly probable that your email is already in the hands of spammers.

Is it safe? 

Well, if Troy with all his expertise in the field cannot be trusted, who else can? Also, AgileBits and lots of other people use his services. Don't see why we shouldn't. For more info, check this FAQ.

Are my passwords kept secret?

Yes. HIBP doesn't have access to your password. Here's what AgileBits reported:
First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash. To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

If my passwords wasn't leaked, am I safe?

No. This is only a dataset of know breaches. Obviously there's way more circulating out there that neither Troy nor other researches have yet reported. Also, don't forget that a website you use may yet be exposed to a security breach meaning that your credentials can be leaked in the future. As a suggestion, keep returning to the site to make sure that your account hasn't leaked. You can also use the NotifyMe feature or even the RSS feed.

How does it work?

If you want to learn more, the video below shows how the feature works.

Benefit for 1Password users

This integration is immensely beneficial for 1Password users and I would be very happy to see more integration with HIBP. Basically because the service will notify you upfront that you're using a weak password.

Conclusion

This is a very welcome feature to 1Password and I sincerely hope that more websites integrate with that tool. I also urge you to start using that service or any tool that generates more secure password. In the meantime, let's all thank Troy for his awesome work, shall we?

References

See Also

For more posts about Security on this blog, please click here.


[Update June 16th, 2020]: Good news! Dropbox also released its password manager!

Monday, February 19, 2018

About the Freedom Mobile Hack

It seems that everyday some company is hacked (for the same reasons). Let's see why.
Mobile syrup reported in 2018 that an anonymous hacker posted a very detailed post on Freedom Mobile's subreddit about how they managed to access customer sensitive data on FreedomMobile.ca. While this wasn't confirmed, let's stop and evaluate certain aspects of the hack from different sources.

The Code

According to the report, the hacker mentioned it only took them 23 lines of code.. While anyone can guarantee this source is reliable, depending on how it was implemented, it indeed may have been possible to build a simple python script to perform username enumeration and password bruteforcing if the necessary prevention mechanism isn't in place.

The Login Widget

I inspected the code as soon as the news was out and collected some data. On Feb 15, 2018, the login screen just after the news offered that apart from username/password, we can also login using Phone number / PIN. If you were the hacker, which login you think would be easier to guess? A password (that can be anything) or a PIN composed of 4 numeric chars? 😉

Reviewing the Phone Number widget

I'm interested about this Phone number / PIN thing because PINs are usually simple and often are used to access your device from the phone. So, they should be numerical. Let's see what the source tells us:

From the screenshot we see that:
  • they're using Angular which has its flaws. Are they running the latest version?
  • some validations happen in the front-end (I hope they revalidate in the the web server);
  • that specific validation is done using Regex (pinRegEx).
  • the min/max length: 4 chars (see the red box on the right there);
  • the "PIN not valid" on the left shows up for non-numeric chars;

Estimating the Complexity

So, a mobile number and 4 numeric chars. How complex can that be?
  • mobile numbers are public.
  • PIN requires 4 numeric characters = 10 ^ 4 or 10,000 combinations

Brute Force

So, knowing your phone number, it takes the hacker, on the worst case, only 10,000 guesses. And it can get better. For example, if your pin were 1220 (Dec, 20) it would have taken me 10% of the time to guess your password.

Username Enumeration

The above has nothing of fancy, complex or undocumented. In fact, username enumeration and password bruteforcing are present in OWASP's CSRF Prevention guide and are part of OWASP's top 10 web application risks.

The hacker confirms it:
Source: https://mobilesyrup.com/2018/02/12/freedom-mobile-security-breach/

No brute force prevention

Sight. No brute force prevention. No account lockout? No MFA? No alerts. Probably not. Worse, the company ignores the issue, states the corporate jargon and returns the responsibility to users (as if a system based on 4 digit numeric PINs, no bruteforce or password enumeration prevention were secure enough):
“We continue to strongly encourage our customers to use unique PIN numbers that are not easy to guess, and to change their PINs frequently to best protect their personal account information. (...) meeting customer demands for a resonable login process.”

Shared Responsibility

Before we wrap up, there are two more things about this hack that are worth questioning:
  • who's responsible the decision to simplify the login by using the phone/PIN widget?
  • who's responsible for not preventing brute force without any lockout mechanism or alert on the login operation?
While I don't want to discuss who's responsible for what, I don't see the developers deciding how people should perform the login on the company's website. Certainly the ability to brute force such a crucial aspect of the application was missed or ignored by the business. It's definitely a shared responsibility.

Conclusion

So, even if we assume that the hack didn't happen, 10k combinations without any prevention against CSRF, username enumeration and/or password bruteforcing is not acceptable. Everyone loses when companies try to simplify security aspects for its users but do it wrong ignoring the most critical web application security risks. In time, if you haven't read yet, check OWASP's CSRF Prevention guide.

References

See Also

For more posts about Security on this blog, please click here.

Tuesday, November 14, 2017

Why use Firefox

Understand why Firefox is still the best browser for those looking to keep their privacy online.
If you have been following this blog, you may know that I've been discussing the importance of security and privacy. If not, please read how we are being tracked without consent everywhere: by search engines, browsers, mobile apps, social networks, TVs, games, devices, etc. Turns out we're living in difficult times for those seeking privacy

My Favorite Firefox Features

Apart from its privacy-first commitment, let me list my favorites of  Firefox.

Performance

This version of Firefox is 2x-faster than a year ago, significantly faster than Chrome. Do not believe? Check the video below for a quick comparison between the performances of Firefox and Chrome.

Lightweight

Firefox made significant improvements to its new engine and now uses 30% less memory than Chrome:
Source: https://www.mozilla.org/en-US/firefox/quantum/

Development Tools

Every developer deserves an awesome development environment. Firefox Quantum ships with a completely revamped DevTools with multiple improvements included. Check more on this blog post to find out more.
Source

Privacy Considerations

As previously said, Firefox is the only browser committed to privacy. Even Brave who marketed themselves as the best privacy-oriented browser were caught replacing ads with their own and probably also tracking you.

Beautiful UI

And, my last personal favorite: the new Photon UI. Simply gorgeous:
Source: https://hacks.mozilla.org/2017/09/firefox-quantum-developer-edition-fastest-firefox-ever/

Mobile

I've used many browsers on different mobile devices and honestly, never have been completely satisfied. Lately, I've been using Firefox Focus and if you want speed, privacy in a lightweight browser, you got it there:
Source: https://www.mozilla.org/en-US/firefox/focus/

Contributions to the Open Standard

Apart from Firefox, Mozilla has been doing very important advances in open science in:
  • Gaming: WebAssembly & WebGL;
  • MDN: extensive documentation on web technologies including HTML, CSS, and APIs for both Web sites and progressive web apps.
  • WebVR: an incubator for virtual reality on the web;
  • Servo: an amazing parallel browser engine 
  • Rust: an amazing open-source programming language that focuses on speed, memory safety and parallelism.
  • Open Codecs: if you use Linux, you know what I mean...
  • Speech and Machine Learning

Conclusion

If you agree with me and thing that it's time for a more open web, more privacy and security, join me and millions of other users and start using Firefox again! So what are you waiting for? Go get your Firefox right now!

See Also

Monday, October 16, 2017

Securing your front-end

How secure is your front-end and how much could it be? Let's discuss it on this post.

An extremely common and dangerous flaw in web apps security is relying solely in client side security as we already discussed on this blog here and here. On this post we’ll examine the most frequent mistakes developers make and how to protect from them. But before we proceed, check our previous discussions on web application security. For all the topics on security, please click here.

Law of Security #4

We already reviewed the 10 laws of security on this blog. So, you may recall our Law #4:
If you allow a bad guy to upload programs to your Web site, it’s not your website any more.
That's probably, the main (but not the only) reason why web applications are so insecure: users are constantly submitting data to your application and changing data state. So what should we do? 
Should you trust all data being submitted to you?
No.

Can you trust data from cookies sent to you?
No.

Can you trust everything that you are getting in your web application layer?
Of course not.

You cannot trust client side security

Because you don’t have control of what runs on your client or how that information is being submitted - if it was manipulated or came from a different source than you expect - you should never trust the data you are getting in a request. That's why you should always re-validate in your server data sent to you. The only actual info you should trust is the session, stored on the server.

So what are the most common mistakes?

In the context of web applications, the most common mistakes web developers make are:
  • Hiding info in hidden fields
  • Relying on Http cookies
  • Relying on Url parameters
  • Using Form action urls for backend logic
  • Using the Referer header for backend logic
  • Trying to be cryptic or to obfuscate info
  • Rely purely on the ASP.Net Viewstate
  • Rely only on html form attributes
  • Only run Javascript validation

Mistake #1 - Hiding info in hidden fields

In the past, developers used to hide essential information in hidden form fields as:
<input type=”hidden” name=”price” value=”45”>
So when a post was submitted to the server, something like the below would be sent:
POST /page.aspx HTTP/1.1
Host: mysite.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
quantity=1&price=449
Hacking this application is as simple as:
  1. changing the price value using devtools and resubmitting the form;
  2. issuing a post from a different tool to the server.
Luckily, this anti-pattern is no longer common anymore.

Solution

The solution here is simlpy not use hidden fields to pass sensitive information to the client. Use the Id of the product or some other type of identifier instead.

Mistake #2 - Relying on HTTP cookies

This one is less common but is still being used. Developers are still saving sensitive information in cookies, which are stored in the client side and can be easily manipulated. Consider this response from the server:
HTTP/1.1 200 OK
Set-Cookie: Discount=20
Content-Length: 100
Assuming that the Discount value set in the cookie was used to perform some calculation in the server, a malicious user could easily change that information to 100 for example, and get the product for free. Not what we want.
POST /store.aspx HTTP/1.1 
Cookie: Discount=100
Content-Length: 10

Solution

The solution here is simlpy not use cookies fields to exchange/store sensitive information to the client. If you need to save, save it on the session, on the server. Upon each request, get the session value and process it from there.

Mistake #3 - Relying on Url parameters

Often, urls are very easily hackeable:
 somesite.com/store/view?prod=3&price=100
Anyone using a web browser or curl for example could alter that url and, if that property was used to provide the price to the server, alter it and benefit from your security issue. Others can be more obscure but also open to attacks:
 somesite.com/store/view?prod=3&price=100&price_tkn=VJ58k6UxCFdUHiVj
 Remember that security trough obscurity does not work flawlessly.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #4 - Using Form action urls for backend logic

Similar to mistake #3, hidden but still modifiable, form actions can also be used to pass information :
<form action="/store/submit?discount=10">
...
</form>
Remember, this approach could be easily manipulated.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #5 - Using the Referer header for backend logic

Less common, the Http Referer header can be used to simulated authentication logic in the server. For example, a request like:
GET /auth/CreateUser.aspx HTTP/1.1
Host: mdsec.net
Referer: https://mysite.com/auth/admin.aspx
Could be interpreted in the server that the user indeed came from the admin page. While this could be true for non-malicious requests, it could also be manipulated.

Solution

Avoid using the Referer for authentication as can be easily manipulated in the client side.

Mistake #6 - Trying to be cryptic or to obfuscate info

We already provided an example in mistake #3. Trying to be cryptic or obfuscating information is not a 100% reliable solution. Yes, it could be used as part of a solution but should not be the sole solution.

Solution

Be creative securing your services and avoid security trough obscurity.

Mistake #7 - Rely only on html form attributes

Html form attributes like maxlength and disabled are nice but can be easily circumvented by simply removing them in developer tools or by submitting. Example:

Solution

Keep using those components to provide more friendlier applications but never rely only on them to validate your data. Always have similar validation in the server and in the backend if necessary.

Mistake #8 - Only run Javascript validation

As in mistake #8, relying solely on javascript is highly insecure as javascript can be disable or be easily removed, altered or manipulated in the client machine.

Solution

Make use of javascript to serve more friendlier applications but never rely only on it to validate your data. Always have similar validation in the server and in the backend if necessary.

Conclusion

So there you are, hope this post has helped you identifying the threats your app may be facing and how you could protect against them. But only for your front end. Remember, security is complicated. Securing your frontend is just another piece in the complex effort towards a good security framework.

See Also

  For more posts about ASP.NET on this blog, please click here.

Monday, October 9, 2017

Privacy and Ethics

Security, Ethics, Privacy and Confidentiality. How's everything related on today's internet.
On a previous post we discussed Security and Ethics. Today we follow up on Ethics and Information Privacy and discuss privacy and ethics.

We're living interesting times. Around 10 years ago, the biggest ad agency of all time started tracking and reading personal information. Now it has expanded from your browser to, basically, everywhere. In case you are not sure what I mean, let's examine where tracking is happening.

Tracking is Everywhere

Tracking today happens on:
  • E-mail providers: Gmail, Outlook, Yahoo! and everyone else is reading your email. What about you? Are you reading your own emails? 
  • Search Engines: where do you think that Google, Bing, Yahoo!, et al get their money from? But wait! We seem to have an option that does not track you. 
  • Social Networks: every social network these days tracks you and reads your data. And they make a lot of money. 
  • Companies:Google, Apple, Microsoft, Facebook, Amazon and everyone else is tracking you not only by using their services but, if you're using their gadgets, you're probably being tracked there too! 
  • TVs: smart TVs like Samsung TVs are spying on viewers. 
  • Smart devices: Smart devices like these, are tracking users:
  • Virtual Assistants are tracking us: virtual assistants are also tracking their users:

Tracking and Privacy

But people are starting to note that privacy invasion is becoming or will become an issue. And that is a good thing!

Maybe this change is happening due to the impacts of the recent very important data leaks on Equifax and Deloitte, or because their personal pictures leaked online or, because their Dropbox, Adobe, LastPass, personal e-mail, mobile operator, and so many other services suffered a leak and they lost confidential information and/or were victim of a scam/phishing/smishing, etc because of those leaks. Who knows? It doesn't matter.

What matters is that the society as a whole needs to be aware of how our privacy is being disrespected and start demanding for a change. Unfortunately, neither governments nor companies are doing their share and remain doing all that's possible to get access to your data - ethically or unethically. But why is that happening?

Remember: If a product is free, you are the product

As we already discussed that on the Security and Ethics post why is this all happening? Why now?

To understand that, we first need to reflect on why would a company give their products for free? Since the majority of them are not charities,  maybe this is happening because, they make tons of money out from your data and ads


For example, here's how Alphabet (Google's parent company) makes money (88% from Ads):

Source: http://www.visualcapitalist.com/chart-5-tech-giants-make-billions/

And here's how Facebook makes money (97% from Ads):
Source: http://www.visualcapitalist.com/chart-5-tech-giants-make-billions/

US$ 106 Billion / year in revenue from Ads

As show in the previous charts, advertising generates 88% and 97% of their revenues to Google and Facebook respectively. That's USD 106.36 Billion per year from your data. All from "free products" like Facebook, Gmail, YouTube, Instagram, Android, Google Docs, etc That's why they say thatif a given product is free you are the product.

All that said, we should be concerned. Not because we're doing stuff we're not supposed to do or because we're being injected too many adds but because your information is being scanned without consent or further notice.

This is not a financial but an ethical decision. It's not about stock prices or revenue per user.

Privacy concerns have reached a limit and people are starting to realize that. You can see by google searches decreasing (more on that later), or increase in utilization of tools like DuckDuckGo (which I recommend using), even by the increase in adoption of free/open software projects like LibreOffice or Firefox that do not track your data. Not because they are better but because they are safer and more trustworthy - If I can read the code, I can trust it.

Privacy - What are our options?

Then where should we be? What should our companies be doing? This is what would like to see: companies that explicitly care about your privacy and how the internet and our lives will be better if everyone cared about that.

Here are my humble suggestions.

Browser

My browser of choice is Firefox. Yes I know there are other options but for my daily use (including development) works very well.

Search Engine

I believe my search engine shouldn't track me. That's why I use and recommend DuckDuckGo.

Operating System

I want privacy in my desktop operating system. That's why I use Fedora Linux.

Phone

I wish a modern phone that respects my privacy and runs all the apps I like. Who knows the Librem 5 or the PinePhone one day doesn't happen? I'm closing monitoring their development and it's getting close, real close!

Final Thoughts

Think about it. Think about the necessity of protecting our privacy, our families' privacy. Think about the impact it can have in 20, 30 years from now. Think how can we make the web and our lives safer for ours and future generations.

See Also




Update [Mar 13, 2018]: There is a very nice description on why you should consider migrating from LastPass here. 
Update [Mar 13, 2018]: Good News! Purism just showed some updates on the Librem 5 phone here

About the Author

Bruno Hildenbrand      
Principal Architect, HildenCo Solutions.