VPN Appliance Placement Options I'm currently looking to implement a VPN solution (based on a Checkpoint Connectra) purely to provide remote access to staff (no site-to-site, or customer access), but the one design decision I can't quite seem to reconcile in my own mind is the placement of the VPN appliance on the network.

I see that there are several options:

VPN Appliance in the DMZ
VPN Appliance on the LAN behind the firewall
VPN Appliance in parallel to the firewall

The Checkpoint documentation only mentions the VPN appliance on the LAN, or in the DMZ as options. Are there any overwhelming reasons for not having the VPN appliance in parallel to the firewall with a WAN router ACL directing the VPN traffic in the direction of the appliance? Or alternatively any overwhelming advantages to using one of the other two placement options?

For sure do everything you can to to disable all ways to tunnel traffic between your servers and clients. I like the design above:

http://undeadly.org/cgi?action=article&sid=20100321135641


Security risks with handling ZIP archives in web applications I'm researching possible security risks when handling ZIP files, or archives in general, in web applications.

The scenario is the following. The user is able to upload any ZIP (or in general an archive) file, the web application extracts its contents and subsequently offers the extracted files to download again.

I've come across a number of possibilities this may be exploited.

DoS with a ZIP bomb (e.g. 42.zip)
Writing arbitrary files, with relative file paths (see evilarc)
Reading arbitrary files, with symbolic links (see How zip symlink works?)
I assume issues with polyglot ZIP files

The resources on the topic seem quite limited and I'm sure there's more risks associated.

What are possible security risks for web applications handling ZIP/archive files?

and

How can these be securely processed?

And remote code execution, e.g. CVE-2016-2334

There is no 100% secure way to process them, however some mitigations are to make sure that any process used to decompose an archive file runs with the least privilege possible and to limit how long decomposition of a single archive can take place.


Where to store uploaded images from perspective of security It is quite common that uploaded files (images, videos, etc.) are stored on a file server because of performance and database-recovery-time reasons. But is there a benefit of storing such files in database in terms of security?

Most large web applications need to limit database usage, and there is an additional burden by using the database as a file store. Most databases are not really designed for file access, MongoDB is a document store, and is commonly used to store files and related data. Another option is using Amazon S3 to store and distribute content.

Regardless of where you store the files, there is a lot that can go wrong with file storage and retrieval.


Storing all past (user generated) passwords (bcrypted) I am working on application where I want to add support for Event Sourcing and I am thinking how to solve problem of the passwords (unfortunately I cannot delegate authorisation to external service).  The problem I have encountered is the question "how insecure is storing all passwords for given user (with metadata, like time of change), even in hashed form?".

I would just record an event like on timestamp T user U changed the password. Storing anything related to the password makes little sense.

Saving the plaintext password is madness. Saving the same hash as the password storage is madness too. Storing a stronger hashed version of the password does not make sense, why store something stronger on the log? Storing an weaker version undermines security.

Saving just the relevant event data (timestamp, user, maybe application module, IP address, things like that) and leaving out the password is enough.


What's the difference between A and AAAA DNS records? Dnsmasq logs show that A and AAAA records are being transmitted/received.

What is the difference between to these two types of DNS records (A and AAAA)? Can either be rejected/dropped/ignored? (Could this be done within Dnsmasq configuration, if possible?). Extra DNS info welcome.

In DNS, we can have multiple answers and we called them Resource Records, shorten as RR.

Among the RR, there are A, AAAA, MX, NS,TXT,DS and many others. More details are available on this wiki page. The RFC1035 will also offer you some in-depth technical details (see the file header for more reading materials).

A resource record means IPv4 answer (or entry) for the said domain.
AAAA resource record means IPv6 answer (or entry) for the domain.


Opinons: To report or not to report? CFAA vs the White Hat As I'm sure most people here are aware, there has been quite a lot of attention brought to the USA's Computer Fraud and Abuse Act (CFAA) recently. Brief back story: A security researcher discovered that a cell phone carrier made email addresses of their customers available through a non-authenticated service. He pointed it out and now could spend several decades behind bars.
More Info: http://www.f-secure.com/weblog/archives/00002460.html

Without getting into "#FreeWeev" craze, I'm curious about how security minded folks are processing this information and whether it would deter you from reporting a legitimately identified security concern. Obviously people in the USA will have a bit more context on the issue but I openly welcome all points of view on the issue.

Will these rulings keep you from your work, or change it? If so, how?

Thanks!

With respect to how (and whether) to disclose vulnerabilities, that subject has been covered extensively already on this site.

With respect to dealing with a potentially-embarrassing flaw with a powerful organization, remember this little gem:

Powerful organizations do not like to be embarrassed. And one way for them to save face is to incriminate the messenger ("see, we're not irresponsible, he's a terrorist"), and so when doing so, some certain amount of self-protection is in order. Perhaps you should remain anonymous. Perhaps you should seek legal counsel. Perhaps you should work through a third party (e.g. security firm).

Certainly what you should not do is flaunt the vulnerability in a spectacle of  sarcastic derision and self-promotion. It may be safe to poke the bear with a long enough stick, but the only way to know for certain is in a post-mortem analysis of the events. Probably best not to poke the bear if you want to stay on the safe side.


If one user sees an email of another user, is it DSGVO conform? I want to give a logged in user the ability to search for other users by their exact email. The search input is passed asynchronously by Javascript so the email would remain in server logs and so on. The connections are HTTPS only (cookie secure=true). I am based in Austria so i have to handle according to our DSGVO and want to know:

Is this handling in the green, gray or red area?

Additional info:-It is a self coded PHP application using a SQL database

The best answer can only give a lawyer.

To my knowledge, it mainly depends, if there is a legal base for providing Email address of one user to another user. See the Article 6 "Lawfulness of processing" in DSGVO.

A few examples.

  (a) the data subject has given consent to the processing of his or her
  personal data for one or more specific purposes;

One legal reason can be, that all users gave you a consent that their Email addresses will be available to all other users. This may look simple, but it is not. For instance if you maintain a web site for Anonymous Alcoholics, may be your users will not give a consent to show their emails to other users.

  (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

Using your application, some user place work requests, the others provide some services. For instance, one user needs get his house painted. Hi gives a consent to disclose his Email to another users, so that are able to send him contract proposals.

Compliance with DSGVO can be not easy in some cases. Better talk to a layer.


How can I verify a company's identity? I'm a web developer working on a project for a client. To keep it short, the project has company listings. These company listings are not provided by the companies themselves and instead it is just a part of big data, however companies can choose to claim their profiles. However, now I run into the problem of how to verify if the user claiming the company is indeed from the company. By default, we have the company's email whether it is claimed or unclaimed. I can always send an email to that address with a verification token to claim the company. However what if that email is incorrect in our database or no longer in use? I can't let the user enter the email himself else anyone can claim any company. Does anyone have a solution to this problem? Would enforcing the domain of the email be enough? As in, suppose someone was claiming McDonald's as a company, would enforcing McDonalds.com in the email be enough? Does anyone have a better idea?

The most common ways used to verify domain(i.e. company) ownership:

verifying via a company-owned email that you designate (e.g. webmaster/admin/support@x.y - this helps prevent an employee who is not authorized to claim ownership from doing so)
verifying via an html tag of some kind in the homepage (or even a whole html page at the webroot)
verifying via a DNS TXT record for that domain

Ultimately, it will be up to you to ensure that the correct domain is matched to the company. I would recommend that you correlate their live website to the company profile when you create it, so you don't run the risk of someone trying to typo-squat them and then falsely claim the company with that.

For reference, here are a few different examples:

Google: https://support.google.com/a/answer/6248925?hl=en
HaveIBeenPwned: https://haveibeenpwned.com/DomainSearch
ZeroSSL: https://zerossl.com/free-ssl/#howtocrt (check under 'Verification')

Lastly, if they do not have a website, I'd recommend taking a look at Yelp's process for verification:
https://biz.yelp.com/support/claiming

I haven't used them specifically, but I believe they allow for 'offline' claiming of a business(and support a process to dispute or "reclaim" businesses in case they're falsely claimed or ownership changes, etc).


How eavesdropping attack takes place in network I am learning some concepts of network security and I have the following question:

One case of eavesdropping attack is that an adversary somehow places himself inside a network to order to capture the communication traffic between two hosts. In the case, how could the adversary place himself inside this network without being observed by Intruder Detection Systems or any kind of detection systems?

