Should I use CSRF protection on Rest API endpoints? Quick note: this is not a duplicate of CSRF protection with custom headers (and without validating token) despite some overlap.  That post discusses how to perform CSRF protection on Rest endpoints without discussing if it is actually necessary.  Indeed, many CSRF/Rest questions I've read on this site talk about securing the endpoints via CSRF tokens without actually discussing whether or not it is necessary.  Hence this question.

Is CSRF Protection necessary for Rest API endpoints?

I've seen lots of discussion about securing REST endpoints against CSRF attacks, but having given the topic lots of thought, I'm very certain that CSRF tokens on a REST endpoint grant zero additional protection.  As such, enabling CSRF protection on a REST endpoint just introduces some useless code to your application, and I think it should be skipped.  I may be missing something though, hence this question.  I think it will help to keep in mind why CSRF protection is necessary in the first place, and the attack vectors it protects against:

Why CSRF?

It really boils down to the browsers ability to automatically present login credentials for any request by sending along cookies.  If a session id is stored in a cookie the browser will automatically send it along with all requests that go back to the original website.  This means that an attacker doesn't actually have to know authentication details to take an action as the victim user.  Rather, the attacker just has to trick the victims browser into making a request, and the credentials to authenticate the request will ride along for free.

Enter a REST API

Rest API endpoints have a very important difference from other requests: they are specifically stateless, and should never accept/use data from either a cookie or session.  As a result, a REST API that sticks to the standard is automatically immune to such an attack.  Even if a cookie was sent up by the browser, any credentials associated with the cookie would be completely ignored.  Authentication of calls to a REST API are done in a completely different fashion.  The most common solution is to have some sort of authentication key (an OAuth Token or the like) which is sent along in the header somewhere or possibly in the request body itself.

Since authentication is application-specific, and since the browser itself doesn't know what the authentication token is, there is no way for a browser to automatically provide authentication credentials even if it is somehow tricked into visiting the API endpoint.  As a result, a cookie-less REST endpoint is completely immune from CSRF attacks.

Or am I missing something?

I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints.

No cookies = No CSRF

It really is that simple.  Browsers send cookies along with all requests.  CSRF attacks depend upon this behavior.  If you do not use cookies, and don't rely on cookies for authentication, then there is absolutely no room for CSRF attacks, and no reason to put in CSRF protection.  If you have cookies, especially if you use them for authentication, then you need CSRF protection.  If all you want to know is "Do I need CSRF protection for my API endpoint?" you can stop right here and leave with your answer.  Otherwise, the devil is in the details.

h/t to paj28: While cookies are the primary attack vector for CSRF attacks, you are also vulnerable if you use HTTP/Basic authentication.  More generally, if the browser is able automatically pass along login credentials for your app, then CSRF matters.  In my experience cookies are the most common technology being exploited to make CSRF happen, but there are some other authentication methods that are used which can result in the same vulnerability.

REST = Stateless

If you ask someone "what is REST" you will get variety of answers that discuss a variety of different properties.  You can see as much because someone asked that question on stack overflow: https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

One property of REST that I have always relied upon is that it is stateless.  The application itself has state of course.  If you can't store data in a database somewhere, your application is going to be pretty limited.  In this case though, stateless has a very specific and important meaning: REST applications don't track state for the client-side application.  If you are using sessions, then you are (almost certainly) keeping track of client-side state, and you are not a REST-full application.  So an application that uses sessions (especially for logins) that are tracked via cookies is not a REST-full application (IMO), and is certainly vulnerable to CSRF attacks, even if it otherwise looks like a REST application.

I think it is worth a quick note that one reason that client-side statelessness is important for REST applications is that the ability of intermediaries to cache responses is also a desirable part of the REST paradigm.  As long as the application is tracking client-side state, caching is not possible.

Rest ≠ Cookieless

For these reasons, I initially assumed that a fully-compliant REST application would never need sessions, never need cookies, and therefore never need CSRF security.  However, there is at least one use-case that may prefer cookies anyway: persistent logins.

Consider a typical client-side (in this case browser, not mobile) web application.  You get started by logging in, which uses a REST API to validate user credentials and in return is given a token to authorize future requests.  For single page applications, you can just keep that token in memory, but doing so will effectively log the user out if they close the page.  As a result, it would be good to persist the state somewhere that can last longer than a single browser session.  Local storage is an option, but is also vulnerable to XSS attacks: a successful XSS attack can result in the attacker grabbing your login tokens and sending them off to the attacker to be used at their discretion.

For this reason, I have seen some suggest using cookies to store login tokens.  With a cookie you can set the http-only flag, which prevents the application from reading the cookie after it is set.  As a result, in the event of an XSS attack, the attacker can still make calls on your behalf, but they can't walk away with the authorization token all together.  This use of cookies doesn't directly violate the statelessness requirement of REST because the server still isn't tracking client-side state.  It is just looking for authentication credentials in a cookie, rather than the header.

I mention this because it is potentially a legitimate reason to use cookies with a REST API, although it is obviously up to a given application to balance the various security and usability concerns.  I would personally try to avoid using cookies with REST APIs, but there may very well be reasons to use them anyway.  Either way, the overall answer is simple: if you are using cookies (or other authentication methods that the browser can do automatically) then you need CSRF protection.  If you aren't using cookies then you don't.


Asking for an SSL Certificate from the Client I have created a web application for a client and I'm hosting it on my own server behind a domain I own. I have purchased an SSL certificate for this domain and the web application runs nicely over HTTPS.

The client has now created a CNAME record for his domain, pointing to my domain. But users who visit the application through his domain see a big SSL warning from browsers as the installed certificate is not for his domain.

The client is a huge multinational company and asking the relevant department for a correct certificate could take a long time. However I'm not even sure whether such a request would be reasonable at all and whether certificates would be passed around like that. Is there a certain best practice in solving such problems?

Update: I think I should clarify that the client's domain will be used for the final product and my domain will be out phased once the official switch has been made. So I basically want to know what is technically the easiest way for the client's tech department to help me out with securing the connection. So I do not need to secure both domains at the same time. Is it feasible for me to ask them to provide me a certificate for this domain or is there an easier way around it as they are already pointing to my server.

The trouble is that with HTTPS, SSL occurs first, and then HTTP within the SSL tunnel. When the server is contacted and must send its certificate, it does not know yet the server name that the client wants to talk with (the name for the URL that the client sees).

There are mostly three methods out of this:

Use a different IP for each name. When the connection occurs, the IP address used by the client is known to the server, so the server could serve a different certificate based on that address.
Use a certificate with several names. The client wants to see the intended server name in the certificate, but there can be more than one name in a certificate. The Subject Alt Name certificate extension can contain a lot of names (Google's certificates contain more than 70 names !).
Have the client announce the intended server name sufficiently early in the SSL handshake. There is an SSL extension for that: Server Name Indication. The good news is that most Web browsers implement it. The bad news is that only most Web browsers implement it; in particular, Internet Explorer on Windows XP does not (IE 8 on Vista and later supports it, but not on XP).

See this site for statistics on Web browser usage over the Internet (use them as estimates, not as gospel; any given user community may exhibit different usage patterns). As of today (October 2013), IE 8 is announced at a bit less than 10% market share (the site does not say how many of these run on WinXP, but I'll bet that most of them do).

Method 3 is the "best practice", or at least will be the best practice in the near future. It is also the only method that you can implement right away without asking your big client to change his DNS or to request a certificate with the extra name.


Why Sniff Session Cookies when UN/PW should also be available? I've recently been reading on session cookies and how they can be hijacked via man-in-middle attacks. It seems this is mainly possible on an unencrypted connection between a client and a webserver.

However, I cannot figure out why, if one is already 'in the middle' of an unencrypted connection, would one prefer to capture the cookie instead of the username & password which should also be sent in plaintext?

There are 2 main reasons why cookies are easier to steal than login credentials:

Cookies are sent for every request, login credentials are only sent once for each "session"

If you sniff a network, it is less likely that you will be in place at the point when a user actually perform a login using its username and password.

Cookies on the other hand, are sent for each request to the web server. It is just more likely that you will be able to capture a session cookie than a username/password autentication.

It is hard to predict which GET/POST parameters that contains login credentials

Sniffing the actual authentication credentials on the web can be a bit tricky. This is because virtually every web application have its own way of doing it. It is hard to anticipate all the various authentication URL's.

For example:

GET /login?username=dogeatcatworld&password=letmein
GET /auth?u=dogeatcatworld&p=letmein
GET /auth?auth=<base64encoded credentials>

Cookies on the othe hand, always exist in the HTTP header, and it is trivial to extract these from the requests.


Can a virus infect source code files with dangerous data? If a user was infected with a file altering virus is it possible that checked in code (files containing text) to the source control could contain dangerous properties.

I ask this after this got me thinking:

  Installing a new version of the operating system over the compromised
  operating is not a good solution as files may have been altered that
  could affect the new system. Even copying business critical
  information from a compromised system is a risk as that data may have
  been altered in some manner by use of the backdoor.

If so how would one clean up the code base?

Yes.  As early as 1990, Peter DaSilva had circulated a cautionary tale about a source code virus. It reads a lot like a design document for such a virus. I don't believe that one was ever implemented, or at least nobody I know of has confessed to trying it.

In 1989, the Usenix Association published Computing Systems Volume 2, Number 2. This had an article, Virology 101, by Doug McIlroy. That article walks you through writing a shell-script virus, which infects source code. I think that shell-script virus would work today, probably requiring minor syntax fix ups.

I'm not at all sure how you'd go about cleaning up a code base that had been messed with by some kind of source code virus.  If you had it in version control, you could revert to a pre-virus version, and then carefully construct patches to bring the code base up to date, but without the self-reproducing code of the virus in it.  Seems like a lot of work.


Need to infect a computer for testing - how do? I'm trying to infect a laptop with malware for testing purposes and I just can't seem to do it. I've been searching for .exes that will just RUN and I can't find anything straight forward. Looking at this site all I can find are raw binaries but nothing really packaged and ready to go--unless I'm not looking in the right place.

It seems that a lot of malware research sites are geared towards software development and the actual investigation of the code itself but I just need an .exe that will work.

I never thought it would be this hard to deliberately infect a computer. Can someone please give me a link to a malware .exe or give me some tips on how to do this?

For testing purposes, use the Eicar test file. Just copy it onto your machine, no need to install.

There are even variants, such as zipped and double zipped versions of that non-malicious test virus.


Do you know any crawler/spider software, which is able to go through an ASP.NET site? Do you know any crawler/spider software, which is able to go through ASP.NET application, not ASP.NET MVC, but the one full of __doPostBack JavaScript functions on every link/button/change event?

If there is no such application - how do you start inspecting ASP.NET web sites? My approach is usually  to search all *.aspx files in the application folder and the one-by-one checking if it is possible to reach the page without parameters or trying to reach it through web site GUI, which is real time killer.

JavaScript links are a real problem for automated spidering.  Personally I tend to use Burp suite and manually build up a page list by navigating the site, and then use page by page scanning.

In theory the way to do it would be to use a spider which relies on the browser engine itself to do the spidering (so some of the tools which "drive" a browser might be useful).

Another option would be to get a JavaScript parsing engine available in your programming language.  One thing I saw which may be useful on that front is this project from rubyracer, which allows access to a JavaScript parsing engine from within ruby.  I've not tried it , but I was thinking that it may be possible to use something like that to evaluate JavaScript on form submissions and extract the appropriate URL for the spider to follow from that.


Dangers of hosting an internal web application on a public web server? Is it a bad idea from a security perspective to host both a publicly accessible website and a website that is only intended to be used internally on the same server?  Obviously the web server would be configured to only allow access to the internal web application to specific internal IP addresses.

Are there any security risks that I should be aware of with this configuration?

UPDATE:

In my situation I am using the following technologies:

ASP.NET
SQL Server
Windows Server
IIS

But I would be curious if there are any concerns that I should be aware of regardless of technology.

It is a bit difficult to answer in detail when you don't supply critical information such as the system architecture, platform, web server, and framework(s) involved. If things are done right, the risk is negligible. To know whether they're done right and will continue being done right... ay, there's the rub. Which depends on the information I was talking about.

Lacking that information I'm going to pepper my answer with might's and sometimes's; please bear with me.

  Are there any security risks that I should be aware of with this configuration?

I can think of some of them, but others surely exist. Many of these are based on the assumption that a vulnerability might exist on the public site, and refer to whether and how it could influence the private site.

session hijacking and gleaning. On some platforms (mainly PHP and *AMP stacks), session data might be stored on the file system, and it might be queryable to any process. Which means that a rogue process on the public web server could enumerate or guess the session data filenames, read them, and disclose information that might be critical.
authentication bypass. Again depending on the platform, it might be possible to trick the secure site into allowing access to a user of the public site. This doesn't bypass network address check, so if you deny private access to external addresses, this specific attack vector is thwarted.
denial of service. Of course, the private site shares some resources with the public site, and can be subject to a denial of service that way.
cross-site attacks. This depends too much on the site's structure to give details. Broadly said, there are security measures in place to avoid victimsite.com to supply code that calls home to evilhost.com. Many of these measures work less, or not at all, if the two sites are of the form public.site.com and private.site.com. This vector of attack involves someone supplying a link to the public site to a victim on the inside (e.g. through an e-mail), and cross-site scripting code on the public site that would attempt to steal information or wreak havoc on the private site. If this works, i.e., if the public site is vulnerable to this kind of attack, then it will work much better on the private site on the same domain, than if it was on a different domain.
shared, shareable, or forceable connections. If the public site is broken into, an attacker is already inside the identification perimeter of the private site. Assuming he can recover the needed credentials (and on some platforms, this is possible - it requires non-default hardening to prevent it), he can identify himself to other hosts, e.g. the database with confidential information, and stand a much better (on most *AMPs, approaching 100% from the wrong side) chance of being allowed access.
code-level access. This isn't too likely, for it would require other vulnerabilities, to wit: write access by the Web server process, and same level of access between subprocesses belonging to the public and private sites. Still, except for a few happy exceptions (Debian and Ubuntu), this is often the default configuration unless specific steps are taken by the sysadmin. At worst, this allows a vulnerability on the public site to grant an attacker full access to everything from passwords onwards relating to the private site, as well as modifying information and reporting, intercepting some kinds of traffic (think "webmail"), and destroy data.

On a properly secured system (e.g. here, points 6 onwards; some pointers on PHP; and of course OWASP), I'd have few worries. Still enough to ask myself, must I really do this?; it's not like server space is all that expensive anymore. But very few. Especially if the sysadmins keep up with the necessary advisories.

On the other hand, placing a private and supposed-to-be-secure site on a system installed out of the box and not too well maintained (e.g. a stock Wordpress installation) is tantamount to conjuring up Murphy at its worst, and I can't advise too strongly against it.


Can you access another program's memory with malloc? I know this is very system dependent, but say we have a program, call it Program A. It contains sensitive data that a hacker wants to get into. One could simply close Program A, and run Program B that allocates lots of memory (malloc). Now since malloc doesn't usually clear the memory it allocates, you could potentially have access to Program A's memory.

Of course this would require lots of inspection of hex dumps and reverse engineering, but is this possible? Are there certain measures a program designer could take when designing an application to ensure this can't happen?

For that hack to be reasonably possible, the hacker would need to already have full access to the program with sensitive information and your system, which means they'd also have direct access to the data used by the sensitive program.  It also implies that no other memory is allocated or freed in between both instances or it would be otherwise impossible to plan how to access the proper memory segments.

The solution to protect yourself is therefore to protect your system at every single layer.  This means to only install reliable software, have good antivirus protection (if appropriate), a good firewall, reliable administrators, and limit system access as much as reasonably possible.

If you wanted to prevent another program from being able to reallocate the same segments in a predictable fashion, you could use randomness in your memory allocations, but that would seriously increase the risk of implementing software bugs which would be harder to troubleshoot, while not making a practical difference because of the previously mentioned points.


Should firmware images for IoT be encrypted for security reasons? When working with Internet of Things devices, is it recommend to obfuscate or encrypt firmware images pushed to clients? This to make reverse engineering harder.

(They should be signed of course)

No. You should not rely upon the obscurity of your firmware in order to hide potential security vulnerabilities that exist regardless of whether or not you encrypt/obfuscate your firmware.

I have a radical suggestion: do the exact opposite. Make your firmware binaries publicly available and downloadable, freely accessible to anyone who wants them. Add a page on your site with details on how to contact you about security issues. Engage with the security community to improve the security of your product.


Is logging number of special characters in password a bad idea? Recently I started new work, and going through documentation and code to understand what company is doing. While doing that, I noticed there is logged number of special characters in his password.

Personally, I don't think it is good idea as disclose some information regarding password, especially for users who didn't used any special characters. From other hand, this issue wasn't picked up by pen testers.

I was wonder, is it me being too paranoiac and this is not a real issue, or it is a issue which was overlooked during pentesting.

You have two separate questions here:

  Is logging number of special characters in password a bad idea?

I would say that is a bad practice. Off the top of my head, if an attacker is trying to brute-force / crack your users' password hashes, then knowing the number of special characters gives the attacker the following advantages:

It reduces the number of brute-force guesses because they only need to build a dictionary of candidate passwords with exactly that number of special characters. I won't do the math here, but see this answer of mine for an idea of how much that might reduce the effort. How critical is it to keep your password length secret?
It tells the attacker which users are "low-hanging fruit". IE who has a weak password and should be attacked first.

So yes, I agree this is a bad practice. I really can't imagine what legitimate reason there is to log this information ... ? I could see maybe someone put the log statements in while debugging the Change Password feature, but those logs statements should almost certainly be turned off in production.

Your other question:

  From other hand, this issue wasn't picked up by pen testers.

To second @schroeder, pentests are usually very limited in scope (what they're allowed to look at / report on), limited in time (how long they have access to the system for), and limited in domain knowledge of your application (specifically where to look or poke). So a pentest report should be read as a measure of how easy it is to find issues, not as a complete list of issues.

If a specific issue was not mentioned by the pentesters, that may mean that A) they found it and it's not as issue, or B) they found it and that specific tester thought it was ok but a different tester would have reported it, or C) they didn't find it in the time / scope given.


Can someone explain me the DNSSEC NSEC3 output? I'm trying to understand how NSEC and NSEC3 records work in DNSSEC. When I query for an non-existent domain with supports NSEC3, I get the following output

$ dig +dnssec NSEC3 gggg.icann.org. | grep -F "NSEC3" | grep -Fv "RRSIG NSEC3"

    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec NSEC3 gggg.icann.org.icann.org.
    ;gggg.icann.org.icann.org.  IN  NSEC3
    l6bdbf682dc45lv4vrfmrfnithopmvm0.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 L6CPA6V9R9563KMQT2NF2NL4BE1DPO3U
    dggsrhgbge97oj2ltjnpkieb951c9dsq.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 DGP62KNMI7ESBJ8BEKD60CEF9T7EUCO4 A RRSIG
    fke7dkh6es15igh27a4tl1fic0ukppkp.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 FKGU9H93DI168B3MQ3VK7VHTPNN67GA0 A RRSIG

My question is, why are there 3 NSEC3 records in the response? In case of NSEC I only get one NSEC record in response.

First, have a look at http://dnsviz.net/d/gggg.icann.org/WVLgMg/dnssec/ it may help to have things displayed graphically and over your mouse on top of the NSEC3 record at bottom to see all details.

NSEC3 is far more complicated than NSEC (and NSEC5 is far more complicated - but not yet deployed anyway - than NSEC3), and the behaviour will not be the same.

Basically you have 3 NSEC3 records because you are seeing here the authentication of the denial of existence of a wildcard record.
The gory details are in §5.6 of RFC7129, but you will need to read the previous sections to first learn about the "closest encloser" concept.

In short, the problem is explained by this snippet:

  The short answer is that due to the hashing in NSEC3, you lose the
  depth of your zone and everything is hashed into a flat plane.  To
  make up for this loss of information, you need an extra record.


Are managed programming languages immune to arbitrary code execution exploits? Classic example of arbitrary code execution is when a stack based buffer overflows, overwrites the return address so the control can jump into the attacker's carefully set up data to execute a shell code to enter the system.

If you develop in C and write lots of code, eventually you screw up somewhere, and your code becomes exploitable.

In managed languages like C#, Java, etc. arrays are bounds checked, doesn't have pointers that can dangle (they are garbage collected), etc. It looks like memory corruptions, buffer overflows and other nasty stuff that can allow an attacker take over the computer is not possible from managed code, is that true?

I'm asking this because I plan to abandon C and C++, and use C# or Java just for security reasons for parts where performance is not critical.

Assuming the implementation of those languages is flawless, then sure.  However, that's almost never the case.  For example, arbitrary code execution exploits have been found for JavaScript engines.
Furthermore, even with a perfectly "safe" language you can still be exploited.  A common source of arbitrary code execution is from deserializing unsanitized user input.


Avast says I don't need to use encrypted connections for my e-mail accounts I am using Outlook 2010 and Avast anti-virus 7. Whenever I add an account to Outlook if I choose to use SSL for incoming or outgoing connections Avast alerts me I shouldn't use it because Avast can't scan it. It goes on to say it's encrypted anyways. Should I not use SSL and select "none" in Outlook?

Should I not use SSL and select "none" in Outlook?

The various merits of using Avast's SSL aside, even if you use an encrypted email connection between your email client and your server, there is no guarantee that each mail relay will negotiate encrypted connections between themselves as they pass your email along, or are indeed not compromised.

There are two other considerations besides the first hop being encrypted to worry about, however. When you authenticate with a mail server, that authentication information is sent when the connection is established. If the connection is unencrypted, depending on the authentication mechanism (and whether it is designed to work over untrusted channels) it may be possible to capture the authentication details. This may allow an attacker to impersonate you and send email on your behalf.

The final consideration is that malware on your PC will have an easier time intercepting unencrypted network traffic (and so your authentication details) than encrypted - specifically, it can just generally collect network traffic (regardless of whether another application then encrypts it) rather than having to attack your email client process.

It comes down to a risk-based evaluation. If you select "none" for your SSL options, chances are high you're sending authentication data in the clear. If you use Avast's proxy, you must implicitly trust the local system (actually, you must do this anyway). If you don't, you don't benefit from virus scanning of your email, an important threat vector.

From a general security standpoint, assuming Avast's proxy is well implemented you should be fine going with that. The benefit of having your email scanned probably outweighs the risk of your loopback traffic being sniffed. Of course, adjust for your risk appetite.


Safely downloading user submitted content TL;DR
We save the request payload and Content-Type header in a database.  It should be JSON or CSV but may be malformed. Support users download the request payload as a file in their browsers using Content-Disposition: attachment. We attempt to add a file extension of either .json or, the default, '.csv'.

How can the support users download this file safely when it could contain absolutely anything? I'm less worried about ZIP bomb type attacks but more spyware, ransomware, etc., etc.

Background

We have a REST API that supports both JSON and CSV content types.

The API is secured with a unique client certificate for each user.

For reasons of arbitration we must keep an audit record of the exact content submitted to the service, we do this by storing the bytes directly in the database along with the content type header and some other fields from the URL and client certificate.  All of this, with the exception of the certificate is pre-validation as we need to record invalid submissions as well.

We have a support team a very activity for them is to help users who are not able to submit their documents because of a) malformed content or b) the content violates some business rule.