The possibilities of how this can happen are manifold.  An attacker will need control of a single computer within or just outside the network.  Depending on the network, it might be possible to sniff significant parts of the traffic.  It is difficult to detect passive network sniffers.  An IDS might detect tries to exfiltrate the sniffed data, but the details of what's detected or not are highly specific to the IDS that's used.

Furthermore, if the attacker manages to place themselves in an privileged position just outside of the systems protected by the IDS, it will basically be undetectable.

To give you a better grasp of how this might work, here is a not-so-contrieved example of passive eavesdropping: Imagine a data center where anybody can by rent a place for their server.  Now assume that the network hasn't been setup properly, leading to traffic being randomly sent to the wrong machines (yes, that happens).  Those packets could be sniffed by other servers in the data center; no IDS would detect this kind of eavesdropping as it is done outside of the responsibility of the IDS.  The attacker would not be able to see all traffic to and from their target, but sensitive data could be sniffed regardless.


Is it secure to use 3rd party apps like WASender for bulk WhatsApp messaging through WhatsApp web? A client collects phone numbers through lead form on his website and he is hell-bent on sending WhatsApp instead of email. To build a solution from scratch is out of the question of after some research I came across Wasender, they claim to provide an API just that ([How it Works][1]).

They've got good reviews on the Chrome web store and all with a lot of users but I am not sure if it's safe. There's always some risk with small 3rd party integrations but has anyone worked with something like this? Is the data safe? If you have used something like this, is there a way the integration could bypass WhatsApp's encryption? Just don't wanna end up with the client's critical business info leaked.

...  is there a way the integration could bypass WhatsApp's encryption?

It does not need to bypass any encryption. It is a browser extension and as such it has access to the messages the same way as the Whatsapp in the browser has - in fact, you grant the extension access to web.whatsapp.com and thus to all your messages since these are no longer encrypted in your browser.

  Is the data safe?

Which data, against what? The messages are send using your WhatsApp account. They might be changed by the extension before sending but they are delivered encrypted from your phone to the recipient. The extension could also read your existing messages.
 I'm not saying that the extension does anything like this but it could based on the permission you grant. And even if it doesn't do this now it might do it later, or never, or instead send their own ads using your contacts ...
If you feel comfortable with this then it might be safe enough for you.


Does HTTP/2's opportunistic encryption potentially allow man-in-the-middle attacks? HTTP/2's opportunistic encryption of http URIs using TLS appears to allow the possibility of man-in-the-middle attacks. Is that true?

RFC for opportunistic encryption.

Here's HTTP/2's spec for opportunistic encryption.

Opportunistic encryption assumes only a passive attacker (i.e. sniffing only) and thus of course makes man-in-the-middle attacks by an active attacker (which can modify the connection) possible. This is not restricted to HTTP/2 but a general limitation of opportunistic encryption. See also Wikipedia about this topic.


How to decrypt a file encrypted under multiple public keys GPG According to https://www.gnupg.org/gph/en/manual/x110.html

  To decrypt a message the option --decrypt is used. You need the
  private key to which the message was encrypted. Similar to the
  encryption process, the document to decrypt is input, and the
  decrypted result is output.

Scenario:

Bob has a file, he wants to keep the file secret. He wants only wants his friend Alice, John and Paul to be able to look at the file.

He encrypts the single file with each of his friends public keys.

His intention is, that whenever for example Alice needs to look at the file, she does not need to be with the others to access it.

An Attacker finds the encrypted file.

What i'm asking is:

Would the attacker need to find out each of the friends private keys in order to decrypt it?
Or would the attacker only need to know one of the friends private keys?

There are two possible interpretations of your question. I'll asume what you have in mind is the following:

Suppose your friends have key pairs (sk_1,pk_1), (sk_2,pk_2), (sk_3,pk_3) and e(pk, data) encrypts and (sk, data) decrypts and p is your plain text.

First interpretation

You encrypt like this:

c = e(pk_3,e(pk_2,e(pk_1, p)))

Then, yes, to decrypt c you need to do

p = d(sk_1,d(sk_2,d(sk_3,c)))

e.g. need all your friends' keys.

Note that the ordering in crutial and that no single user can decrypt the data nor can it be salvaged whenever one key is lost.

Also, this would require your friends to in turn share the intermediate results (because no one will giva away his secret key, hopefully) with one another and the decrypted file. Especially the last step might impose other security concerns if not carefully done.

There are however systems that require a group of people to work together for decryption that are tailored for that purpose, which GPG is not.

Second interpretation

The other interpretation is:

You create one file for each friend, like

c1 = e(pk_1, p)
c2 = e(pk_2, p)
c3 = e(pk_3, p)

Then each one of your friends can decrypt 'his/her' file on their own.


What's the difference between an executable signed with a Windows Digital Signature and one signed with PGP? I'm trying to figure out how to establish trust in Windows executables that I download from the internet.
Some software that I download, such as KeepassXC, has a Windows Digital Signature, but they also provide a PGP signature that I can manually verify using a certificate that I get from their code repository.
Other software that I download, such as my tax software, is also signed with a Windows signature but they don't provide a PGP signature that I can verify.

Does a Windows Digital Signature and a PGP signature perform the same function?
Is one or the other enough to trust that the executable hasn't been tampered with by a third-party? If so, why does some software provide the additional PGP signature and tell me that I need to validate it, if that software is already signed?

Does a Windows Digital Signature and a PGP signature perform the same function?

Well, yes and no. The windows digital signature you refer to is present because Windows requires all executables to be signed. Otherwise Windows will complain that the executable is from an untrusted publisher and Defender SmartScreen will block it. Windows uses it to verify the that the executable has been signed by a reputable publisher (just signing is not enough, you also need a positive reputation). Of course since its signed, the executables integrity is also verified. Almost.
So if the digital signature on the file already verifies the file's integrity, why use PGP too?
The thing is KeePassXC is software used by security-conscious people. And quite a few of these people are (often right-fully so) extremely paranoid. The problem with the Microsoft Authenticode certificates used to sign executables is that they are issued by CAs trusted by Windows. And CAs can (and have in the past) be hacked or go rogue. So if a CA was compromised, went rogue or forced by a government, they could issue a fake Authenticode certificate under KeePass's name. Then any software signed with it would pass as verified KeePass code, and a fake backdoored but signed version can be distributed to users. That's a risk the paranoid folks would rather not take.
So the solution is to sign it with their own PGP key as well. Now anybody who verifies the PGP signature on the executable can be sure they aren't using a backdoored version signed using a fraudulent certificate.


What process would add gdiplus.dll and msdia80.dll at the root of a hard disk I added a new 4TB hard disk drive to my desktop computer, and noticed a couple of days later two .dll files at the root of the drive.

The environment in question is a 64-bit Windows 7 Professional (American English, if that matters). This new hard disk does not contain the OS (the OS is on a separate SSD disk). I have not installed any applications to this new hard disk.

Being that the OS is on a separate disk, what would be the reason for some process to place dll files on the root of the new HDD?

These are commonly the artifact of installing the Visual C++ redistributable package, often installed with many applications and video games. It's worth noting that Steam installs this package with a large number of games.

Some more info: http://support.microsoft.com/kb/927665


How to check which process is modifying my clipboard? I'm on Windows 10 last build and for a few days it looks like I have a malware that modifies ethereum addresses in my clipboard.
I sadly tried a lot of antivirus, antispyware and nothing is found. I think I have a FUD malware.
Is there a tool to catch a process that modifies my clipboard? Maybe any sysinternal tools?

You can reboot, close every single auto-start program you have, close anything not crucial, copy one Ethereum address to clipboard, paste it somewhere and see if it changed.
Then you could use Process Explorer to list every single running process, and run strings (form SysInternals too) on each one searching for the changed address. Unless the address is obfuscated in some way, it can reveal the culprit.
If you cannot find it using strings, use Volatility to take a memory dump, and check the dump later to pinpoint which process have the changed address in memory.


Perform XSS on a link where image path is passed in querystring I have a page on my website like this : domain.com?img=test.jpeg
And on the page, the javascript written is:

var imgPath = getQuerystring('img');
$("#img").attr('src','/Images/' + imgPath);

I was wondering if someone can manipulate the querystring to do something mailicious.

Since the javascript is always appending the path with '/Images/', I hope its not vulnerable.

But then I changed my js code to this:

$("#img").attr('src',imgPath);

Now when I passed a malicious querystring like this:

domain.com?img=alert('XSS')

But whoops, it didnt show me the alert box.

Is this kind of attack taken care of by our Web browsers?

XSS isn't just about making alert boxes appear and redirecting to other pages, there are other things it can do. ;)