Now a requirement has come in to allow our support team to download the audit information so they can try to reproduce the users issue by submitting it to a test system or just looking at the content to spot mistakes.

We will provide a link to the file with either a .csv or .json extension if we can detect the content type.

The problem

Obviously this is wide open to XSS from the point of the unvalidated fields but that is mitigated easily enough by correctly encoding it for display however I do not see how this is possible for the downloaded file.

For example, I submit an Excel spreadsheet with Content-Type: text/csv, a support user downloads the file and opens in Excel to view the CSV and gets warned "the file extension doesn't match the content, do they want to open anyway?" to which they click "yes" because they are trying to figure out why it's malformed and my malicious spreadsheet is opened.

Even if we remove the file extension requirement then a support user may try to open it in Excel anyway seeing the content is supposed to be a CSV.

Solutions

I cannot think of any robust solutions;

Train support users to open in plain text editor first, but users are fallible)
Prevent downloading of content that is not character data, but character data can still be an attack vector, i.e., a .bat file and doesn't meet the requirements
Encode content and display on screen for copy/paste thus ensuring it's only text, files could be large and currently use streaming from DB to output stream to keep memory overhead low.
Trust our users and that they keep their client certificates safe

Is it just that the requirements will always be at odds with security and there is no way to download user submitted files safely?

IMHO, your key problem is that you are not validating the content being uploaded. Since we are only talking about JSON and CSV here, its trivial to write code to validate these. It won't catch all the issues, but it will get most of them. And at least you can tell the uploading user they've made a mistake at the time they are uploading - rather than telling a content consumer sometime later that they can't have the content.

As a minimum I would suggest validating the character set and the structure of the file - and checking it matches the submitted mimetype. However there is a complication in that not all the things which are thought of as CSV comply to RFC 4180, and RFC 4180 actually describes a lot of variants of the CSV file format (particularly how the symbols used for meta-data are represented when they occur within data).

I would strongly advise against allowing anyone to download content which has not been checked via their browser. Since it should be possible to represent the content using UTF-8 or UTF-16, its trivial to create a representation of the content with the non-compliant characters replaced and displayed in a PRE.../PRE block within an html page (with the htmlentities translated too).


Why do (many) TOTP devices or TFA apps use none or simple access password? In Sweden, where I live, you can use an app called BankID to identify yourself and sign into official website or sign up official documents.
The app uses a 6 digits (numerals, not alphabet or symbols) code as your key.
You use it by typing your personal ID number (which is not secret in Sweden, or at least very easy to obtain) into the web site, and than type the 6 digit code into the app on your mobile device or a desktop app as a replay to a pop up with the requesting site's name.
Some banks uses a kind of TOTP devices, like this one for example,. The device uses a 4 digit key as access password. Again you use it by typing your personal ID number into the bank web site, the 4 digit code on the device, and then copying the generated longer OTP.
This is different than traditional login procedures using 2FA since the "something you know" is a very short and simple password. In the bank's case it's only 4 digits, and while I suppose the device would lock itself up if someone would try to guess the password I suppose there's a good (whatever it is) chance to guess it, especially if you obtained some information about it.
Am I getting it wrong ? Is it more secure than that ?

You named it - it is a bank!

Banks are finance institutions and compare numbers and probabilities. We all know that a four digit!!!!! (not characters) password is absolutely insecure. Nevertheless the bank calculates the probability and costs of a user getting breached and the probability and costs for users forgetting their more complex app password and thus creating support requests.

There would be however one reason for using a real password on the app: The app on the smartphone stores a symmetric key to generate the one time password. You could use this password to encrypt this key, when it is not used. Again, we know that a four digit PIN will not create a good encryption key.