What are you doing with the input that the user specifies? Does this get stored in a database, or is it used to retrieve images?

The input that you are taking in, does it get redisplayed anywhere on your site? If so there could be a persistent XSS issue, as you have stored the input that an untrusted user has given to you.

Best answer is to make sure you strip any special characters from that field before using it elsewhere in your application, as this nullifies the XSS risk.


WiFi security in 2018 On my wireless network I have implemented WPA2 protocol with AES encryption. Last year there was several warnings that WPA2 is broken, hacked. Now there are announcements that WPA3 is comming in 2018. But until it comes, and everyone accepts it (wifi devices and clients) it may pass much more time. My wifi equipment has the possibility for RADIUS authentication. Should I implement it now, while waiting WPA3, or maybe RADIUS authentication could be permanently safe solution?

You bring up a number of topics, but in the end only really ask one question. Let me address some of the topics mentioned briefly by referencing some of my other answers here.

  Last year there was several warnings that WPA2 is broken, hacked

This would specifically be referencing KRACK. While this was a major security find, the real world implications of this vulnerability are limited. See my answer here for more on my reasoning that KRACK isn't really a major concern.

  Now there are announcements that WPA3 is comming in 2018

I go through a number of details regarding WPA3 in my answer here. Feel free to check it for more information. The key point I keep making to people though is that while WPA3 is proposed by the the WiFi Alliance, to my current knowledge it is not in any way related to a current 802.11 amendment (which is the actual standard defining wireless networking operation).

  My wifi equipment has the possibility for RADIUS authentication. Should I implement it now, while waiting WPA3, or maybe RADIUS authentication could be permanently safe solution?

Now to your question. This is really a question that is begging for opinions as different people will have different reasons to say yes or no to it.

Let me say that this is something you must decide for yourself. 802.1X RADIUS authentications are much more secure than using PSK, however it is still using WPA2, so that doesn't change.

Keep in mind that security and usability are often at odds with each other. Adding the additional security of 802.1X authentication to your wireless environment will make it more secure. But you will have additional complexity in configuring your clients properly to take advantage of the extra security. Additionally, many consumer devices (game systems, media players, etc) do not support 802.1X wireless authentications.

In the end, you must decide for your environment if the extra effort/complexity is worth the extra security. For some it will be, for others it won't.


Does keeping a password history increase the risk for the user? It's common practice in many system to keep a password history for different reasons (mainly, prevent the user from reusing them).

Answers like this one suggest that they are usually kept on the same format (which makes sense, in order to easily check it on password change).

Answers like this one suggest that they are often kept in the same database system.

So this makes me wonder: Doesn't this make a breach in the database all that much worse, since an attacker would have multiple passwords associated to that user/email which they can try to login in other systems (since a lot of people have 3-4 passwords that they reuse)?

Alternatively, if you have a mental algorithm for passwords, it could be deducted (not sure if anyone would bother, but for a high profile account, maybe) from the multiple samples.

Is there actually additional risk? Is this risk a concern? In which case, are there best practices to mitigate it?

If system A stops people from reusing passwords (and therefore keeps a password history) it is good for the security of system A. It ensures that passwords are regularly changed.

If it takes a year to crack the average password, but passwords are changed every half year an attacker can not get much value out of a data breach. Sure, you don't have to be a genius to guess what comes after password1 and password2, but it is still better than just keeping password.

You are right to point out that storing multiple hashed password gives an attacker more value if they want to attack system B, where users might have reused passwords from system A. But if your main concern is to protect the assets of system A, and not protecting your users in general, that doesn't count for much.

So I would say it is a question of what you want to protect. If you only care about your own system, go for a password history. If you care about users that are reusing passwords being vulnerable on other systems, then don't. What one should or should not care about is inherently subjective, so it can not be answered here.

(There is also an argument that forcing password resets makes users pick worse passwords, and therefore should not be done at all. I'll left that aspect out of this answer since I don't think that was what the question was about.)


Reliability of Padding Oracle vulnerability testers I recently ran my website through the Qualsys SSL Labs SSL Test. My website got a grade "F" with this message attached:

  This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.

Being bothered by this, I contacted my web host about my concerns, and the response they gave me was:

  The scoring is false, since the distro we using, it uses Open SSL, but it is patched while retaining the original numbering version. it is already patched but Redhat do not change the OpenSSL version to latest version due to how they build their packages.

This sounded fishy to me, since I didn't think it made sense for such a test to check what version of OpenSSL is running (how do you even check for that from the "outside"?), but rather to test that the vulnerability is present by trying to execute an attack against it. So I complained some more, including letting them know that other vulnerability testers mark it as vulnerable. Their response to that was:

  It is already patched. Just they report it as bad due to the version number reported when checking it. Lot of checkers fails it due to that specfic reason itself.

Should I trust the response from my web host, or should I run as far away as I can as quickly as I can? If they are telling the truth, are there vulnerability testers that are not fooled by incorrect OpenSSL version numbers?

The version would most likely be checked based on HTTP header or default error pages. This also seems to be the assumption of your hoster, which says that they are sending out the wrong version, which results in false-positives.

Qualys however says that they do not test this via version, but via a test that is based on this test.

Cloudflare describes the test (and also the vulnerability itself):

  Detecting a vulnerable server is as easy as sending an encrypted message which decrypts to AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, and checking if the TLS alert is DATA_LENGTH_TOO_LONG (vulnerable) or BAD_RECORD_MAC (not vulnerable)


Configuring Argon2id for Multiple Threads We're using argon2-jvm to use Argon2id on our Java TCP Server.

Because its argon2id instance is thread-safe, we plan to only create a single instance for the lifetime of our app and have each request handler call it whenever necessary (e.g. for new registrations and user log-ins).

We've fine-tuned our single argon2id instance so hashing and verifying passwords both take roughly 1 second on a single thread using the approach from this answer:

Use the max number of threads we can use (no. of CPUs x 2 in our case).
Use the max amount of memory we can use.
Tweak the number of iterations so it does not exceed our target max time (1 second in our case).

However, when the number of threads (TCP requests) accessing our argon2id instance increases (e.g. there are multiple users registering and logging in), its execution time increases as well.

Our plan now is to reconfigure our argon2id instance such that it still takes roughly 1 second to hash and verify passwords, but instead of doing so on just 1 thread, we'll be doing it on our expected max number of concurrent registrations and log-ins at any given time (e.g. 500 TCP requests).

Our concern is that, if we do so, then our hashes might not be secure enough because each request won't be getting as much processing as it should (e.g. a hash that takes about 1 second on max capacity might take only 0.25 seconds when it's the only request being made).

We feel that configuring Argon2id for max capacity is going to undershoot a secure configuration for each individual request. Is this how it's supposed to be done? Or should we stick with our configuration that takes 1 second on single threads but takes longer on multiple ones (we fear this might take too long for too many requests)?

UPDATE: I also asked the Crypto subreddit for their thoughts here.

There is no perfect solution. There is always a trade off between security, price and user experience. If you want to get both higher security and acceptable response times, consider using more hardware resources (higher price).

First estimate the risks to decide what security level you actually need. What are exactly the threats? What benefits can an attacker get in case of successful brute-forcing of single password? What will it costs for the attacker to brute-force a single password? Are the possible benefits and the costs commensurate? Does it make sense for the hacker at all? What can be costs to you and to your users to provide particular level of security? E.g. if you reduce the number of requests per server/container from 500 to 100 (to enable more hashing iterations) and increase the number of servers/containers x5, will be the price x5 acceptable to you?

Also we should distinguish two basic use cases.

There is a single user. For instance, a user on a laptop uses hash (derivated password) as a master password in password manager, or to encrypt/decrypt a drive.
Then it makes sense for a single hash to use as much resources as possible.
There are multiple simultaneous requests, for instance in some web application. If some requests require too much resources, other requests (normal requests that don't use password) will notice degraded performance.

The number of threads: The main purpose of this parameter is to load memory bus as much as possible. But normal CPUs have only 2 memory channels, where as many graphic cards have 6 or 8. Thus, exhausting your server you don't exhaust the resources of the attacker. Means, it does not necessarily increases your security. That's why I'd suggest to use 1 thread.

Memory: Your application is probably performing a lot of other logic besides hashing, like evaluating permissions, calculating some business logic, searching data for particular complex criteria, creating reports, etc. How much memory need such requests? How much memory can hashing use so that the performance of the main functionality remains acceptable? May be after analysis you will conclude that you can use for hashing not more than 5% of the available memory. Just model and calculate.

The number of iterations: Then tune up the number of iterations to get the acceptable response time.

Then check your assumptions on the real environment with real users. If you see that performance is not sufficient, you can still tune them. After password validation against the old hash succeeded, you can rehash the password with new (optimized) parameters and save to database.


Is it secure to centralize database information? I would know if it is secure to centralize database information into one file like this :

db_infos.php:

$server = "localhost";
$user = "root";
$password = "1234";
$database = "foo";
$table = "bar";

And then, include this file when I need to:

include("db_infos.php');
mysql_connect($server, $user, $password);
...

Is there any way to get the database information, else is there other ways more secured or more relevant (both are accepted ;p )?

If it's not secure please tell me why, and how it will :)

I'd say it is as secure as the directory it is placed it.

The ideal place to store the database connection file would be outside the web root. In this way, an attacker would not be able to gain access to the file using directory traversal attacks.

More information on directory traversal: http://en.wikipedia.org/wiki/Directory_traversal_attack

This page also has more information on the subject: https://stackoverflow.com/questions/6322766/php-basics-where-to-store-mysql-password-used-by-php


Security concerns with iframes Are there any security concerns I should be aware of, if I want to give users the ability to embed iframes(for things like Youtube videos) in their generated content on my site. The user generated content is editable by them, so I can't control iframe options like sandbox(though I might be able to do a check on the content when it comes to the server and insert appropriate options there).

If there are risks, I am thinking of either

checking the domain of the iframe being inserted and only allowing select domains like Youtube.

OR

only allowing a select group of trusted users to add iframes in their content.

Thanks.

The Origin-inheritance rules for iframes will prevent malicious content within an iframe from accessing the DOM of the parent.

Allowing sensitive control functional,  like administrative pages to be placed within an iframe exposes you application to clickjacking.  As a result most security-aware application disallow iframes with the x-frame-options.

Iframes can be a vector for XSS if you do not use proper sanitation:
<iframe src='javascript:alert(1)'> </iframe>


What's the right way to provision, share and store (in a db) cryptographic keys? Two systems must share a secret for JWT signing. The secret has to be shared and stored. Are there tools and there guidance for doing this securely?

The first step is to ensure your application is secure, not just to protect the secret in question, but also the application as a whole. If your application is perfectly secure, then there will be no possible exploit, and the secret is safe. Unfortunately, we are not perfect and it is likely that there is some vulnerability lurking in the application that has yet to be discovered.

The following points will help you reduce the impact, should a vulnerability be found and exploited in your application:

Store important secrets outside of the database, -or- you could store the encrypted secret, with its decryption key outside the database.

One of the most common exploits exploits is to gain access to data via SQL Injection. If the secret, or the key that encrypts the secret is stored in a file outside the database you have eliminated that attack vector.
Use the strictest possible Filesystem Permissions possible on the file. It is best if the only user account which can access that file be the application in question.

Other applications can run on separate user accounts so that if those applications are compromised then your secret will still be safe.
Physical or VM separation is even better. The point again is that you do not want exploit of unrelated applications to compromise a secret that is only used by the application in question.

One inexpensive way to achieve physical separation would be with a small computer on the network such as Raspberry Pi or HSM, with a single dedicated purpose. Since your particular secret is itself a cryptographic key, you could outsource the cryptographic operation physically. That device could have only very simple software running on it so you know there is no way to extract the cryptographic key without physically removing the storage media.

In this quote, substitute "deficiencies" for "vulnerabilities" and it still holds true:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C.A.R. Hoare.
I'm not familiar with the operation of your service, but if it is accessed via Username and Password, then you could use user-defined passwords to derive keys to decrypt the secret as needed. I've outlined how that would work here: How can we serve sensitive encrypted data without storing the key? Should I use user-defined passwords for keys? However, that solution will not work for an autonomous system, because the user's password and session key would not be available.


Meterpreter shell and system shell define? What is the difference between Meterpreter shell and system shell?

For example, if I found some vulnerability in a system which allowed both shells, then what should I go for, system shell or Meterpreter shell?

What kind of stuff can I do with meterpreter shell but not with system shell and vice-versa?

In the context of your question, a system shell is something like cmd.exe powershell.exe bash ash sh running on the target machine and which you have access to via some network connection.

A meterpreter shell on the other hand is an application that wraps a system shell to make certain tasks easier. Such as transferring file, migrating between processes, dumping memory etc. You can access the system shell from meterpreter by typing 'shell'

Learn more about meterpreter here https://www.offensive-security.com/metasploit-unleashed/meterpreter-basics/


Is testing for SQL injection vulnerabilities still relevant in modern web applications? First some background:

I'm an Infrastructural Engineer with 5 years of experience mainly in Virtualization and Networking.

I've spent the past year doing a lot of self study about security, passed the Security+, read Web Applications Hackers Handbook and made some good money finding bugs using Bugcrowd and Hackerone.

Whenever I look for vulnerabilities, I always skip SQL injection as most modern application don't show any sign weakness against traditional SQL Injection methods shown in books or online tutorials.

Now, is this the case for other security enthusiasts? How do you approach this? I try to send a lot of unusual characters but the best the result I've got so far was error 500.

Thanks in advance

Actually according to OWASP, SQL Injection is on top of the top 10 Vulnerabilities through Web applications.
https://www.owasp.org/index.php/Top_10_2013-Top_10

and there are many papers, article, news about concerns in this subject and every day there is a news about SQL injection attack against famous web applications such as for example Joomla,Wordpress or websites and so on, so we can not say that " modern application don't show any sign weakness against traditional SQL Injection methods" because every day a new SQL Injection method is introduced.


Is it possible to set permissions on a per application basis? I wold like to set permissions on a per application basis, permissions like:

Creation of sockets
Creation of sub-process
If an application creates a sub-process child processes should inherit the same permissions
IPC
Shared Memory
System mutexes
Limit read/write to specific folders and files
etc

I'm using Windows or Linux, both are fine.

Is there any built in functionality or even a third party tool?

Giving a linux-specific answer, I think SELinux (available in Red Hat like distros)  or AppArmor (available in SUSE and ubuntu like distros) is exactly the thing you are looking for.

To quote wikipedia's AppArmor page:

  AppArmor ("Application Armor") is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths.

When you consider that almost all things in linux (sockets, shared memory, etc) have file paths, SELinux / AppArmor applies to most system resources.


Sharing wifi at a business - Bad Policy? Is it safe for a small business to let customers use their wifi while waiting?

My friend is starting up a small dentistry practice (1 dentist), and I'm setting up his computers/wifi as a favor.  He'll have a waiting room and wants it to be a pleasant experience for his customers and thinks the wifi password should be easy so the receptionist can give it to patients.  (Though he doesn't expect patients to wait long or most to ask and expect wifi).

I'm telling him he needs a very strong WPA2 wifi passphrase and to keep it private (his business is in city with other businesses/apartments nearby) or else someone malicious could start openly stealing his wifi and either do illegal things with him liable or just severely slow down their connection (which needs to be fast; they plan on using cloud-based services).

Is there a secure way to let the public use your wifi that is monitored by non-tech savvy people (once properly setup)?  Or is the only option for small-scale users (without enterprise solutions) to just not allow random users on their wifi?

Simple MAC address filtering is probably too burdensome on the receptionist (getting patient to find MAC on their device; typing it correctly; and removing it after the patient leaves).

Would it be possible to say have a whitelist of a few MAC addresses that we use; and allow other MAC addresses ~2 MB of unrestricted bandwidth at which point their connection starts getting severely throttled?  Or is it possible to setup a scheme to generate one-time passwords that will expire after the first of ~2MB or 2 hrs of use?

You can't allow customers to be on the same network as your own computers.

A lot of new WiFi access-points take care of this for you, by creating two wifi networks, where the "guest" network does not have access to internal computers. The Cisco/Linksys 4200 is what I have at home for guests, and it's easy to setup, but there are many other systems that have the same feature.


Is it a security risk to give out ssh key and one of or both public and private keys to my webhosting provider? My web hosting provider requires my ssh password and one of or both private and or public ssh keys to setup ssh access. This seems like a security risk to me. Aren't private keys supposed to stay on your machine. If I gave out my ssh password couldn't they just create my private and public keys themselves? Wouldn't that allow them access to my machine? Or am I mistaken?

For clarity: it's on the hosting providers website that they are asking for the ssh key and one or both public and or private ssh keys in a web form not an error openssh terminal connection or human interaction. They have two text areas that you can choose one or both and they are for your public and private keys. Then they have one mandatory text area for ssh key.

Im used to gaining access to sites that allow ssh by only giving out my public key so this seems fishy.

Also hoping this falls under risk management as Im trying to understand if this is a risk to my machine.

The note at the bottom of your screenshot is says:

  Note: you don't have to import both keys. It is perfectly acceptable to just import a public OR private key if that is al you need on this server.

So it depends on what you need the keys for.

To log in to a server you only need to upload your public key (to an ~/.ssh/authorized_keys file or the equivalent), but when you're going to authenticate from that server to other services, a private key may be needed. (One scenario is for instance when you download code from a repository with git and authenticate with a private key file...)

Please note that cPanel is designed to simplify the process of managing a domain and hosting a web site to the website owner or the "end user" not for security experts, power users  and expert system administrators.

In that context offering the option to generate and manage SSH keys server-side from a web panel and providing an option to convert between the openssh format and PuTTY pkk files is, although not the most secure, a reasonable compromise between usability and security. It is certainly a big step up from authenticating with usernames and passwords over plain text FTP which was the standard in web hosting for far too long.


How does Android's security model differ from UNIX's? In UNIX's security model, you log in as a user, and then every process you start can access everything that belongs to your user account - that is, the trust is based on the user account, not on the particular executable.

But on my Android phone, it seems things are slightly different - every app seems to run under its own user account. Is that correct? Or is it that apps made by the same author run under the same user account? Does the author's private signing key give access to the user account?

Also, I read that the Linux kernel was modified to accommodate Android's security model:

  In order to get a working Android system, you need the new lock type they have created, as well as hooks in the core system for their security model. In order to write a driver for hardware to work on Android, you need to properly integrate into this new lock, as well as sometimes the bizarre security model.

I'm particularly interested what these kernel changes were, and why are they bizarre?

Android essentially relies on the Linux Kernel's security theme's for its security model:

User based permissions
Process isolation
Mechanisms for inter-process communication
Modular kernel that can be customized (insecure modules removed/modified)

Bizarre seems like a strong word, but Android definitely went a little extreme by combining process isolation with user based permissions.  You're absolutely right, for each app a user is created.  It is independent of the author of the program.  If there are multiple apps from the same author then each app gets a user created for it.  The private data for each app is protected under this user's permissions, and so is the process space.  In this way only the app can access its private data, and it's process space can only be accessed by the app.

Apps can talk to each other through IPC, and the main addition to the kernel in this respect is the Binder class.  This addition allows a background service to interact with apps, and courier data between processes.  When created in this manner it does not live on indefinitely in the background, but is created with a specific purpose and is killed once it's fulfilled.

For more detailed information I'd suggest reading Android Security Overview.


Can someone explain what exactly is accomplished by generation of DH parameters? I'm setting up a node.js server:

https.createServer({
    ...
    ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
    honorCipherOrder: true
}, app).listen(443);

This is a able to achieve a SSLLabs A rating, which is good. Now, it appears that all of the negotiations in the handshake simulation are performed using TLS_RSA_WITH_RC4_128_SHA.

RC4 is resilient against BEAST. If we are vulnerable to BEAST we cannot get an A rating.

I would like to support PFS (forward secrecy) if supported by the client.

Based on my reading I "must generate some randomness" by generating Diffie-Hellman parameters and get that into my certs somehow, before the server will properly implement ECDHE for forward secrecy. I read somewhere that ECDHE is less CPU-intensive than DHE, so that is a plus.

Well, I have a lot of questions. But I will ask the first one:

Why must I generate "some randomness" to append to the certificates, what purpose does it serve, and what does the command actually do? The OpenSSL page on dhparam doesn't tell me a lot about what it actually does.

I have seen this answer and am looking for a more clear explanation (or at least references to relevant reading!).

According to OpenSSL Ciphers it looks like ECDHE is a TLS 1.2 cipher. On Qualys' PFS page it says that ECDHE is supported by all major modern browsers, and yet I only see iOS6 in the results from my SSLLabs test connecting via TLS1.2. I guess I can take the "handshake simulation" section with a grain of salt.

Another question is why SSLLabs rates with an A if I leave the HIGH entry in the cipher list: This would have the server support a connection e.g. TLS_RSA_WITH_AES_128_CBC_SHA (the report indicates as much), which is vulnerable to BEAST! Perhaps because it never tested with a "client" that reports no RC4 support.

One more question: On the OpenSSL Ciphers page the list under TLS 1.2 cipher suites includes:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256

Does this indicate that if I do get it connecting with ECDHE that is now vulnerable to BEAST as well due to the use of CBC? E.g. I should switch this to do as Google does: ECDHE with RC4. But the Ciphers page does not include anything that looks like ECDHE-RSA-RC4-SHA. There is however a ECDHE-ECDSA-RC4-SHA. How is this different? Edit: this SO answer mentions that ECDSA is something separate from RSA. I'd like to replicate what Google's doing with the ECDHE_RSA+RC4+SHA as that seems like the perfect blend of performance and security.

More notes (please tell me if I have misunderstood things, especially the statements disguised as questions):

BEAST resilience is controlled through the selection of the symmetric cipher (RC4 vs AES, etc). Modes of AES not using CBC are not supported by many clients? So we should just avoid AES altogether...? PFS is may be obtained through the use of Diffie-Hellman key exchange, and only the modes that include either DHE or ECDHE satisfy this. Only OpenSSL supports perfect forward secrecy. RC4 is faster than AES. RC4 is better than AES (because of BEAST)?

Another edit: Let's see... here is an indication that BEAST isn't something to be too realistically concerned about, though it negatively affects SSLLabs rating. That big "A" looks so good... Let's see... I should probably still put the RC4_128 ciphers in the beginning of the cipher chain if for no other reason that they have not been shown to be "broken", and are faster than AES generally. Anyway I've strayed far away from the original topic which is ECDHE. And how to get the DH parameters properly working with Node/Express?

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and eventually acquires the private key, he can use that to decrypt the session key from SSL exchange, and then use that to decrypt the whole session. So that's not perfect forward secrecy.

The key here to Perfect Forward Secrecy is the Diffie-Hellman key exchange. DH is a very cool algorithm for generating a shared key between two parties such that an observer who sees everything -- the whole exchange between the two parties in the clear -- cannot derive the key just from what is sent over the wire. The derived secret key is used one time, never stored, never transmitted, and can never be drived ever again by anyone. In other words, perfect forward secrecy.

DH alone can't protect you because it's trivial to play man-in-the-middle as there's no identity and no authentication. So you can continue to use RSA for the authentication and just use Diffie-Hellman to generate the session key. That's DHE-RSA-*, so for example: DHE-RSA-AES128-SHA1 is a cipher spec that uses Diffie-Hellman to generate the key, RSA for authentication, AES-128 for encryption, and SHA1 for digests.

But Diffie-Hellman requires some set-up parameters to begin with. These aren't secret and can be reused; plus they take several seconds to generate. But they should be "clean", generated by you so you know they're not provided by an attacker. The dhparam step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.

Some recent bit of research showed that while "breaking" a DH exchange (that is, deriving the key from the traffic) is difficult, a fair amount of that difficult work can be done ahead of time simply based on the primes. This means that if the same DH primes are used everywhere, those become a  "prime" target for well-funded agencies to run their calculations against. This suggests that there is some amount of increased safety to be had in generating your own primes (rather than relying on those that come with your software), and perhaps in re-generating those primes periodically.

An interesting bit is that Elliptic curve Diffie–Hellman is  a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating.

See also:

What is ECDHE-RSA?
SSL/TLS & Perfect Forward Secrecy

With respect to BEAST
The BEAST attack relies of some artifacts of the block chaining method used with AES on older versions of SSL. Newer versions of SSL do things right, so no worries there. RC4 is not a block cipher, so there is no block chaining. The BEAST attack is so absurdly difficult to pull off that its real-world implications are decidedly nonexistent. In fact, RC4 has some weaknesses of its own, especially when when abused the way the BEAST attack would have to do. So you may not actually be getting any better security.

Certainly forcing TLS 1.2 would solve all your theoretical security problems, while at the same time preventing many visitors from actually connecting. Not entirely unlike using ECDHE.


chrome invisible flash document I have it so flash doesn't start on page load for security and performance. Lately I have been noticing That some pages will load with a flash document that takes up the full screen. I can see it as it has not started running and gives the gray box to enable flash. I found that when this flash document is loaded it is invisible and tricks the user by taking the click actions of the user when the user thinks there clicking on the page. I would like to know what this is and how to get rid of it all together. It looks to be used to reroute users to advertisements. I have noticed it on a lot of news websites from google news.

Has anyone else discovered this on a website and found out what it is and how to stop it? So far what i have to do is as the flash document has not loaded I can right click on it and have it hidden and not run. This feels like a workaround for something that a user should not have to deal with.

Clickjacking is an old problem of the HTML world. There isn't a really good way to "fix" it from the standards point of view without breaking a lot of existing pages.

But I don't think Flash-based clickjacking works anymore in Chrome (nor is it really necessary) because Chrome now requires you to right click on a blocked plug-in to activate it and the context menu clearly says you're enabling a plug-in.

What you saw is more likely just a normal iframe doing clickjacking. This is allowed by all browsers by default and is way more damaging as it also bypasses the same origin policy that Flash would follow.

Installing NoScript can help you defend against them.


Is it safe to transfer location data by using TLS? Is it safe to transfer location data by using TLS with self-signed certificates?

I read a lot of varied discussions on the web which makes me to ask about the subject.

TLS encryption is obviously strong enough to protect your data.  The weakness in this question is the integrity of the keys involved.

Certificates protect the integrity of keys by making sure that no attacker has swapped a legitimate key for a fake key, and is intercepting messages in an Attacker-In-The-Middle attack.  The way certificates protect against this is by being signed by a root Certificate Authority that all computers in the communications network agree in advance to trust.  By itself, a self-signed certificate has no such integrity, because none of the participating computers knows to trust it.

There are a few ways around this issue.  The first (and safest) is to get the key signed by a trustworthy Certificate Authority, instead of being on a self-signed cert.  Most CAs charge a fee for a certificate (which can be off-putting).  Your DNS provider may offer you a few free certificates as a part of their service.  Let's Encrypt offers CA signing to anyone for free, and you can run the whole process through their API.  The advantage is that your system's security will be "normal" and your keys will be as protected as any other site; the disadvantage is the small extra effort involved in learning about the process and getting the signed certificate.

Another way is to generate your own custom Root CA.  OpenSSL can be used to generate a CA self-signed certificate, which can then be used to sign other certificates, such as your location server's certificate.  Google will return plenty of examples of how to do this in just a few calls to openssl.  Next, on all the computers where you want to trust your location server's communications, you install the custom Root CA certificate in each system's Trusted Root certificate store.  You then use the custom Root CA to sign your location server's keys, and those computers will trust them.  This seems easy, because it's just a couple calls to OpenSSL, and installing a new root certificate.  And your data and key exchanges are protected.  However, the drawbacks are larger than they seem: all the computers that trust your custom CA are now susceptible to spoofing any TLS communications if someone manages to compromise your homemade CA's private key.  (This may also be problematic if you don't have the authority to install a new root CA on all the computers involved.  For example, your workplace would likely have a security incident if your company PC had your homemade certificate installed on it.)  You can mitigate some of this risk by cautiously creating your custom CA, keeping the private key offline on a thumbdrive stored in a safe, etc., but that's a huge amount of work for very little benefit, and nothing can solve the problem of installation on an externally managed computer.

There is a third option:  look at the certificate with your eyeballs and make sure it's the same certificate you started with -- every time you use it.  While this will work, it only protects one key exchange at a time.  A year from now, if you get careless and forget to check the certificate before exchanging data, it's possible an Attacker-In-The-Middle could strike and you wouldn't notice.

A fourth option, which is where I think you were going, is to ignore the integrity of the key exchange entirely, and hope no attacker tries to intercept your communications.  Of course, if you're attacked, you'll never know.  And if you can live with that risk, why bother encrypting it at all?


Is there any point in preventing apps from running on rooted phones, if you also offer a web interface? Some banks prevent their apps from running on rooted phones, for alleged "security reasons".

However, you can usually use their services from the web interface anyway.

Using the same phone, having the same features.

Moreover, the web interface can, again, be accessed from any desktop computer, where every application have much more freedom than those on mobile phones.

So, under these circumstances, does it make any sense to prevent those apps to run, or it's just ignorance / superstition / you-name-it?

Please notice: under different circumstances, this might make sense. If, for instance, the web interface has less features than the app, or requires more authentications, or whatever.

This question, however, is only about situations where their features and authentications are more or less the same.

Example:

  You’ll no longer be able to use our Mobile Banking app if we think the
  device you’re using has been jailbroken or rooted.

  Jailbreaking and rooting, removes safeguards from your phone which can
  leave your device vulnerable to fraudulent attacks.

  You’ll still be able to access Mobile Banking through your mobile
  browser – visit {site} from your mobile phone and sign in.

WARNING! This is not a rant. If you are not happy with your bank's policy, just switch to a different bank, it's easy.

This is simply a genuine question, i.e. I'm wondering if there is anything I'm missing.

If you think this is a rant, it either means I didn't write well enough, or that you didn't read carefully enough, or a mixture of both. But rest assured it's not intended to be.

A rooted phone may allow the user to install services that are able to read the private data of other apps. Many online banking apps rely on app-private storage for their easy sign-on system. (i.e. 4 digit PIN or Fingerprint)

If the bank cannot rely on app-private storage, then a more thorough authentication is required (i.e. full password and possible security question), as you would normally see in the web-based interface.

Furthermore, the app may store additional cached information in the app-private storage for a better user experience, knowing that app-private storage is more secure than browser localStorage.

If app-private storage is compromised then these assumptions cannot be relied upon.

Personally, I think that this is a bit of an over-reach for the bank. It is just really annoying for the tech-savvy users who are careful about installing root-capable apps.

Perhaps some (non-tech-savvy) users (who don't understand the risk of rooted devices) will benefit. The risk of having your online banking account hijacked is quite serious.

Most of the (possible) risks of using a rooted phone (i.e. screen-scrapers and keyloggers) still apply when using the browser online version.


Databases in DMZ and Intranet In a study project i have to plan a network for a small company (around 50 employees) and i am currently at the point, where i want to design the database architecture.

I read that its common to have a web server in the DMZ. The company has got an online shop. So it is necessary to access a database. Customers can create accounts and so on via the online shop. Where to put this database? Also inside the DMZ or inside the company's intranet?

Does it make sense to build up multiple DMZs, for preventing attacks on neighbor components in the DMZ? How to mirror customer data into the companys intranet?

Thanks for explanation!

The point of a DMZ is to place any systems in there which must be reached by external systems directly but also require access to backend systems which must not be accessed directly by external systems.

A backend database used by a public-facing website is a perfect example of such a backend system which should not be placed in the DMZ but behind it.

     Customers          Internet
         |
  ====Firewall====
         |              DMZ
     Webserver
         |
  ====Firewall====
         |              Internal network
     DBserver--Employees

When you also want to isolate your database from the local LAN (to protect against internal attackers), you could set up a two-tier DMZ where an additional firewall shields backend-systems from the LAN so that only authorized employees may access them and may only access those services on the machine you want them to access.

     Customers          Internet
         |
  ====Firewall====
         |              DMZ1
     Webserver
         |
  ====Firewall====
         |              DMZ2
      DBserver
         |
  ====Firewall====
         |              Internal network
      Employees

But sometimes you don't want your employees to have any direct access the database server, even when they have personalized user accounts on it. Most database systems allow you to set user accounts with read- or write permissions to certain tables, but when you want to have fine-grained control over what data each user can and can't access, the build-in permission handling of your database might be insufficient. In that case you would have a separate application server between DBServer and employees which works as an abstraction layer between the employees client program and the database just like the webserver does for the customers. The application server might in fact be a webserver (an internal web interface).

     Customers              Internet
         |
  ========Firewall========
         |                  DMZ1
     Webserver
         |
  ========Firewall========
         |                  DMZ2
      DBserver--AppServer
                   |
  ========Firewall========
                   |        Internal network
               Employees

You might even go further and introduce a 3rd DMZ to place the internal application server in. This would protect the DBserver in the case that an employee totally compromises the application server and uses it to launch an attack which is not SQL-based against the DBserver. But that would already be a very paranoid level of security. However, there might be high-security organizations where such a level of paranoia is justified.

Which option you choose depends on the level of security you need. When you have a small team and you can trust them to not attempt any l337 h4x0r stuff on the database server, the simpler option 1 is sufficient. But when you have a very large internal network with hundreds to thousands of clients and you can not vouche for everyone to be trustworthy, you have to consider your LAN as just as dangerous as the internet and have to shield any internal-facing applications with an additional firewall and choose option 2 or 3.


How can a "server" know that what browser i'm using besides the user-agent? How can a "webserver" know (or a sniffer between the srv<->and the client) that what browser i'm using besides the user-agent?

Are there any "magic tricks"? javascript? java? How can I securely, completely hide that what webbrowser am I using?

What exactly do you mean by 'what browser I'm using' - like being able to find if you are using firefox or opera, or do you mean something else?

In any case three projects come to mind

EFF's Panopticlick (paper here): This method is not about finding out what browser are you using but more about identifying who you are among others, by correlating information about you leaking from your browser when visiting a site.
Information collected by Panopticlick includes:

The user-agent http header
the http accept header
if you have cookies enabled or not
your screen resolution (determined using javascript)
your timezone  (determined using javascript)
Browser plugins, plugin versions and MIME types (determined using javascript)
System fonts (determined using flash or java applets and javascript)
supercookies (javascript - but there are more here)

Evercookie project There are many different kinds of cookies, like flash cookies, silverlight cookies, html5 databases and DOM globalstorage. More information on the provided link.
BrowserRecon project: This is an older project, similar to panopticlick but older (and not very well known). This is aimed towards finding which browser a user is used, not identifying him among others. It uses large databases that contain observed values (fingerprints) of several http fields (like the user-agent field, the header-order field, the accept field, the keep-alive field and many more). By matching the values of all these different fields when a request comes to a server, the specific browser and it's version can be determined with a high degree of certainty.

On mitigation measures: The last technique can be defeated by using a proxy, which can potentially alter the values of many http fields and so alter the fingerprinting results.

NoScript is of great help for the other techniques, and disabling all unnecessary functionality or only enabling it on whitelisted sites.


Is it possible to connect to a proxy with an ssl (or otherwise encrypted) connection? What i want to know is whether it is possible to connect to a proxy with an ssl (or otherwise encrypted) connection? (I'm suspecting this is possible because TOR encrypts user connections to it's network.) If such a thing exists, what is it called, and is it easy to implement (say with firefox and foxyproxy)?

All i could find were questions about whether it's possible to relay (or tunnel) an ssl connection through a proxy, but i'm not looking to do that. What i want to do is have an ssl connection to a proxy (so the traffic between me and my proxy cannot be eavesdropped upon by any intermediaries). I don't neccesarily want the connection that the proxy makes to the destination url be encrypted via ssl (only when the destination url supports it).

By the way, in my case I am using foxyproxy and firefox, but the question is more about the general principle. And i am aware of TOR, but i'm not looking for that level of anonymity and TOR is too slow for my day to day surfing needs (i am thinking of only routing really sensitive traffic through tor, and day-to-day privacy-sensitive traffic through the proxy).

Support seems to vary depending on the browser. You should find the "Encrypted browser-Squid connection" section of the Squid documentation relevant. (Note that this is different from its SslBump feature.) More specifically, these links should be of interest:

http://dev.chromium.org/developers/design-documents/secure-web-proxy
https://bugzilla.mozilla.org/show_bug.cgi?id=378637

Alternatively, if the browser you're using doesn't support it, you could use something like stunnel to establish the connection to the proxy itself.


Given good security practices and an up to date system, does an antivirus add to security? I use Windows 10, do all the updates in time, browse only with Microsoft Edge and Google Chrome, and I think that I have all the common good security practices meant to avoid exposing my system to malware.

I've read that antivirus software can be exploitable, but don't know how dangerous these flaws can be in the real world, or if some are known to have been exploited by malware.

In this situation, can a third party antivirus add to security, or should I avoid them ?

Please only consider the security side, and not the potential loss of performance/pop-up annoyances/weird problems that antivirus software can cause. I'm simply trying to know which situation offers the best security.

Even if you have a perfectly secure (i.e., unexploitable) browser, you will still want to download content from the Internet and open it in other local applications, that may not be perfectly secure. An AV is useful for scanning such downloads for malicious payloads that can attack local applications manipulating the file.

So, I would say, yes you need an AV.


E-Mail attachments can be opened using their URL in webmail even after logging off My E-Mail is on Bell Net. I noticed today what I thought was a major security hole. Then I wasn't sure so I wanted to post this.

I discovered that even though I have logged off my E-Mail, I can still open attachments from my E-Mail. I viewed my browser history and I could easily open E-Mail attachments that I HAD open in a browser tab. I tried this for both images and pdfs. Then I tried this in Hotmail and this is not possible to do in Hotmail. I found that on the Bell Mail, when I logged out and cleared images from history, the image could still be viewed from the history. I had to clear Images + Cookies in order to be safe.

My concern is that in a public computer or if someone borrows your computer or you are visiting someone etc... even though you've logged out of your E-Mail, people can still view your attachments.

Is this a legit concern for my E-Mail Provider?

Use proper settings on your browser.

All attachments opened directly from your browser are cached by it, so yes, you can access them later. They did that as a feature...so they say. To prevent that, in all browsers now-days you can open your e-mail in private/no history mode and that way when you close the browser nothing is saved.

Personally, I don't open any files directly from browsers. I save them to a specific location and then I open/edit/delete them from there as needed.


Monitoring User (developer) interaction I'm looking for a "tamper proof" way, if there is such a thing, to monitor what a developer/engineer does on a given system.
To expand a bit more about this, we have several systems that run a Ruby on Rails technology stack with Ubuntu Docker containers on K8S, and for our PCI compliance, we require a monitoring solution that allows us to basically track what a developer/engineer does on a system from the point where an SSH session is established until the session is terminated.
Ideally, we'd like to see:

Loggin in
Any commands used in the SSH session
Any commands/code executed with irb or rails console
These logs send to Cloudwatch
Inability to disable this monitoring

I was originally thinking about a simple shell overwrite for the above commands to simply track every command going on, and rely on the shell history to see what has been happening, but that obviously doesn't pass the "tamper proof" requirement, as anyone with SSH access would be able to bypass that.
I'm thinking more about some OS level monitoring to either watch the processes directly we know that will be used for working with the PCI sensitive information, or just monitor all tty trafic/interaction.
What I'm looking for is best-practises, reading material or recommendations on what's the accepted/recommended way for setting up a system like this.

Tamper proof monitoring may be used as a compensating control to meet requirement 6.4.2 in respect of separation of duties between Dev/Test/Prod environments. Remember that DSS was written pre-DevOps :-)
Typically the way most entities do this type of monitoring is via a jump host, so the dev connects to the jump host and from the jump host then connects to the Prod environment. The jump host records the screen and all keystrokes. The dev's rights on the jump host can be very restricted. I don't know of any FOSS systems that do this but look at commercial Privileged Access Management (PAM) systems.
NB: Whether a compensating control is sufficient for your environment is a discussion between you, your QSA and sometimes your acquiring bank.


What does "fd" stand for in the context of public key infrastructure? I'm reading the OpenSSL Cookbook. Early in Chapter 1 on page 9, the author generates a private key using the RSA algorithm:

openssl genrsa -aes128 -out fd.key 2048

I understand that the key could be named anything, for example foo.key. I also understand the extension could be anything.

In the case of the extension, it makes sense to use .key because it's one of the accepted Privacy-enhanced Electronic Mail format extensions. Others could be common [accepted PEM extensions] are .pem, .crt, and .cer.

Why does the author choose fd? Is it short for something?

As @CodesInChaos stated;

If you read the complete chapter, you see that the author is setting up a cert for Feisty Duck Ltd, CN=www.feistyduck.com, it's just the name for that.

As you said also, I understand that the key could be named anything; so the "fd" stands for nothing here, in terms of context in PKI.


Personal Data Encryption Workflow By personal, I mean for one person that's not sharing the workflow of data access with any other users.
Appears based on the feedback I got on "is-hardware-based-disk-encryption-more-secure-that-software-based" that it might be more secure, but due to a lack of disclosure on the hardware implementation makers part, it's impossible to know, and as a result, appears to be meaningless.
As a result, I want to know the best practices for implementing and managing a personal data encryption workflow, and a briefing on the core concepts that are related to the workflow. This workflow assumes local access only, there is no need to make it more complex, and less secure by allowing or accounting for remote access unless it's as a counter-measure to prevent remote access.
Workflow should include backups of data at offsite, where the offsite store is assumed to be hostile and insecure.
The best answer will suggest a real implementation, not just a theoretical workflow, which is to stay it will present a implementation that is executable.
While I believe it would make the answer more useful if the answer worked on Windows, Mac, Linux, etc -- since this would cover the needs of most users, I'm open to a solution on any platform.

There have been a lot of recommendations here for encrypting specific files but nothing really about full disk encryption. If you do not use full disk encryption, your data is vulnerable if the attacker has access to your machine. Most programs you would use to interact with the data (including the OS) will create temporary files, etc that will leave bits and pieces of your data in unencrypted areas of the hard drive where it can be recovered by an attacker. If you at all think that an attacker might have physical access to your machine, you must use full disk encryption. The easiest way to do this is to use TrueCrypt on Windows. Ubuntu Linux will let you do full disk encryption if you use the alternate installer. This tutorial isn't for the latest version of Ubuntu, but it is more than enough to get you started.

Backing up to a remote location makes things tricky. You absolutely must encrypt all data before it ever touches the network or a third party service. Sites like Carbonite, Backblaze, Dropbox, etc. offer encryption but still maintain a copy of your keys so that you can restore your data from a web interface and cannot be trusted to fully secure your data. I would recommend storing all of your data in a encrypted volume (again Truecrypt is a good option for doing this) and then backing up the entire volume at once.

To summarize, the workflow would look like this:

Fully encrypt your computer using Truecrypt(Windows) or LVM(Linux)
On your now fully encrypted computer, create a local encrypted volume using Truecrypt to store data that needs to be backed up .
Do Work
Unmount/Close the encrypted volume so that keys are no longer in memory, and then push the fully encrypted local volume to a remote site.
Shut off your machine when you are done. Do not use suspend as it will leave encryption keys resident in memory.

If you are exceptionally paranoid, the computer you do work on shouldn't have access to the internet. To back up the data you would want to burn the encrypted local volume to a CD, move it to another secured computer with internet access, and then back it up from there.

Also, all of the steps above assume that you use good, strong passwords/passphrases for all encryption. They should all be different and all contain letters (capital and lowercase), numbers, and symbols to make them difficult to guess.


Any benefit to proof-of-work to avoid database lookups? I thought I was being clever - overly engineering a (just for my learning) mobile app that is scaled out using only distributed technologies (AWS Lambda, S3, and Dynamo DB in this case).  I want to allow apps to register themselves in the database, but I'm trying to limit the database queries and writes that I need to perform in case someone tries to make my costs very high by spamming me with database activity.  I experimented with a proof-of-work scheme where an api/service call handler generates a signed assignment (all in memory, no database) that the mobile app then has to perform which is later verified by another api call before writing the new registration to the database.  Fine, I'll do the work, but they have to do more work which isn't much of a burden for the cooperating client, but which might be a deterrent for a malicious client.

But then I realized that without tracking the submissions, the malicious client can do the work for real the once, but then just spam me for the remainder of the assignment validity window (before it expires) and still require my database lookups.  The window before expiration would have to be at least the worst case of my worst-performing supported client hardware which would leave plenty of time for trouble.

Further, because my database is merely eventually consistent, I don't know how to avoid double-issued requests to isolated replication nodes in any case.

There's no shared state or even host affinity between the event-driven lambda api processing.  Dynamo DB is (I think) only eventually consistent.  MemCache or Redis (offered by ElastiCache).

These are relevant:

http://people.cs.pitt.edu/~mehmud/docs/abliz09tourpuzzle.pdf
http://www.cypherspace.org/hashcash/hashcash.ps
http://jorgenmodin.net/index_html/proof-of-work-to-prevent-dos-and-ddos-attacks-of-web-pages

Is there any benefit at all to adding a proof-of-work?  Or is any additional complexity merely deferring 100% of the problem that is unavoidable (while also introducing new points of failure)?

Are there any anonymous registration schemes that are compatible with eventual consistency and requiring more of the registrant than the registry?

You are asking several very different questions.

  I'm trying to limit the database queries and writes that I need to perform in case someone tries to make my costs very high

You should have a gateway (e.g. Amazon Lambda) that supports rate limiting. With this toy in your hands you'd be able to configure number of allowed requests. There are generic gateways available if standard stuff is not suitable or available, e.g. Umbrella.

  ... how to avoid double-issued requests to isolated replication nodes

You do this by configuring write quorum. More nodes in the quorum - better consistency but slower write speed (this is known as CAP theorem).

  There's no shared state ...

This is by design, shared state is a performance killer especially in distributed environments.


Need help detecting a flaw or vulnerability in a network Let's assume that my public IP address is A.B.C.D and I have a Linux server within my network that has the IP X.Y.Z.T and I have some port open in the X.Y.Z.T server but that same port is closed in my main router so that A.B.C.D:PORT can not be reached from an outside network.

The thing is that I have been attacked by someone that exploited my resource at X.Y.Z.T:PORT by accessing it through (according to my server's logs) A.B.C.D:PORT

Logically A.B.C.D:PORT cold not be accessed from outside my network since the port is closed and the attacker's IP has no NAT address inside my network. So my question is how can something like this happen ?

Please understand that I don't expect a full answer to that, I just need some clues where to start looking (I'm a complete beginner in networks).

Simple answer:
Start sniffing your network and discover what is happening. After this work with what you'd seen.

Sources, destinations, packets entering, packets leaving and possibly their content. It's all there if you can catch.

Sniffing your network and understanding how this connection is being stablished without suppositions is the key to solve your problem, so you can start working on what's really happening.

Discover how it's leaving your network and drop it.


Security implications of "local admin on host OS" vs "local admin on virtual guest OS" At work we have a discussion on computer security.

The scenario:

Our work PCs are Windows desktops that are part of a windows domain
Users have domain accounts they use to log in to windows
The user's domain accounts do NOT have local admin access
Our organization has a group of developers
The developers would very much like to have local admin access to their computers (our experience is that developing on Windows with Visual Studio without local admin is a hassle)
But the IT department does not want to give any users any sort of local admin access to the computers (not even create local users)
Instead, the developers are allowed to install virtualbox and install whatever they want in virtual machines.

The issue/question:

I argue that the security implications of having guest VMs running with local admin, is on roughly the same level as running the host OS with local admin.
My reasoning is that if for instance a guest OS was infected by a virus, the potential implications would be on par with the host OS being infected.
After all, the guest OS can access the same network resources (on the IP level) that the host OS can (possibly dependent on the VM software config), and therefore the surrounding network infrastructure is exposed to the virus no matter if the virus is running on the host OS or the guest OS.

Am I right? Am I wrong? Does any one have pointers to good articles/discussions on the subject?

From the security perspective , the current setup is better , i.e running virtual machines on host , instead of giving developers local admin rights , because it is not just about the virus problems that they are not given local admin access. There are other security implications to that. Installing virus is just one aspect of that.


Is my ISP hacking me? Today I was trying to enter my routers admin page. I put the default IP address starting with 192.168. I couldn't login so ran ipconfig, and I discovered that I was assigned a Class A address. I was confused because I didn't change my IP so i typed that A class IP which starts with 10.100 a file downloaded and installed in my computer. I ran network map in Windows 7 and I found a computer not in my network taking the routers name.

Is my ISP hacking me?
Thank You

It is highly unlikely that your ISP would hack you, since they can easily (and without a trace) watch all your data go by on the wire.

However, since you said there is a strange computer connected to your network, that sounds like an intruder on your network, perhaps trying to perform a MiTM attack.

You should reset your router to factory settings, use a strong (24 character, randomly generated with special characters) password, disable WEP and WPS, use WPA-2, disable remote access to router panel, and force it to be on a wired connection to access admin area.


How to easily remember lots of different passwords? I know that you shouldn’t use the same password on every site. But, when you log into several dozen sites, keeping track of all the passwords can be pretty hard.

What system do you recommend that won’t compromise all my accounts when one site gets hacked (assume the worst case — site storing passwords in clear text)?

I am looking for a system that helps me remember the passwords, not a way to store them.

To remember passwords, type them often. You can remember dozens of passwords if you type them daily -- that's muscle memory, the same kind which is used by martial arts practitioners, so remembering many passwords is like being a Kung fu master (albeit in a slightly less awesome way).

Bruce Schneier, well-known Chuck Norris imitator, recommends writing down your passwords and keeping them in your wallet. This makes sense because you are both trained and highly motivated at maintaining a high level of physical security on your wallet. I would double that with a copy of the same password sheet somewhere in your safe, so that you could recover from a wallet theft (i.e. logging again in all the sites and change your password). Also, a piece of paper has no battery which needs recharging.

(Caution: your smartphone is not a good wallet. Physical security on your phone is much lower than the one you apply on your wallet. Unless you are in the habit of flourishing your wallet at arm's length while walking in the street.)