The device you linked with the key pad is probably a challenge response device?
I assume you do not always enter the same PIN in the device!? The PIN is the challenge - it should contain some kind of information of the transaction. Your device also has a secret key and will create a response based on this challenge/transaction data. If it is implemented right, it is a rather strong mechanism. They could however have created this based on the OCRA algorithm (RFC6287 https://tools.ietf.org/html/rfc6287).


How can I restrict users' connection attempts to my FTP server? Is there any way possible to restrict user to make a connection to the FTP server on my Windows XP computer?
I have an FTP server established in Windows XP and now I want to make access to that FTP server restricted to deny brute force attacks.

If the machine was Linux then I would use an iptables chain to restrict users' connection attempts, for example to deny user after 6 connection attempts in one second.

So can I do this in Windows?

Have you thought about just using the windows firewall API? Should give you more than enough control based on what you are trying to do.


New to security, is php password_hash() good enough? This is the first time I've had to handle personnel information and I want to make sure I have a good amount of security. I will be storing users' emails and passwords for their accounts on a MySQL table, so I was wondering if the password_hash() function is sufficient for hashing.

For example would this be an acceptable amount of security for storing passwords?:

$password = password_hash($password, PASSWORD_BCRYPT);

I would then compare the hashed passwords when a user tries to log in to verify. Also because I don't need the emails for contact purposes, they could be hashed as well.

Using bcrypt is a good start; that's the recommended choice (or at least one of the recommended choices). The documentation seems to indicate that PHP finally does things properly. Make sure that your PHP version is at least 5.5.0. Don't try to fiddle with salts: by default, the function will generate a random salt when needed, and that's the right way to do it, so just let it do its job.

You should try to alter the "cost" option as well. For bcrypt, the cost is a value ranging from 4 to 31; each increment means that the password hashing is twice as expensive, both for your server and for the attacker. In practice, you want to make that value as high as can be tolerated, given your server power, average load, peak load, and maximum user patience: this will give you the best security that you can hope for.

(Note that I said "the best", not "good".)

If you want to understand the underlying concepts for good password hashing, and why bcrypt is a good choice, start here.


How can I locate and purchase SSL certificates that contain a specific trust chain? I am dealing with a unique scenario where I have a mobile app that is unable to be updated on the App Store and has implemented SSL pinning. The issue is that the app pins against Lets Encrypt, which now will be moving to new certificates that are not pinned. As a backup, the app pinned a number of other certificates:
@"nKWcsYrc+y5I8vLf1VGByjbt+Hnasjl+9h8lNKJytoE=", // Intermediate DigiCert Global Root CA
@"E3tYcwo9CiqATmKtpMLW5V+pzIq+ZoDmpXSiJlXGmTo=", // Intermediate DigiCert Global Root G2
@"r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E=", // DigiCert Global Root CA
@"i7WTqTvh0OioIruIfFR4kMPnBqrS2rdiVPl/s2uC/CY=", // DigiCert Global Root G2
@"h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=", // GeoTrust Global CA
@"q5hJUnat8eyv8o81xTBIeB5cFxjaucjmelBPT2pRMo8=", // GeoTrust Primary Certification Authority – G3

Originally, the developer intended RapidSSL to be used as a backup if this situation arose, with them being able to get certificates from RapidSSL that contained any one of these certificates in the trust chain. I am tasked with purchasing a certificate that achieves this, but I am not able to find any concrete information on how I would go about finding a certificate that would meet this requirement.
I was looking at DigiCert for a Basic OV certificate, with the assumption that the DigiCert Global Root CA would be somewhere in the trust chain. Would this be correct? Is there anywhere that I could see an existing certificate so I can see what the trust chain contains?

You ask CA to issue a certificate. This certificate will be signed by CA and its signature will be confirmed by its certificate. You cannot force CA to use a certificate with particular trust chain.


Will gmail close my well intentioned botnet account? I'm part of a company that has at least 1000 PC's distributed in different buildings over a radius of 25 miles.

I've been asked to make a  program to survey technical information on each PC.

Since not all of them share a LAN connection but all of them have internet access, my solution was to use a gmail account to share the encrypted data.

I've created  client/server like services to send the data and retrieve it to the data base through emails, all of them using the same gmail account (to send and receive).

I know that this look a lot like a botnet...actually I think it is, since each client would be able to receive configuration mails from the server to request certain registry entries.

All external IP's are dynamic, the server is internal, the resolution to establish a trusted unattended connection would demand publishing the IP's somewhere, Dynamic DNS has been suggested but in terms of reliability it's just as safe as gmail.

Anyway my question is: will gmail detect all this traffic made on the same account as a botnet and close it? if so, should I use several accounts?

For those who voted to put this on hold, and for the ones who'll review it, I think this is a policy question (as stated in what topics can I ask about) specifically about gmail security policies. I think I couldn't be clearer about it.

Using email as a configuration distribution service is terrible. Using an external and uncontrolled server is even worse. As people already stated, you could trip the spam filters and get messages silently dropped, anybody could send emails to the account, the latency between a message being sent and received can be very high (and unpredictable), and other complications.

If your clients have internet connection, you could set up a free server running PHP/Python/Ruby/Node and create a webservice with authentication in place. The clients would connect to it, and send statistics or receive configuration changes.


Secure high-portability way to store passwords? I'm developing a cross-platform Java desktop application which uses a password to derive a cryptographic key. I'd like to add a "Remember me" feature that stores this cryptographic key on the hard drive securely so that my program can get it after a reboot.

If I store it directly, anyone who manages to get access to a typical user's hard drive (no encryption) will be able to get the key. If I encrypt it, the key used to encrypt it must still be stored somewhere on the drive, and hence defeats the purpose.

I've seen gnome-keyring, Windows Credential Manager, and Mac OSX keychain, but they each seem to have their own non-Java APIs (or unofficial ports to Java). Furthermore, it seems like any program running as the user will be able to read or write to or from these two services.

Is there a more portable (and preferably isolated) way to securely store passwords (or cryptographic keys) on the hard drive?

Thanks!

On today's systems, you can use TPM. It can be used to store (or wrap) the root key and protects additional keys created by an applications. The application keys cannot be used without the TPM, making this a very useful authentication method for endpoint devices.

Read about the how-to here .

Another advanced method which will probably be used a lot in the future is to use Physically Unclonable Functions.  Instead of keys being stored (and susceptible to reads), keys are instead derived from unique physical properties of a chip’s SRAM memory and exist only when powered up. Using an SRAM-based PUF, the keys are guaranteed to be unique since they utilize the inherent randomness in silicon bit patterns. Even if this sounds more futuristic, it's something usable today.

PUF Details and documentation about key storage using this method.


The data(username,passwords) stored in app bundle is safe in a jailbroken ios device I was testing an iphone application in a jail broken device. I happend to see an intresting thing that the username and passwords are stored in a plist file and Cache.db file in preferences directory of app bundle.  I can see this data as cleartext. So the data stored in nsuserdefault, plist, sqlite are not safe right? I have checked the other storage options like Keychains. But there is a tool keychain dumper,which can easily dump the keychain data.. So how i can save data in iphone app.  Nothing is safe. So any alternate method to save data, I mean any kind of encryption or anything. How you advice me to secury store a data even if the phone is jailbreaked.

Your app checks if the device is jailbroken and refuses to run if it is. That's it.

On a jailbroken device, a hacker (or the user) can modify installed applications, so nothing is safe.


How Secure is OAuth2 for Web Applications? Let’s consider a single page client side application, developed using HTML and Javascript.

In this case, even if the implicit or authentication code flow is being used to request Access Tokes, still the clientID and Secret would still be found in some Javascript, which might be making the token requests. Plus, passing the Access Token in the request header (or query parameter) are still visible in the network trace. Moreover the Access Token needs to be stored locally in a browser.

How secure it is to use OAuth2 for web based applications??
How the user information can be protected, if the client (browser) is compromised.

Thanks.

Usually OAuth is used by a user to give access to resource to a third party, which is the client in the OAuth framework. So in the implicit flow the user might see the access token, however they already had access to begin with so that is not a problem.

The more secure method though is to not use the implicit flow. This then gives you an access code that you have to combine with your client credentials to obtain a access token. You don't do this in the user's browser using javascript. Instead you have your server side software capture the access code and do a back channel call to the authorization server to get the access token. Now the user or any one else snooping around never actually has enough information to get your access.

So the steps are like this:

Redirect user to authorization server
User authenticates and provides consent
User is redirected to Client with access code (or error code)
Client webserver captures the access code
Client backend exchanges the access code for an access token through a direct back channel call to the authorization server (notice the user's browser is not involved here)
Client can now use the access token, and possible refresh token, to access the resources the users has provides access to.

In the steps above the user's part is done after step 3. So you don't want to be depending on the user's browser to finish running your javascript. Not only would this cause security issues as you described, but it would also make execution of steps 4, 5 and 6 uncertain and probably degrade your user experience if you require them to stick around of a long processing task. Instead you can do all that on the backend without the user needing to be involved.

If you implement OAuth correctly it can be a very secure way authorisation. But that is a big if.


Does Apple still monitor or track after having a customer support screen sharing service with ara.apple.com? Is having screen sharing service with ara.apple.com safe?

I had screensharing service with ara.apple.com(https://ara-prn.apple.com/) which is official apple website for apple products support. And they wanted me to install an app after entering session key and they said the app will self-destruct once support session ended.

Would there be a possibility that Apple can still track and monitor that computer even after the support session ended and even if they claim that installment of the app for screen sharing self-destruct?

There's always possibility...

Nevertheless, why would they continue tracking and monitoring you using this tools since they can put any backdoor they want as editor of the operating system ? It would be far easier to do this directly on the OS shipped with your device.

Moreover, such a monitoring would probably be discovered and lead to a scandal...


What are the risks of posting family pictures online without any access control? What are the risks of posting family pictures online, for example on a blog site, without any access control in place?  What should be my threat model?

I am weary of posting (recognizable) pictures of my self and my family on Facebook. Facebook is a foreign company whose primary goal is making money for their shareholders by milking other people's personal information. Combined with the current state of AI, they could do a lot worse then passing personal information to low-lives like Cambridge Analytica.
Even a fairly innocent future-use like 'selling' facial recognition to advertisement companies, who could then spam me and my loved ones IRL using in-store cameras would be horribly annoying.

A very simple solution would be to just post any pictures i want to share online on a blog.
Coming up with a nefarious business case is a lot harder if you have to collect data from disparate sources, without any machine readable metadata (Facebook already has at least one email address, a name, a network of friends, login data, data from cookies and pixels to go with the pictures).
As it would be very hard for a company to abuse openly available pictures on a large scale, the risks of an actual 'industrial scale attack' are nil. But there is no protection against individuals who may use the pictures for whatever purposes.

The risks i can see:

people using the pictures to aid building a fake persona online for criminal purposes (see this answer in related question) or just for fun.
people photoshopping the pictures just for fun and posting them somewhere. Obviously, this could be very unpleasant depending on what is photoshopped and who sees the results.
pictures could attract someone really disturbed

What else?

Well, other than the standard geolocation stuff and other metadata you should remove from the images and people being able to guess your location just by the image background, I don't see any.

That being said, with stuff like google crawlers, these images can be very easily harvested and facial recognition can probably associate them with you if you the company (FB) has pictures of you already.

And if you post links to them on social media, then to correlation would be even much easier. But if you do this, there is an interesting solution. Use a key to access the photos and just put them in the link. Something like: mypage.com/photos/my_holiday_photo.jpg?key=tGJ4sNcUYYz2Xagt


Appropriate defense for 404s in my logs - persistent web scans from one region This seems to be a fairly easy question to figure out, but I wanted to make sure.  I've got about a thousand entries on one of my web servers with phpmyadmin in the connection criterion, but as I don't have phpmyadmin installed, it always 404s.  They originate from several former-Soviet-bloc countries, which makes me concerned.

Should I assume these are exploit scans?  Further, are there any additional preventative measures which I can implement on the system to block these requests (such as a selective iptables rule or something)?

Server Info:
Ubuntu 10.10 Linux, 32bit.
WebServer: NGINX

This is pretty well the background noise of the Internet. Since phpMyAdmin had such a poor security history it is not uncommon to see systems looking for instances of it running on the network. Chances are, that is exactly what is happening. There are a few things you could do to take action on such an activity, though which one, or ones, you choose will depend wildly on how your site is used.

Block It Entirely
Depending on who needs to access your web site, you could insert firewall rules to only allow access from specific addresses or address ranges. For example:

-A INPUT  -s 198.51.100.50-m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT  -s 203.0.113.0/24 -m tcp -p tcp --dport 80 -j ACCEPT

This will specifically allow address from the host 198.51.100.50 and the network 203.0.113.0/24. Here the benefit is limiting your scope of access to a relatively small set, however you need to know every where access is required.

Rate Limit Connections
IPtables has built in support for rate-limiting. As an example take these firewall rules:

-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --set --name WEB
-A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name WEB -j DROP

What this will do is limit each source address to only 8 connections within 60 seconds. These values may need tweaking, depending on your environment, but will certainly slow down any kind of brute force or fast scan.

Dynamic Detection and Blocking
There are a number of applications for doing this, but they all basically work the same way:

Read specific log files for actionable events
Compare events against some kind of scoring system
Take action if meets criteria

One of the most popular (subjectivity alert) is probably an application called fail2ban. It will process a large variety of logs on your system, including SSH and Apache, and issue blocks for those source addresses that are committing "suspicious" behavior. Typically this would be adding a source IP drop rule in your host firewall. You mention that you are using Nginx as your web server, so you would have to research whether or not fail2ban, or what other product, would work for you.


ARP poisoning on campus network I am a computer engineer student. Recently, I was able to arp-spoof the router of my class.

I used:

Kali
Ettercap
Wireshark
The gateway IP address was: 192.168.0.1
The victim was my phone with the IP: 192.168.0.34

I was able to see the packets from my phone being sniffed by wireshark on my laptop.

However, I tried using the exact same method on the residential campus network.

Kali
Ettercap
Wireshark
The gateway IP address was: 192.168.1.254
The victim was my phone with the IP: 192.168.1.87

But I doesn't work. The only things that I can sniff on wireshark is the arp packets (Like:

  192.168.1.254 is at ec.a5.sd. ...

I think this is because the network is larger and have several layers.
But I am not sure, why the arp poisoning is not working on the campus network?

There are a couple of possible answers; you don't provide enough information to determine the cause.

One cause might be that the active network components of your campus network are taking precautions against arp spoofing. The simplest one might work like this:

Your phone talks to the network, maybe to fetch a webpage or something.
The AP remembers where the first arp request from your phone for the gateway came from (Where is 192.168.1.1? Tell 11:22:33:44:55:66, e.g. your phone's mac address).
You're trying to spoof 11:22:33:44:55:66 from your laptop, but now the origin doesn't match the origin recorded by the AP in step 2, and so it doesn't update it's arp lookup table.

I know this kind of defense against arp poisoning can be used on switches (they remember which port a mac address lies on and can be told not to update their 'memory') and on normal computers.

I'm not sure how it would technically work on a Wifi AP - maybe a mac address can be tied to an active session on the AP. But I'm pretty sure it's something a professionally managed network would try to protect itself against, so it's not so surprising that it doesn't work in your campus network.


Is unauthorised deletion an integrity or availability issue? During a web application test I have discovered a parameter tampering issue that allows a user to delete comments left by other users. They can't modify the content of other users' comments, and they can only view them where this is intentional.

I'm now calculating the CVSS score using this calculator. It's pretty clear that the confidentiality impact is none, but I'm unclear about the others.

So my question is: for the purpose of CVSSv3, is unauthorised deletion an integrity issue, or an availability issue (or both) ?

As pointed out in this (unanswered) question, Availability in CVSSv3 is about how well the web service performs, not whether its data is available:

  While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email).

To answer your question: only Integrity is relevant here.


Monitoring HTTP traffic on openvpn server I have configured an OpenVPN server and can monitor HTTP traffic via tcpdump. Is there any way to monitor the HTTPS traffic as well?

Hints:

Self Signed SSL certificate as root certificate on VPN client's machine.

If the above hint allows me to monitor the traffic, please specify how can that be implemented on CentOS + OpenVPN?

TL:DR; you'd have to setup a transparent proxy on your VPN server.

You can reroute all outgoing traffic to port 443 from your VPN server (which are, probably, your VPN clients) using iptables.  After this you could run an intercepting proxy such as mitmproxy which takes care of the SSL bit as well.

First off, you redirect all outgoing web traffic to your local proxy - for example:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

This makes you a transparent proxy; i.e - traffic to all web ports (in above cases just port 80 and 443, you can add more) your clients will not have to set a proxy on their browsers, yet traffic goes though your proxy.

Makes sure your box forwards traffic, but that usually happens already if you're running OpenVPN (else they won't be able to access the Internet).
Second, we need to set up an intercepting proxy, such as MiTM Proxy, this can simply be run in transparent mode with the -T parameter;

mitmproxy -T --host

It sets up a CA and that certificate can be found on the server on the ~/.mitmproxy directory.  That certficiate needs to be distributed to your clients and needs to be trusted by them.  The --host parameter ensures that the value of the Host header is used.

This would give you access to the HTTP traffic; and you should see it happening in your MITMProxy screen.  To handle a large amount of traffic, or store these, add the --outfile parameter to mitmproxy to write all traffic to a file.  More info can be found at http://docs.mitmproxy.org

Some clients will prevent connecting to particular SSL websites (such as google), due to certificate pinning; so it may either break functionality, or you'd have to implement a rule that doesn't trap this information.  You can either do this on MiTMproxy or using iptables.

Also, to remain ethical.  You should tell your users that their traffic is being monitored; they can find out anyways (since all certificates will be "signed" by the same CA, yours).


How dangerous is Javascript in an Android browser and how to protect? I'd like to know how dangerous Javascript can be for Android devices.

I know that there's the NoScript AddOn for the Firefox mobile browser but that's not really an effective solution as it's very inconvenient (it's inconvenient enough on Desktop Firefox).

Are there known cases of Android infections via Javascript? What could theoretically be done to these millions (or is it billions already?) of devices via this way and what are the technical theoretical, researched and implemented protection-measures against these?

Well this is the latest one related to javascript, an estimated
 36.5 million Android devices may have been infected.
https://www.theregister.co.uk/2017/05/30/android_app_judy_malware/

Read this as well by Siegfried Rasthofer

https://blogs.uni-paderborn.de/sse/2013/09/16/java-script-attack-vector/

You can also see my this answer although it is about java virtual machine(dalvik) not javascript, but attackers can chain browser javascript based exploits with Dalvik or Linux Kernel exploits to gain elevated privilages, remote code execution, etc.

What kind of attack vectors are made possible as a result of Java being hopelessly intertwined with Android?

You can also google "Android Javascript CVEs" to see more examples.


How can I make sure password hashing is secure on computers while not being prohibitively slow on mobile devices? I'm new to cryptography and its implementations. I'm designing an Android app where an user enters a password to retrieve some encrypted data. After some research on possible solutions I ended up with bcrypt used like so:

  User enter Password -> bcrypt(Password) -> key for encryption

And then storing it in the database like so:

  SHA256(bcrypt(password)) -> user check (this is stored in DB)

I was planning to use the jBCrypt implementation in Android, but from what I've read bcrypt is extremely slow on mobile phones (over minutes depending on the model of phone/strength selected.)

I know that slowing the hash procedure is the core to the bcrypt algorithm, but it's not acceptable for a user to require 2 minutes to login/decrypt on a mobile device, while the same operation on a normal PC takes seconds. However, if I lower the iteration count on the smartphone, an attacker can bruteforce it on a faster PC. How can I reconcile these two aspects of the problem?

EDIT

I finally decided to try jBCrypt on Android, and I've tested it on several mobile phones I have with different SO versions. I also tested it on my home PC and compiled a table of results:

It seems like a Work Factor of 10-11 would be aceptable while still being reasonably secure. I'll try to implement a NDK solution to see whether I can improve the results. (I'll post results if I end up doing tests.)

jBcrypt is a Java implementation. Android apps are written in almost-Java, for an almost-Java virtual machine called Dalvik.

For computing-intensive tasks, especially cryptographic algorithms, Java incurs a typical 3x slowdown compared to equivalent optimized C code: a good Java virtual machine runs a JIT compiler, and the performance of the code will be limited by the constraints which a JVM must operate in (translation from bytecode to native code must be fast and incremental, methods being translated on a per-call basis; and the result must still be appropriate for the garbage collector). Further slowdown can be observed in some specific cases where native code can benefit from extra opcodes provided by the CPU, the typical case being computations on big integers (say, for RSA), because the CPU may offer an "extended" multiplication (64x64->128) that Java code cannot use, due to the lack of a 128-bit integer type in Java.

For a rather thorough experiment in the context of hash functions (not "password hashing", just "hashing"), see sphlib: a library implementing a lot of hash functions, in C and in Java, with "similar efforts at optimizations" (same developer for the whole lot), and including measures on a variety of platform types.

Now, there can be additional slowdowns for Android apps:

The CPU of a smartphone is not as fast as that of a PC. Smartphone CPU can go to the gigahertz range, but still do less work per cycle than x86 CPU -- because one of the prime objectives of a smartphone CPU is to save battery. A smartphone must be alive for a full day, while engaging in radio activity, whereas a laptop can have a bulkier battery and only needs to be up for a few hours. Modern smartphones are efficient, but there still is a gap when compared to desktop PC. Let's say an additional 3x factor.
Dalvik is not necessarily the best JIT compiler around. The relative lack of raw muscle means that the JIT cannot apply the most complex optimization strategies, because it would make JIT translation of a method too expensive.
Up to Android 2.1 (included), Dalvik has no JIT. This is the worst slowdown, that other answers allude to. In Android 2.1 (and before), Java bytecode is interpreted, not translated to native code, and this incurs a heavy extra cost (say 10 to 20 times slower than JIT code). Android 2.2 onwards has JIT.

Switching to PBKDF2 won't change the picture much. If you use PBKDF2, be sure to use SHA-256 (or SHA-1), not SHA-512, because the smartphone CPU is ARM-based and will be quite uncomfortable with 64-bit arithmetic operations that SHA-512 heavily relies upon, thus slowing down your code -- whereas the attacker has a PC, which eats 64-bit operations for breakfast, and will not incur the same slowdown.

Summary: bcrypt will be very slow on Android 2.1 (and previous versions). It will be somewhat fast on Android 2.2, albeit not as fast as a PC (say, between 5 and 10 times slower). PBKDF2, scrypt... do not change this picture in a significant way.

All of this is said about the performance of bcrypt. I did not comment in any way on the proper use of bcrypt-derived secrets for both encryption and password verification. Indeed, when you store "something" to validate a password, you don't what that "something" to be too close to the password-derived key you use for encryption.

One "cryptographically reasonable method" is to compute the password hash with bcrypt or PBKDF2 (with salts and iterations and everything), and then take the output and expand it with a Key Derivation Function into enough key material for your needs. In your context, take the bcrypt output, then hash it with SHA-256. This yields 256 bits. Store the first 128 bits in your database as "password verification token". Use the other half as encryption key.

PBKDF2 makes this process slightly simpler since it is a KDF, so you can ask for 256 bits of password-derived output right away, not needing an additional hashing; whereas bcrypt's output size is fixed to 192 bits, which may not be sufficient for your needs.


Permissions for .htaccess file that needs to be modified by sister application? The .htaccess in our application has 777 permissions because a sister application needs to write to it. Could you confirm that htaccess with 777 permissions is bad for security and if so what a more secure alternative would be.

I was thinking if the sister application (located on the same server) changes the permissions before it edits it and then changes them back again?

Yes, XX7 is very bad for security, it gives read, write and execute access to all users and should be avoided unless absolutely necessary. A malicious user could use the .htaccess file to get a malicious or sensitive file to become visible to the web interface. Then, using the web inteface user (who may have elevated privileges) the malicious actor could perform actions under that context.

If you can get the sister application and the .htaccess file to have the same owner/runner then 700 should work, otherwise try to get them into the same group and have 770.

Obviously the more users with write access to a file the less secure it is.

If some level of access ( > 0) is required for .htaccess, consider:

1 (execute)
4 (read)
5 (read and execute)


Recommendations on minimal alternatives to openssh Although openssh is awesome, I'm interested in exploring some more lightweight FLOSS alternatives to use for connecting to servers I'm administrating (and using alone).  Since I only need a minimal set of features (only public-private-key authentication, only a single (secure) algorithm like ed25519) and I'm aware that feature reduction is often equivalent to a reduction in attack surface, I was thinking about using something like tinysshd or dropbear.
But from reading about it I got the impression that due to the lack of privilege separation as implemented in openssh this might be counterproductive from a security point of view.
Therefore I'd like to ask the community if currently (2020-10):

it is recommended to use one of the alternatives to openssh,
if yes: which one is preferred and why, and
if no: why this is (not) the case.

Also I'd like to know if it is advisable from a security point of view to use tinysshd in conjunction with tcpserver since it allows it to be run as non-root-user but needs to leave the host keys inside /etc/tinysshd/sshkeys.d readable to the user.
In addition I'd appreciate any recommendation on other alternatives except openssh, tinysshd and dropbear.

I would keep using openssh
Assuming a 'normal' server, with no resources problem but only about concerned about the security benefits, I would keep using openssh.

It has an excellent security record.

While the list of CVE is a long one, analysis shows those are -particularly for one-user servers- actually relatively minor. Those not covering DDoS mostly go along if system is configured in a specific way, an authenticated user could bypass certain setting, which may be unintended.
For a vulnerability suitable to an attacker, we would probably would need to go back 14 years, to CVE-2006-5051. And even that doesn't show a clear exploitation path.

Hardening features like the mentioned privilege separation

Well known and reviewed. Being so widespread, it has been very scrutinized. You can be sure any security issue that was missed will be promptly fixed when reported.

Distribution support. openssh is packaged on every distribution. The other two are available in some of them, but not in others. Even then, you can expect they would quickly patch an openssh vulnerability, which may not be so fast for less common packages. Of course, you may as well install your sshd directly from upstream (and it would provide you the latest version), but there's benefit on using packaged versions if you don't want to be separately watching new sshd releases.

Note that you can restrict openssh features (only PublicKey authentication, just certain algorigtms, etc.) so that you reduce the attack surface available to an attacker.

That said, I don't think using any of the other would be insecure, and wanting to .
PS: For your use case I don't think there's an issue with the /etc/tinysshd/sshkeys.d keys.


What should be people warned about? I'm doing a presentation about security/privacy on web and i would appreciate few hints about what would you talk about. Just general, nothing IT specific. I just wanna give a 1000 foot view on few topics and go deeper if I see interest. People should know about a threats on the web and also not just leave defaults everywhere to allow everyone track their every move.

Topics i prepared so far :

Nothing is free. If it's "free", it gets money by gathering informations about you(VERY SIMPLIFIED)
CSRF - Don't click everything.
Encryption.
Passwords - Just don't use the same 10 char long pass on every website... Also how to make a "secure" one
Defaults - I have a really deep problem with this one. admin/admin is not secure router login. Also many other defaults
"Smart" devices - They are not so smart when it comes to security. But they excel at tracking your every move.
Backup everything - We are living in the era of ransomwares. Backups always come handy and can save you LOT of time and sometimes even money.
Facebook/Instagram/other sites can gather MANY informations if you let them.
VPNs & Proxies(maybe even Tor)
Sandboxing applications
Antiviruses
A small bits about random topics - What you delete is not actually deleted. Can be helpful if you accidentally delete something, but can be really dangerous if you think you really erased something. -- Do not use random add-ons in your browser(refering to those malicious sites using facebook to spread) -- few other random bits
App permissions on smart devices. Does calculator really need to access your microphone?
PDFs/MP3s can be malicious too! Also i would refer to virustotal.com here.
Phishing + Social Engineering - I should've mention this earlier. Huge topic. Extremely powerful and sometimes even legal!
What to do and how to react when you've been "pWn3d". Time is everything here. You need to react.
2FA

Every idea appreciated. Simply put : How would you scare people?

Why you should never trust a public network: A brief overview of man-in-the-middle attacks.

Why you should never trust a public network #2: Are you 100% sure that the convention center WiFi is really controlled by the convention center and not someone else who just made the SSID look like it's for the convention center?

The name on the second one could probably use a focus group.


Does a PC with many NIC's can create vulnerabilities for each network wihich it is connected? I wonder if installing 2 more (USB to Ethernet) NICs to my PC can be risky if I need that only my PC can access to the three networks, and no any other host in these networks... Could my PC act like a router, allowing traffic from any host to any network?

yes,, that is not secure for your networks, your PC will be an entrance for other network if it got exploited, attacker can use PC as a zombie or even launch attacks to the three networks from it directly,,


Cookies + CSRF protection + AJAX In my app (built in Codeigniter), users can submit status updates. When submitting forms, Codeigniter automatically provides a hidden cookie. I can validate that cookie through AJAX when the user submits the update, so the CSRF protection works great.

The issue comes when I am using AJAX to submit/load data without a form (such as deleting a status update). In such cases, because there is no form, there is no automatically generated cookie. I have figured out that I can use the cookie that creates the status update to delete it (and have limited the delete function to the status creator).

But does using the status creation cookie to delete the status update violate a security principle? Does the cookie need to expire (or be different than the creation cookie?), and if so, how can I generate another cookie that will be linked to the correct status update?

I think you meant tokens, not cookies. As far as I know, CodeIgniter antiCSRF mechanism inserts unique random tokens in every form. These have nothing to do with HTTP cookies, which as a best practice should not be accessible from JavaScript code.

Regarding your actual question, it has been discussed in other threads if using one anti CSRF token per session is a bad thing (example). Your case is between using one token per form and using one token per session, so as long as you are using SSL you should be ok.


Linux and Windows Password Security Settings I'm asking a client why some password parameters are not defined in the Linux OS level and he's saying that, internally, Linux and Windows complexity and timeout settings are different. If they set the Linux password complexity/timeout settings, then there is potential that the Linux system will ask for a password change before Windows AD will, AND/OR Linux password complexity will be different to Windows complexity and the user will change their password to something that is valid in Linux, but is not valid in Windows and therefore gets locked out their account.

Is this true? Can't they just set up the password settings of OS and AD the same way (i.e account lockout, idle session timeout, complexity) to avoid this?

The authentication systems in Windows AD and Linux are completely different. Windows AD uses Kerberos, which uses various "tokens", "tickets" and keys to establish identity. Linux systems can use Kerberos authentication if there is a Pluggable Authentication Module (PAM) to support it, but more likely they continue to use their native authentication system which is as Scottie H described.

It is, of course, possible for the most part to set the various parameters (password complexity, expiration, etc.) the same in both systems, but finding all the right levers to push and knobs to twist on two disparate systems may be an exercise in futility, and there may be certain combinations of parameters which may be mutually incompatible across the two platforms.

I would also consider that passwords themselves are rapidly outliving their usefulness, and multifactor authentication (MFA) is the secure way to go. However, implementing MFA cross-platform is fraught with the same sorts of incompatibilities unless the infrastructure (e.g. RADIUS for hardware or software token authentication) is carefully chosen with both platforms in mind.


Clicked link on fake email which appeared to be from friend I receieved an e-mail which at first glance appeared to be from a friend, I clicked on the link provided without thinking as we would often exchance links to sites. The link went nowhere i.e page not found. When I looked at the e-mail again, the actual e-mail address was completly different to my friends.
Does simply clicking with no other activity provider hackers with a route into my computer? The computer has since been disconnected from the internet.

Any repsonses would be greatly appriecated.

A clever attacker can set up a site so that if you click on it even once, within seconds he can take over your computer. Even worse, you might not have to go to his site. If you click a link that leads to his site, he could feasibly "own" your computer. Beware!

Whenever you visit a Web page, lots of invisible activity can happen on your computer. For example, if the Web site welcomes you with your own name, that's because last time you visited, it put a special text file called a cookie on your computer. If a stock ticker scrolls past or sports scores update automatically, the site could be executing a script on your computer. This stuff is normal. But the fact that your computer is willing to receive and execute instructions from a Web site is what hackers exploit.

Not all Web-based attacks are visible to the intended victim. Sophisticated hackers use tricks to hide what they're doing. But such sophisticated attacks are rare. Most Internet users pay no attention to URLs, so the average attacker doesn't use sophisticated attacks, most of the time he does not even know how to exploit your browser, he would need a rare browser 0-day and this type of bug is worth hundreds of thousands of dollars, sometimes millions.

You probably haven't been infected just by clicking on the link.
I would not worry if you did not enter personal data on the phishing site.


Is it safe to derive an IV partially from the secret data if it is hashed before use? To help ensure uniqueness of IV's used in a CFB AES-256 cipher, software I know of gathers bits from various sources including the plaintext being enciphered, and runs that through an SHA-256 hash.  The resulting 128 bits are used as an IV.  I suppose, because CFB is used, this only occurs for the first block.

The plaintext changes over time, and is enciphered many times over its lifetime.  An attacker may well have access to multiple ciphertexts of plaintexts which only differ by as little as 1 bit in 4096.

Is this likely to adversely affect the cryptographic strength of the ciphertexts by much?

If your IV is derived from the plaintext, so that encrypting the same plaintext twice leads to the same IV, then you lose semantic security: someone can tell whether two plaintexts are equal by comparing the ciphertexts.

Other than that, for CFB, it is ok to use a predictable IV; what is critical is that the IV is not reused (or at least not reused for distinct messages, with the caveat above).

So a cryptographic hash of the whole plaintext, or of the plaintext plus other data, is a suitable IV as long as you don't mind exposing plaintext equality. Note that if you include data other than the plaintext (e.g. IV = hash(plaintext || moredata)), then this also exposes the equality of moredata if you have the same plaintext multiple times with different moredata.

Source: Is using a predictable IV with CFB mode safe or not? On the danger of reusing an IV, see Will varying plaintext compensate for a fixed initialisation vector?


What information does ssh -vvv expose? I am using the most verbose debug option of ssh (concretely: OpenSSH_8.2p1) ssh -vvv and I am wondering what information the output exposes.
Of course the output contains the username and the server one is trying to connect to, however there is quite a lot more.
What information is exposed by this debug information? What could an attacker do with this information?
For example, would it be safe to send the output to a service desk or ask in an internet forum for help with a problem and giving the output of ssh -vvv without replacing some information? Would that allow or help a third party to access the server, break the encryption, etc.?

The private keys are not displayed, not even ephemeral ones used only for that session.
But public keys are displayed. Person with access to output of ssh -vvv would be able to identify the server in an internet scan (if server is open to the internet) and identify the client using something like "ssh public key is associated with github account".
So this is a privacy problem, but not a way to attack the server or the client, IMO.
If an insecure authentication method is enabled, even if it is not used, person with access to output would see that, and might try to attack the server or the client using that insecure method. There are tools to scan servers (e.g. this) but the information about the configuration of the client is new to the attacker. The attacker might get the same information by MiTM or by tricking client to try to connect to it without pretending to be something else.


Is industry experience the only way to a CREST certification? I hope this question is direct enough for the stackexchange format, my apologies if it is not, please feel free to downvote to close.

I'm interested in pursuing a CREST certification, however it looks to be a a chicken and egg problem - without certification it seems unlikely i'll be able to land professional experience, without professional experience it's unlikely i'll be able to be certified.

Is it possible to gain industry experience without certification, and the corollary to this - is it possible to become CREST certified without industry experience?

To be more direct, is having industry experience the most direct pathway to CREST certification?

You can pass the CREST exam on skill and knowledge alone. It is however very unlikely that someone without practical experience will be able to do so in the limited time allocated for the exam.


What are some secure methods of sending email from your server? This question title might seem a little vague, and I apologize for that. Let me just begin by stating I'm an engineering psychologist—not an IT security or computer guru by trade. As luck would have it, my employer (a very, very big one) has placed me on a small team where I work on a mission critical server that can (ideally) never fail and has to have the utmost security. I do web design, accessibility analysis, user experience stuff — all front-end. Without really thinking about it and without any regard to my skills or background, someone up the chain unwittingly placed me in charge of also making sure the entire system is secure, as at one point our website was listed on senderbase.org with a poor reputation rating.

One of my co-workers seems to think that unix's Sendmail is the root of the problem. Concordantly, we blocked all traffic on port 25 and stopped running sendmail. But because of that, my contact forms using php mail() don't work (requires sendmail). I was told that "there is no way to use SMTP on a server and have a secure server." But I'm less certain of this.

On a clean, uninfected system with ideal security, could sendmail be targeted from the outside and used to send spam email? In other words, are there any secure ways to send emails server side? Or will I have to convert all my contact forms to "mailto:" links, etc?

To be clear: the location of the mail is to a support email we use. It is hardcoded; all email gets sent to this email address and the user cannot change this (unless there are hacking techniques I'm unaware of, which is really my question). The only fields the user can type in are Subject, Message, and From.

There obviously has to be some solution because I see email contact forms all the time on huge, powerful websites. If it was a security weakness, you'd think google, yahoo, facebook, cnn, times, and all those other popular websites would have stopped using it long ago, right?

There is a difference between a mail server that sends emails and a mail server that receives emails from outside. In your case you do not need to receive emails from the outside, so the mail server does not need to listen on port 25.

It is true that sendmail has a long history of security issues and a extremely complex configuration language (there is even a macro language to make configuration simpler).

sendmail is not used on current Linux distribution anymore but there is a number of drop in replacements such as qmail, exim or postfix that will provide a compatible interface and a symlink called /usr/bin/sendmail. If that symlink is used, they will parse the common command line parameters the same way
as the original sendmail did.

On Windows you need to edit the [mail function] section of php.ini to point to an external email server. Since you are sending emails to a fix target domain, it can be the mail exchange server that is responsible to receive emails for that domain. Use host -t mx example.com to learn the name.


Database Encryption Security I am encrypting and decrypting my database data from my web applications API.  If my web server is compromised, what is to keep someone from using that same method to retrieve the data?

For example, say I have a PHP application on my web server that does the database encryption/decryption.  If the web server is compromised, what prevents someone from having access to the key and decrypting the data.

The problem isn't language specific, the problem is storing a key that the web application can use but still be secure from someone who has administrative access to the server.

The answers here are good (both @blowdart and @Tate), but the important thing to take into account, is that if your website is compromised, it's gameover as far as security is concerned - you've been pwned.

The malicious takeover code can do any thing your site can, including accessing your code, running process, database, etc. That means, no matter how you do your encryption, no matter where you put your key, they can get to it and decrypt your data too. Whatever you try, its just obscurity, at best - and worst case, they can just let YOUR code do the hard decryption work and just intercept it afterwards.


Encrypting a password with its own hash I just found out that an e-commerce platform (similar to Shopify) I was planning on using allows me to see my password. I know I can't assume anything and I should (probably) just run away from it, but it got me curious: is there a way to do it securely?
I mean, what if they use the password's hash as an encryption key to encrypt the password itself? If done properly, could something like this be a reasonable solution?
Moreover, does anyone have any idea why on earth an e-commerce platform would choose to do it?
And no, I don't plan to implement anything like this.

If I understand correctly, it sounds like you logged in, then you navigated to the change-password page, then the site populated the disabled password input box with your existing password, then you were able to recover your existing password from this disabled password input box.  If that's the case, then the site is storing your plain-text password - either from the time when you logged in, or permanently in their user database.  Either way, it's bad.
With regard to using a hash of the password as the key to encrypt the password - see https://crypto.stackexchange.com/questions/51820/is-it-safe-to-use-the-hash-of-the-data-as-the-key-to-encrypt-them for some interesting thoughts around this method.  Notwithstanding, I don't think this is what is at play here, because it just becomes a cyclical problem - the site would not be able to populate the disabled password input box with the password encrypted in this manner, without knowing the password.


Is it possible for a vulnerability in one application to be exploited to attack another application on the same server? If for example I have Magento-eCommerce and WordPress installed on the same server. Both have a database each with a different database username/password and both have different login details to the admins.

If there was a serious vulnerability in a Magento plugin that allows Magento to be attacked, can that vulnerability be so bad that an attacker can use that vulnerability in Magento to attack WordPress?

If the Magento vulnerability led to a shell, then that shell could be used to get root access by a privilege escalation vulnerability. When that happens, the attacker has complete control over the system.


"Prey" & "Find my ____" have limited usefulness? I've recently had an iPad stolen, and used the "Find my ____" app to try to locate it.  There's also "Prey" available which does a bit more.  I think there are others but I don't know any names.

But it seems to me that both are useless, because the device cannot receive a control message unless it connects to the internet, and it cannot do that unless someone who knows the passcode unlocks it and selects a WiFi AP.  (Or they happen to go to a location where I have already "remembered" an SSID/password.)

Plus, unless a thief is quite stupid, won't they promptly wipe the device and treat it as a new one?

If an iPad is registered with "Find my iPhone", it can't have iOS reinstalled without entering the password for the iCloud account with which it's registered. The thief can't do a wipe and reinstall. It's certainly true that it has to connect to wifi to tell you where it is, and so you should consider setting your iPad to connect to unprotected wifi networks automatically to help its chances of doing so.


Mod_security for Apache2 blocks cURL! I'm trying to get my users lat. and lng. from their address using Google's geocoding API but when mod:security is enabled, it prevents it and the script times out. How can I add an exception by IP or domain for this or just remove whatever configuration that makes mod_security do this?
I am using the OWASP ModSecurity Core Rule Set Project

UPDATE:

[Sun Jun 26 13:13:14 2011] [error] [client 174.252.196.188]
 ModSecurity: Unable to retrieve collection (name "ip", key "174.252.196.188_fc2ccdca4bf1fc8585b77c1444811dedd59da612").
 Use SecDataDir to define data directory first. [hostname mydomain.com"] [uri "/admin/geocoding.php"]
 [unique_id "EIpfP38AAAEAAA2eAT0AAAAK"]

I have added this line:

SecDataDir /var/log/apache/modsec_SecDataDir

Now, I don't get anything in the error log, but still the same behaviour!

If you can provide the lines in your log file showing what rule is causing the block it would be helpful.
An option would be to use SecRuleRemoveByID to disable the rule that is causing your block.
Alternatively you can white list IP address using a number of different techniches which are listed here


Why is it required to HMAC riv in HDCP 2.3? In HDCP 2.3 (pdf) during the Session Key Exchange, the HDCP transmitter sends also the 256-bit HMAC of riv (HMAC-SHA256(riv, kd)).

Why is it required? Does it prevent any attack?

Let's first break down this (HMAC-SHA256(riv, kd)).

As described in RFC2104, an HMAC can be defined as follows:
HM AC=H(K⊕opad||H(K⊕ipad||text))
where H is the chosen hash function, K is the secret key, ⊕ is the exclusive OR symbol, || is the concatenation symbol and ipad, opad are constant values.

Based on this paper, building HMAC upon the backdoored Merkle-Damgård hash function yields a backdoored HMAC scheme, which is easily forgeable using the backdoor key.

Hence, it is easy to see that after the messages are prepended by k⊕ipad, they still lead to a collision in the inner hash chain of HMAC~h. Since the outer chain is equal for all messages, m and m∗ both have the same tag t. Putting differently, HMAC is not backdoor-resilient just because it uses a secret key. In summary, since an adversary holding a backdoor can forge a tag for a new message, HMAC~h is forgeable and hence not pseudorandom.

Please, refer to paper, for more information.

What is the HMAC?

  A HMAC is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret key. Input is a message and a key, output is the HMAC value. It is used to verify data integrity and authenticity of a message. The accompanying hash function for the HDCP standard is the SHA256 function which works with input blocks of 512 bits.

Why is it required in the HDCP standard?

  In the HDCP standard, the HMAC-SHA256 function is used for the locality check and the calculation of H (HMAC of km). The most demanding HMAC calculation concerning the timing is the one used in the locality check. As mentioned before, the NIOS processor has not enough computing power to complete a HMAC-SHA256 operation within 2 ms. That’s why this block has to be rewritten in VHDL. The HMAC for the locality check has a key size of 256 bits and a message size of 64 bits.

Function of the HMAC-SHA256 algorithm for the locality check:

  The locality check asks receiver and transmitter to calculate a HMAC value of a random number rn (message) and the pre-shared key kd. Before the calculation starts, the pre-shared key kd has to be xored with a pre-shared random number (rrx).
  The random number rn is sent in plaintext to the receiver, the receiver sends back the HMAC value. The transmitter checks now if its own HMAC is identical to the received HMAC.  Only  someone  who  is  in  possession  of  the  pre-shared  key  can  compute  the correct HMAC value. Additionally, it is impossible to conclude the key from the HMAC value, because the HMAC-SHA256 algorithm is a one way function.

Block diagram HD over IP system:

(Kindly provided by Lukas Itin's Master Thesis)


Anti-virus anonymity question Many people pay for VPNs and select the VPN based on whether or not that VPN keeps logs of the user's activities and if so for how long. The motivation is privacy- they don't want their surfing habits to be known. Of course they take other steps , controlling cookies etc to control their privacy also.

My question is how privacy is potentially effected anti-virus software. As far as I can tell virtually all of the anti-virus makers now attempt to identify phishing sites and other malicious URLS. In order to do this, they intercept every url their customer surfs to, in order to examine it for viruses or check it against, say, a black list of known bad urls. \

My question is, aren't these companies in a position to benefit or monetize their user's definitive clickstreams? I read the privacy policy of two, BitDefender and Eset and they both sort of say, to the best of my ability to understand, that you're permitting them total access to all knowledge of when and where you surf, full stop. They then say they might share any information they collect with their partners yadda yadda yadda. This was my understanding of their privacy policies and maybe I am mistaken.

My question is- very many people go out of their way to read the TOS for their VPNs to make sure they're not being logged, but these anti-virus companies make NO promises about any logs they might keep or for how long.

People who are worried enough about getting hacked and privacy that they buy a VPN also are likely to use an anti-virus it seems to me. Is this an example of badly compartmentalized risk assessment ? It seems like the anti-virus companies have and may keep all the information users were so worried about their VPN having and keeping?

Have I got this wrong?

There are two ways in which these lookups may be ~safe for your privacy.

First, these lookups should be encrypted via SSL.  Assuming a good SSL implementation (i.e. assuming nothing like Heartbleed) and a client that quickly revokes rogue certs, this means that third parties cannot directly see your data, so you merely have to trust the lookup server.

Second, the lookups should be hashed.  Because these hashes cannot be salted, somebody with access to your lookups could note what you have in common with others, but won't be able to identify sites for which they have only hashes.

I can't speak to the setup at Eset or Bitdefender, but Google Safe Browsing does both.

An additional protection, which may require some legwork to configure, would be to tunnel connections to this lookup server over Tor or some other network connection (e.g. a proxy) that is decently uncorrelated to the rest of your network activity (which e.g. uses your VPN).  One complication:  some VPN setups won't let you make any network connections that don't pass through the VPN.


how to reset router without reset button? I was trying to enable mac filtering and now I can't access internet, the reset button is broken, is there a way to reset the router or bypass the mac filtering?

Does your router have a power button? In some cases, holding down the power button functions as a reset.

It might help if you told us what kind of router it is.