Screenshots and steganography, can malicious code in image be copied?

That depends entirely on the kinds of steganography used
For example, you could modify the least significant bit of every pixel to store data in it. This has a visible, although barely noticable effect on the image. It requires the file to be transmitted as is, as even slight changes in the colour values of the image will destory the associated information.
If you make a screenshot and that screenshot is a perfect, pixed-by-pixel replica of the original image, that screenshot will also contain that information, although it will be much more difficult to extract, since it will also contain a lot of irrelevant data.
It's also possible that the program you use to make that screenshot compresses the data in a lossy format. As such, if you have a large white background - as you do on a document, for example - tiny variations in color - as you would have when hiding information via the LSB method - would be "smoothed" over and stored as one blob of colour, thus effectively destroying the information.
Other methods of steganography rely on the way a file is structured to hide the information. As such, methods that copy the visual information will not copy the hidden information.
Summary
Is it possible? Yes. Always? No.


How does detecting promiscuous mode using an ARP test work?

It is at first a little counterintuitive, as the Ethernet address is a 'fake' broadcast address, but the test itself is not a broadcast test. It is targeted at only the destination IP address. You would need to target each individual IP on your subnet, ie do a scan.

However note that it is relatively easy to not be detectable, by using a Lan Tap. It effectively connects the sniffer in parallel to another device but has the Transmit wire disconnected (ie it is not possible for monitoring device to respond to anything).

For further reading: http://www.securityfriday.com/promiscuous_detection_01.pdf


Is it safe to publish file paths on a server publicly?

If your server is otherwise secure then its simply not recommended to do so, but poses no immediate threats.

However, if your hosting a web server there are extra risks involved such as SSI (server side includes) which will allow individuals to access those paths. You may want to double check your server user permissions and vulnerabilities first.

Its rarely necessary to use absolute paths and is just an extra risk. Your just laying our breadcrumbs for someone with malicious intent ;)


Cryptographic hash functions must have several properties:

Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x.
Resistance to second-preimages: given m, it should be infeasible to find m' such that h(m) = h(m').
Resistance to collisions: it should be infeasible to find m and m' such that m ≠ m' and h(m) = h(m').

These properties are not equivalent to each other, and you do not necessarily need all of them. It depends on the protocol in which you are using the hash function. For instance, hash functions are used at the initial step of digital signatures, for which collisions are not a problem -- unless the attacker is in position to choose an exact message to be signed. Details can be subtle.

If the hash function has an output of n bits, then there exist generic attacks which find preimages, second-preimages and collisions with cost, repsectively, 2n, 2n and 2n/2. A "generic" attack means that it works for all hash functions, regardless of how perfect they may be. This sets the maximum achievable security level.

If you "compress" SHA-256 output to 128 bits (whatever compression procedure you may want to use, even a simple truncation), then you are actually defining a new hash function with a 128-bit output. As such, the resistance to preimages and second-preimages of that function will be at best 2128, and resistance to collisions will be at best 264. Therefore, your truncated SHA-256 will offer "128-bit security" only in usage contexts where collisions are not an issue. But since it can be quite hard to ascertain that collisions are indeed not a problem, "compressing" hash function output is not recommended.

In general, we prefer to be safe than sorry; thus, when we want "128-bit security" we use a 256-bit hash function. That way, we don't have to worry about whether collisions could be leveraged into an actual attack or not. SHA-256 collisions are not feasible with existing technology.


What are all of the issues with storing a cleartext password?

I know this does not directly answer your question, but another approach would be to have the application authenticate itself to the service to set up a trusted channel between the two.  The app could then just pass identity assertions on behalf of the user, and no per-user passwords would be needed.

The assumption here is that the service is happy to trust the application.


Email sender spoofing check from receiver

Message authentication methods such as SPF, DKIM, and DMARC can be used by a message recipient to determine whether the domain of the apparent sender may have been spoofed.  These standards are based on information published in the DNS for the sender’s domain.
In the case of SPF, an SPF record is published in the DNS for a domain to specify the SMTP servers that are authorized to send mail from senders in that domain.  If a spoofer tries to send a message appearing to be from *@paypal.com, he is unlikely to be able to relay the message through one of the SMTP servers designated in the SPF record for paypal.com.  If he tries to send the message through a SMTP server other than one that is designated in the SPF record for paypal.com, the recipient’s spam filter would likely detect this mismatch and determine that there is a high likelihood that this message was spoofed.  As pointed out in the comments by @SteffenUllrich, the shortcoming of SPF is that it only applies to the domain of the sender address in the MAIL FROM of the message envelope, which is generally not seen by the recipient.  However, DMARC can be used in conjunction with SPF to apply to the sender address in the message headers as well.
In the case of DKIM, a DKIM record containing a public key is published in the DNS of the domain.  A signature over a hash derived from the message body and headers is created using the private key corresponding to that public key, and this signature is included in the headers of the message.  If a spoofer attempts to send a message appearing to be from *@paypal.com, he would not have the private key, and therefore would not be able to create a valid signature.  Therefore, if the recipient’s spam filter is able to verify the signature using the DKIM public key published in the DNS of the purported sender’s domain, then it’s unlikely that the message was spoofed.
As pointed out by @SteffenUllrich, all of the above frameworks validate the sender’s domain, but not the particular sender.  In addition to (or instead of) these frameworks, the sender can sign the message using an S/MIME or PGP/GPG signature. If the recipient has the sender's public signing key, then the recipient can use the public key to verify the signature. If the signature verifies, then this proves that the sender (or someone else that has the sender's private key) signed the message.


The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that respect, PUT and GET mimic the expected behaviour of FTP.

On the other hand, a "POST" is the generic verb for API-like calls: orders sent to a server for immediate execution. Such API calls are not idempotent. A "change password" call should probably be envisioned as an API call, not a file transfer. Therefore, you should use POST instead of PUT.

See for instance this blog post for further discussion about PUT vs POST.

From a security point of view, there is no real difference between PUT and POST: everything goes through the SSL, and it is mostly a matter of convention between client and server. As long as the client and server understand each other, then the security offered by both requests is the same.

The theoretical difference is that a client might take upon itself to issue a PUT call again in case of network failure, while it would not for a POST. Generally, you prefer the POST semantics, and keep PUT only for bulk file transfer where such reemission would be a nice feature, and not a problem.


Adding any network equipment in your network architecture is bound to slow down the traffic by at least a small portion. Each device processes the data, at least to put them from one cable to the other.

Using multiple routers (security wise) is interesting when you start having multiple machines and want to isolate clusters of them from each other (e.g. when you have two department in a company). As a individual user, it does not helps in any sense, unless one router can provide a service the other can't.


What's this kind of authentication scheme called?

Displaying a hash of nick and password to identify users is known as Tripcode.

There are different variants of this, sometimes the website operator adds a secret key, sometimes an expensive hash like PBKDF2 or bcrypt is used, sometimes the password is replaced by public key.


How do key pairs work especially in the context of cryptographic signatures?

As long as matching sets of keys (i.e. the infamous key pair) are used you can use either one to encrypt and the opposite one to decrypt.

No, because encryption with a private key and signing with a public key is neither defined nor secure for RSA. For schemes like ECDSA you cannot even directly encrypt.

  And in the case of RSA I know how that sequence happens.

Really? I would say that it is up to the protocol to define how "the sequence" happens. There are discussions about sign-then-encrypt and encrypt-then-sign too.

  What seems implied is that the message digest which is encrypted with the sender's private key is then decrypted with the sender's public key ...

No, you should not think of signature verification as decryption, not even for RSA. In RSA, there are different padding schemes. Only "textbook RSA" is similar - in other words, both rely on modular exponentiation.

  So it seems that messages encrypted with a user's private key could be decrypted with their public key.

Well, yes, but only for textbook RSA, which is completely insecure.

In general, you should never use the private key to encrypt. Encryption is to keep information confidential, if anyone can decrypt with the public key, then the scheme doesn't make any sense.


Let me give you an example of a hypothetical yet very plausible scenario.

There is an aspiring hacker named Bob. One fine sunny morning, Bob found an SQL injection flaw in a popular social networking site named HandBook. Using said SQL injection flaw, Bob managed to dump the a list of email addresses and passwords of accounts registered with HandBook. Given that HandBook has a shitty security team, all the passwords are hashed unsalted with MD5. Cracking open his trusty rainbow table, Bob manages to recover the plaintext passwords of 86% of the user accounts.

What does Bob do next? Bob knows that 86% of the people on HandBook are teenagers. What do teenagers love more than one social networking site? Two social networking sites of course! Bob decides to try out all the email address and passwords combinations he managed to crack against the authentication service of a second popular social networking site, Chatter. Given that teenagers are teenagers, they do not have strong password policies. Bob manages to access 76% of the user accounts simply by trying the same password or a close variant. He was able to accomplish this very quickly since Chatter's login form kindly notified him when he was trying to login with a non-existent email address.

Is this a flaw? Yes, potentially. I mentioned this in another one of my answers. It has been pointed out that this might not be a major issue if the usernames of registered accounts can be enumerated in another fashion, for example through the registration page. However, many registration pages are protected with CAPTCHA, which makes automated attempts against it that much harder.


Is it easy to protect against SSI injection?

It's not a terribly difficult attack to prevent.  I would say prevention has more to do with the developer being security aware than it does with the complexity of preventing it.  This is actually true of many security vulnerabilities.

To answer your question - no, I don't think you are missing anything.  It's just a matter of making sure developers are thinking about security when they implement functionality that uses SSI.


It does not take much effort to block P2P etc with current routers and restrict access as this detailed article from 2011 (Lifehacker) shows.

But unless you restrict access a lot and thus make users unhappy they will still be able to upload copyrighted content to youtube, make bomb threats etc. If you don't want to deal with these liability issues (which also differ between countries) you better let  a commercial hotspot provider deal with it. These providers usually create a separated network for the guests and route the traffic over their own infrastructure. This way they appear as the source of the traffic and not you and thus they also handle all the liability problems. Of course this shift of responsibility has a price which either you or your customers must pay.


To a large extent, yes, you will lose your anonymity.  Github (and anyone monitoring Github) will be able to connect your email address to your IP address.

A key element of anonymity (or more technically, pseudonymity) is keeping your separate identities separate.  Your Hushmail account accessed over Tor is one identity, while everything you do through direct Internet connections constitutes a second identity.  By using your Hushmail account for a direct-connection service, you've tied those two identities together.


The difference between Management and Configuration Policies

Are you asking specifically about password management and configuration?

Management is outward facing and influences user behaviour such as 'password length' or 'frequency of password change' and typically relies on governance and policy; whereas
Configuration is inward facing and influences service behaviour such as 'where passwords are kept' (such as LDAP, or flat text files) or 'what authentication service is used to authenticate' and typically relies on technical requirements and administrative choice.


Does RAND_add(&Time,sizeof(Time),0) at each ssl connect reduce randomness or not?

Mixing in easily guessable information never reduces entropy. In fact, that's the whole point of mixing: you can add information of dubious unpredictability, and all the unpredictability from uncorrelated sources adds up. So the mixture still has better entropy than before, or at worst just as much (if the new input is completely predictable).

To put it another way, the entropy of a RNG is the logarithm of the probability for an adversary to guess the sequence of random number (which for a PRNG is equivalent to guessing the (relevant portion of the) internal state). If the adversary can guess some of the input, that lets him establish a correlation between the state before adding that input and the state after. But that doesn't make the state after easier to guess than the state before.

All this assumes that the method for mixing entropy is a good one. This step is very easy to get wrong. As far as I know, ssleay_rand_add does it right.

Schneier's concern is not that there is a partially-predictable input, but that all the inputs are partially-predictable, to the point that the resulting generator state hasn't accumulated enough unpredictability. The problem isn't that unpredictability (entropy) goes down — it doesn't — but that it starts from 0 and may not have risen enough.


The generic issue with such countermeasures is that they defeat only some keyloggers, and are themselves defeated by the next generation of keyloggers. In this case, it would be easy for a keylogger to take into account the backspace events (the keylogger sees all keyboard events, so in it sees backspaces) to rebuild the actual password. In fact existing key loggers should already do that, because human users use the backspace key occasionally, too !

Another generic issue with an anti-keylogger software is that it is software. A software keylogger, in order to enact its malevolent functionality, must intercept keypress events, and this requires privileged access to the operating system, at least administrator-level. An evil piece of code which obtains such access will not necessarily stop there; it may also scan for the launch of known anti-keylogger software and deactivate it. Malware and virus do that in general, against anti-malware and anti-virus software.

An additional reason why a keylogger would block out your envisioned anti-keylogger software is that keylogger writers generally dislike competition -- if they find other keyloggers from their fellow keylogger writers, they promptly kick them out. Your anti-keylogger software, from the outside, really looks like a keylogger, since it intercepts keypress events; it is then likely to be deactivated by another keylogger which just wants the monopoly of key logging.

Therefore, if software such as you describe exists at all, then it cannot be considered as reliable. It might enjoy some partial success against a few keyloggers, but this won't last.


HIDS - Choosing between regular OSSEC or Wazuh fork

Regarding Wazuh differences with OSSEC, the Wazuh team is working on updating the documentation to explain those better (and on a new release and installers).

Wazuh new version (2.0, currently found under the master branch) highlights are:

OpenSCAP integrated as part of the agent, allowing users to run OVAL
checks.
New WUI on top of Kibana 5, and integrated with the RESTful
API to monitor configuration of the manager, rules and status of the
agents.
Improved log analysis and FIM capabilities.
Ruleset with compliance mapping.
Agent-manager communications over TCP supported.
A modules manager that will allow future integration of other tools
(in the roadmap is OSquery and Threat Intelligence sources)

Complete changelog can be found here:

https://github.com/wazuh/wazuh/blob/master/CHANGELOG.md

If you are curious, here are some screenshots of the WUI.

https://github.com/wazuh/wazuh-documentation/tree/2.0/source/images/screenshots

As well it is worth mentioning that Wazuh project, as a fork, is based on the work done by OSSEC developers and contributors to which we are thankful. Wazuh plans to continue contributing to OSSEC Github repository with bug fixes, but we also have our own roadmap so, most likely, both projects will evolve in different ways.


How to block all access to Akami deploy servers and Apple push servers?

Use LittleSnitch to restrict what services applications can access, without having to manually list the thousands of servers owned by each of these CDNs. As a bonus, you can specify the rules by application, allowing for a much greater degree of control over who uses what.


Disabling IPV6 firewall with IPV6 disabled

If the device cannot speak IPv6, then it is very unlikely that having an IPv6 firewall enabled would offer any protection.


Why does rfc6797 say "An HSTS Host MUST NOT include the STS header field in HTTP responses over non-secure transport."

This client behavior is prohibited by section 8.1 of the RFC:

If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).

The spec prohibits severs from sending insecure HSTS directives and clients from processing insecure HSTS directives. This ensures that a faulty implementation in either a server or client is not sufficient to undermine HSTS; the failure must be present in both for the weakness to be present.

As noted in your question, HSTS over plain HTTP sounds like a great way for an attacker to implement long-term client-enforced denial of service on a service offered over HTTP. In fact, section 14.3 of RFC 6797 addresses this specifically (as well as an even more serious concern):

The rationale behind this [requirement that HSTS be served over secure connections only] is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability")); for example:

Unauthorized notation of the host as a Known HSTS Host, potentially leading to a denial-of-service situation if the host does not uniformly offer its services over secure transport (see also Section 14.5 ("Denial of Service")).

Resetting the time to live for the host's designation as a Known HSTS Host by manipulating the max-age header field parameter value that is returned to the UA.  If max-age is returned as zero, this will cause the host to cease being regarded as a Known HSTS Host by the UA, leading to either insecure connections to the host or possibly denial of service if the host delivers its services only over secure transport.

Since HTTP can be easily spoofed, an attacker could specify an HSTS directive to treat an HTTP-only site as an HTTPS site: the client would then demand HTTPS and the server would be unable to supply it.
More seriously, this section of the RFC indicates that an attacker who can issue HSTS directives for a host could strip the host's status as a Known HSTS Host, thereby dangerously allowing the client to issue plain HTTP requests to the host.


Locate rogue wireless access point using Kismet data

Sure this is possible.  There's a couple of ways to approach it.

The easiest way is to run kismet then as you're running it look for your Rogue access point appearing on the list of access points seen.  When it does, lock the channel that kismet is looking on to the channel being used by your rogue access point (this gives a clearer signal than if kismet is hopping over a number of channels)

Then look at the signal strength being shown and wander around the area until you get the strongest signal you can. At that point I generally find that the AP is within 10-15 feet and just looking around the area will spot it (unless someone has deliberately hidden it from you)

Another option is to use directional antennas and triangulation to try to locate the AP, but I'd suggest that in the first instance you just go based on signal strength.

If you have other tools available besides kismet, I'd actually recommend airodump-ng for locating access points as from an interface point of view it can be easier to look at the signal strength on that as you're walking around.

Also if the AP is not cloaked you can used Android tools like "wifi Analyzer" which work pretty well for this kind of thing and which can be easier to carry around.


Is this use of PBKDF2 for generating passwords secure?

This kind of solution has been proposed and deployed many times. It kinda works, but it has a some drawbacks:

If two people use the same mechanism for the same target site, then both their passwords use the same 'salt' (the server name), which is not ideal. Conceptually, you want per-site passwords so that poor security on one site does not impact your security on other sites, so you somehow assume that some of your passwords will be recovered by attackers. If 10 users use your system on the same site, and that site gets hacked, and the attacker gets all 10 passwords, then he will be able to make a parallel attack on all 10 master passwords because the 10 PBKDF2 instances will use the same salt.

To a large extent, this issue can be fixed by using as salt the concatenation of the target site name, and your name (e.g. your email address, which is unique worldwide). Note that the salt does not need to be secret or random; what it needs is to be unique.
You only get one password for a given site. If the site wants to enforce a password change, and the new password must be different from the old one, then the system ceases to be applicable.
Many sites try to enforce "password rules" (minimum length, maximum length, presence or absence of some types of characters...). Most of these rules are remnants of traditional rituals with very little scientific justification, but they still exist. The problem is that all these rules are contradictory: there is no generation method that will produce passwords that will comply with all the sets of rules that various sites employ.

The bottom-line is that while a hash-based password generation method works, you will need to handle exceptions.

If you have a trusted Web server accessible through SSL/TLS, then maybe you could simply store your passwords there ? Possibly with some local encryption, relative to the master password that you type and send to your Web server.


Allow user to export data, what about security?

The first questions to ask here are IMHO:

who is the owner of the data?
what is the responsability of each part?

For the first question the answer is the client not you. So if they want to publish their data on their facebook page, it is their problem, not yours. And as the owner of the data, they must be able to get it from you at any time, because they must be able to stop working with you and make business with someone else (not nice, but they can).

Your reponsability is to secure the data when it is holded by your application, and on the way between the client and the application. So you must make sure that you address the risks and threats that the client consideres important. In your example, choosing a big cloud platform is certainly a good choice for Availability, but did you considere Confidentiality? Can you say how many admins will be able to access the client data, and do you know whether it matters for your client? You say that you will do your best efforts to secure the application, but have you considered a third party security audit, depending on how much the client sees the security as important.

As an IT professionnal, you must also give advices to the client for all the processes where you are involved. Have you specified with the client the access levels if different persons can access the data, and the risks associated with each level? As you speak of poor passwords, have you spent some time to explain the importance of good passwords and have you proposed to pass automatic guess tools (John the Ripper for example) to control the weakness of passwords? If it matters, can you application log who retrieved what to later analyze the causes of a data leak?

IMHO, that is what you should feel concerned with, not what the client wants to do with their own data, beyond giving advices to them.


Host filesystem manipulation from docker vs. virtual machine

It's perfectly possible, with virtualization systems, to expose the underlying host OS filesystem (assuming here we're talking about Hypervisors running on a general purpose OS and not a "bare metal" setup), how that's done depends on the hypervisor in question.
That said container systems, like Docker, are more likely to have issues with this as, whilst most VMs can operate perfectly happily with just the resources available in the guest, containers will often mount host directories in to provide persistent storage.
Where that gets somewhat more dangerous, in many container setups, is that contained processes often run as the root user, which is the same UID as root on the host (assuming user namespacing isn't enabled).
In that configuration, if a sensitive host path is mapped inside the container, it would be easy for an attacker who has gained access to the container to modify the files on the host.


This code allows an attacker who knows the victim's X-Forwarded-For: header and the victim's session ID to login as that user.  If the victim doesn't have an X-Forwarded-For: header, the attacker can put the victim's IP address in his header and the code will use that value as his legitimate IP address instead of his actual IP address.  This is the vulnerability.

In a network-sniffing scenario, the attacker gets both of these values at the same time, hence adding this code does not protect against network sniffing.
In an XSS scenario, where the attacker injects javascript to steal the user's cookie, this is usually done by causing the victim's browser to make a request to an attacker-controlled web server with the cookie value appended as a GET parameter.  The X-Forwarded-For: header of the victim would be supplied to the attacker in that request.

I haven't yet been able to think of any scenario where an attacker could obtain a victim's cookie but not be able to obtain the value of a legitimate X-Forwarded-For: header or, if no header was present, the victim's IP address.

So the answer is yes, as written, this code does nothing to improve security.  It should trust the directly connected IP address only.

Note: If your web application server is behind a reverse web proxy (such as nginx, Varnish, HAProxy, mod_proxy, Amazon ELB and many others) that always adds the connecting IP address to an X-Forwarded-For header and makes a new connection to your web application server with its own IP address, you can "trust" part of the value of this header.

Modules such as mod_rpaf or mod_remoteip for Apache can be configured with a list of trusted proxy IP addresses and will replace the value of REMOTE_ADDR with the trusted part of the X-Forwarded-For header for connections coming from those addresses.  This REMOTE_ADDR will be available in PHP as $_SERVER['REMOTE_ADDR] and will be logged in your Apache log files as the true connecting IP address.

If you don't do this (or the equivalent if you are not using Apache) then you will only ever see connections from one IP address, your reverse proxy server, and therefore all your sessions will contain the same IP address.


If you're servers do not store, process or transmit cardholder data in any capacity at any time, your systems are not in scope for PCI compliance and you've effectively outsourced the handling of such data to authorize.net - this means PCI is simplified as you've a reduced scope and would complete a less onerous Self Assessment Questionnaire (SAQ). As a merchant you need to be compliant rather than your site needing to be compliant. How you handle cardholder data dictates which SAQ you complete - if you've outsourced the cardholder data handling, you'd complete SAQ A which is pretty simple!

Visa and MasterCard have guidelines on how web applications should be secured when the transaction handling has been outsourced such as using hosted payment pages. The worry is that the application could be manipulated and cardholder data transmission redirected (or copied) to a third party.

Requirements include secure development lifecycle, vulnerability scanning, logging and file integrity monitoring.

You should consider storing the transaction key separate to the application itself such as encrypted within the database or in a separate file store with strong access controls.


security performance criteria in employee reviews

I'd like to respectfully offer a different perspective from the perfectly valid answer and comments already here.

I'm reading between the lines a lot, but I believe the original question is trying to achieve quite a good (and difficult) thing - prioritize security awareness at departmental level, with objective measurements of awareness.

The effect being that various managers are kept aware of how good direct reports are with regards to IT security, and there are hard numbers to refer to, not individual incidents. It's not just left as another thing for HR to deal with - you're treating it as training, instead of discipline.

I feel that IT Security is so nuanced that individual managers are better suited to evaluate their direct reports than HR is.

Phishing is much more of a threat to senior managers or financial controllers. It's important that they are "phishing-resilient" because their accounts have access to business critical systems. I'm not fussed if the maintenance crew score poorly against phishing - their accounts are likely to have very few privileges. In contrast, the maintenance crew has to be great at physical security, because they have access to the entire building (which may include switch cabinets, cable runs, etc.)

The metrics part is great because it's better to have numbers from a careful study instead of single-case incidents. But this is the hard part.

To do this you would need a well-designed framework for constant and systematic evaluation of each staff member, AND a "red team" that constantly tries to tailgate into buildings, leaves "malicious" USB drives in employee parking lots, phish employees, email nude-pics.jpg.exe to staff, etc. At the end of the day, you could then indeed construct great objective measurements:

"Resistance to phishing attack": Received 24 test phishing emails, visited the phish page 2 times, entered credentials 0 times,
"Safe treatment of unknown USB Drives": Returned 2 out of 2 "lost" USB drives to the IT Helpdesk.

Excellent, but very resource intensive. You could then gamify the system to increase response by comparing ratings between departments, improvements over time, awards for perfect scores, etc.

If you planned on deriving metrics from non-training, real-world incidents, I would agree that those are much less useful for staff training and awareness.


Windows event log - Security - Audit failure

Logon Type:         2

2 means it is Interactive (logon at keyboard and screen of system)

  Security ID:        NULL SID

Subject is usually Null or one of the Service principals, though not that useful.

  Logon Process:      CredPro

CredPro indicates a logon initiated by User Account Control

With these, you can determine that someone is in fact trying to log on. At regular intervals, could be a script (maybe, at that lenght they are trying to make it seem like it's another admin or something, compared to trying to log on every 30 minutes).

See this from MSFT of what looks like a similar issue.

Also if you are watching Event Viewer, I'd also suggest centralizing the Event Logs maybe to another dashboard (useful if the account becomes compromised). See these types of modules here (I'm involved in the project) and also others that can collect EventLog events into another format like JSON.


The problem is that this only helps if one particular account is attacked. But instead of trying 100 passwords on one account, an attacker might also try one common password on 100 accounts. To prevent this, you also have to monitor the total number of failed logins and start displaying CAPTCHAs when the number gets exceptionally high.

For user-friendliness, the failed logins should expire automatically after a while. It doesn't make sense to keep the counter for more than, say, 24 hours.

Last but not least, be careful with race conditions when you actually implement this. Many people first check the number of failed logins and then increment the counter if needed. But this allows an attacker to send an arbitrary number of concurrent requests between the check and the increment, and each time the server will still “see” the old counter. You need a single query where you increment the counter and get the new value at the same time, and then you have to check that value. Different database systems have different techniques for this. In PostgreSQL, you can use an UPDATE query with a RETURNING clause. In MySQL, you can use an UPDATE query with the increment expression wrapped in LAST_INSERT_ID() and then get the incremented value with SELECT LAST_INSERT_ID(). Note that you can't just make a plain SELECT query after the update, because the counter might already have increased in the meantime.


FREAK attack - why doesn't Finished message prevent it?

The idea of the FREAK attack is that the attacker has already factored the RSA key -- because the server uses the same RSA key pair ever and ever (generating a new RSA key pair is somewhat expensive so the server won't do that for each connection). Since the attacker, at that point, knows the RSA private key, he can hijack the connection and "fix" the Finished messages.


In general there are valid URL schemes that are dangerous. Most obviously javascript:, which as a pseudo-URL refers not to a new location, but to a command to execute on the current page. Allowing a javascript: URL to be added to your page means you have a cross-site scripting problem.

There are also other scripting aliases (vbscript:, mocha: et al), as well as data: and any number of arbitrary protocol handlers that third-party software might have installed at the client. So typically you need to whitelist URL schemes.

Django's default URLValidator for URLField does this, allowing only http, https, ftp and ftps links, so as long as you haven't replaced the validators it should be OK. (You may wish to do so, if that's not the set of schemes you want.) If you have any other means to populate the some_url field that doesn't go through the normal field/validator then you'll need to make sure that is validated too.

  (What comes to mind is including a quote in the URL and then arbitrary HTML.)

As long as you haven't disabled autoescape, the default HTML-escaping provided by {{...}} templating prevents that (it correctly encodes single quotes to &#39;).


Can the contents of a web page be protected from modification

Use https. This will encrypt and sign all your content between your server and the users web browser.

This does not protect from modification on your server, of course, but when your server is compromised then everything is lost anyway. Web application security simply doesn't work if the server gets compromised.

If you want to sign your code, then Browser-based Javascript isn't the right technology, because there is no code signing and verification system in web browsers. It would be hard to introduce one, because then all scripts on the whole WWW would suddenly need to be signed or the users would get bombarded with missing signature warnings, which will lead to them getting used to just ignore them.

An alternative option would be to use a good old Java applet, because they support code signing.


How to verify a GPG file signature on Linux and Windows without connecting to the Internet?

2) For Linux - what are the lines to input in the command line?

On Linux:

gpg --verify file.asc file.exe

You can also use a shorthand:

gpg file.asc

which will aks you which file is the signed file.

In the special case where the signature file is named exactly the same as the signed file, except with .asc appended, this will automatically guess that this is the file to be checked against the signature.

  1) For Windows - what are the lines to input in the command line?

I believe the same commands as used for Linux should work on Windows, provided GPG is installed. I cannot be sure though and I currently lack the ability to check it. I hope this answers proves useful to You either way.


Configure Wireshark to capture preformatted data from pseudo-device

Wireshark is usually a poor choice for things that must run continuously.  dumpcap, part of the wireshark suite, is a better choice.  You should be able to specify the hone device with -i hone (or -i /dev/hone) to dumpcap.  Alternatively, dumpcap can read from a named pipe, which could read from the device.  See: https://www.wireshark.org/docs/man-pages/dumpcap.html


How are sites like PersonalCapital safe/trustworthy?

Who, besides the owner of the sites, says they are secure?

One big problem is that they must store your password in a recoverable manner. This is contrary to best practice. No matter what the site does, there must be some way to get the clear-text password. This is definitely a risk.

While IANAL, I know that banks' user agreements typically require you to keep your password secure and hold you liable for damages if, for example, you give your username and password to a third party. This is different from, say bank account numbers. Those are not intended to be secret and you are not liable if they are misused, provided you didn't actually partake in their misuse.

The sites are, of course, likely to be targets of attackers due to their high value.


Is it secure to return a JWT to an already-logged-in user?

Providing a JWT token to the authenticated user is not a problem, but you shoud take into account the following considerations:

Are your environment secure (is it internal or public network)? Do your use secure transport (TLS) for communications?
If not,you shoud care about token integrity and privacy using JWS and\or JWE
Do you transfer any PII (Personally identifiable information) data?
If so, you should always use encryption for the tokens.

Anyway, before using JWT tokens look into OpenID Connect specification http://openid.net/specs/openid-connect-core-1_0.html that actually describes how to use JWT tokens for SSO, some common vulnerabilities and privacy issues.


The other answers mostly talk about attaching arbitrary code to images via steganographic techniques, but that's not very interesting since it requires that the user be complicit in extracting and executing that.  The user could just execute malicious code directly if that's their goal.

Really you're interested in whether there's a possibility of unexpected, arbitrary code execution when viewing an image.  And yes, there is such a possibility of an attacker constructing a malicious image (or something that claims to be an image) that targets specific image viewing implementations with known flaws.  For example, if an image viewer allocates a buffer and computes the necessary buffer size from a naive width * height * bytes_per_pixel calculation, a malicious image could report dimensions sufficiently large to cause the above calculation to overflow, then causing the viewer to allocate a smaller buffer than expected, then allowing for a buffer overflow attack when data is read into it.

Specific examples:

http://technet.microsoft.com/en-us/security/bulletin/ms05-009
http://technet.microsoft.com/en-us/security/bulletin/ms04-028
http://www.adobe.com/support/security/bulletins/apsb11-22.html
https://www.mozilla.org/security/announce/2012/mfsa2012-92.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability

In general, these sorts of things are difficult to protect against.  Some things you can do:

Keep your systems and applications updated.
Enable DEP.
Enable ASLR if possible.
Avoid running programs with administrative privileges.
On Windows, Microsoft's EMET could also provide some protection.


What happens if 1password or allpass are gone?

It shouldn’t be too much of a serious problem.

What I guess you are referring to is that your password database on one of those service’s servers is gone/cracked.

The cracked possibility

If the servers were to be cracked and your database to be released in the wild, then you’d probably be safe, depending on the security of your password. As databases are encrypted, only someone with the password (you) can unlock it. However, if someone was to use password cracking on your database and that you used a weak password, it could be cracked. That’s why it’s recommended to have a VERY SECURE PASSWORD that you’ll still remember (no forgot my password function here). I’d still recommend changing your passwords tho, but you don’t have to rush it.

The server shutdown possibility

If it happens, then don’t worry, because the app probably stored your database locally, and you’ll be able to export it. lHowever, I’d still recommend doing backups regularly, and storing them somewhere safe, and even better, doing 2 backups and storing them separately.

Another option

If you don’t trust the company’s servers, you can use a serverless solution called master password that works without any server whatsoever, but doesn’t really let you choose a password. For a more traditional style, there’s keepass, an open source database file format for which multiple different softwares/apps (keepass 2, keepassxc, keeweb, etc.)  were developed, and therefore lets you have the freedom of host, like dropbox or google drive.


Is it Possible to Prevent a Physcial Attack on Server in Remote Data Center?

I've been using Amazon Web Services to run my Java application. However, due to high costs I'm looking into getting a dedicated server from Hetzner...
I'm concerned that anyone with physical access to my server could steal my data/application...
In other words, unless I have complete trust in the people who run the company to secure physical access to my server there's absolutely nothing for me to do to protect my data. If the server is located in a foreign country (as Hetzner is) I would also need to trust the government of that country not to breach my data. And if someone did steal my data I would never find out.

I think it is incorrect to say there is absolutely nothing for you to do to protect your data. It would be more correct to say that it will be very difficult to protect your application and data from theft by Hetzner or the foreign government.
But, similarly, there would be nothing you could do (or rather, again, it would be very difficult) to protect yourself from Amazon Web Services stealing your application and data.
You will likely have to trust Hetzner in the same way you trusted Amazon Web Service.
I guess it is also incorrect to say you would never find out. For example, suppose Hetzner stole your application and then started publically selling it as their own product. You could then, for example, sue them (in international court, I guess) and probably be able to make a pretty good case.
What you could do on your end to protect yourself is make sure you have good validated documentation regarding your development timeline for the app and then if Hetzner or whoever steals your IP you could sue them...
Pre-emptively you could also put it in the contract that they will hold your app in confidence, etc, before you buy services from them.

Per the comments, there are other ways to try and secure your dedicated server. For example, there are datacenters that will rent you a lockable rack. You could install your own server in the rack and lock the rack shut with your own lock. Of course, you have to trust that the datacenter owner wouldn't cut through your lock, but at least if they did you would know about it next time you visited the datacenter.


Personal cipher/digest preferences ignored when generating a new key pair in GnuPG

The personal-digest-preferences option does not set preferred digest algorithms for creating keys, but during signing (if also encrypting at the same time, the most preferred algorithm supported by the recipient is chosen). From man gpg:

   --personal-digest-preferences string
          Set  the list of personal digest preferences to string.  Use gpg --version to
          get a list of available algorithms, and use none to set no preference at all.
          This allows the user to safely override the algorithm chosen by the recipient
          key preferences, as GPG will only select an algorithm that is usable  by  all
          recipients.   The  most  highly  ranked digest algorithm in this list is also
          used when signing without encryption (e.g. --clearsign or --sign).

To set the default preferences for creating new keys, use default-preference list instead. Be aware this requires the same input you'd use for setpref in the --edit-key menu; containing all your preferences for encryption, digest and compression algorithms.

   --edit-key
          Present  a  menu  which  enables you to do most of the key management related
          tasks.  It expects the specification of a key on the command line.

          [...]

          setpref string
                 Set  the  list  of  user ID preferences to string for all (or just the
                 selected) user IDs. Calling setpref with no arguments sets the prefer‐
                 ence list to the default (either built-in or set via --default-prefer‐
                 ence-list), and calling setpref with "none" as the  argument  sets  an
                 empty  preference  list. [...]


SSL is handled inside the applications (like browsers) themselves by using libraries like SChannel, Secure Transport, OpenSSL, NSS etc. This means only encrypted traffic enters or leaves the applications. Anybody wanting to get access to the plain traffic without being an active man in the middle would need to inject itself into the  process of the running original application or would need to modify the application binary or similar.

I'm not aware of any VPN which would do this and it is also not needed for any routing decisions. Routing is done at the level of the IP addresses (Layer 3) and not at the application level.


What is the safest way to ssh to a machine behind a router?

There are many automated bots out there that will try to attack SSH servers, but if you take a few precautions you can actually make SSH very safe.

Disable password-based login completely, and make public/private key pairs the only way to log in. This page provides information on how you can disable password login, and this one shows you how to set up key pairs. It is basically impossible to brute-force a key, so this step alone will dramatically increase SSH security. The only downside is that you'll have to copy the key to every computer you need to log in from.
Set up rate limiting - block an IP address after a certain number of incorrect password attempts. There are many ways to do this; I use fail2ban but if you search Google you'll find many alternatives. This is important because if you don't block IPs, you'll have bots guessing passwords for literally hours on end. Granted if you are using key-based logins they'll probably never succeed, but they'll still use up a good chunk of bandwidth by generating a lot of junk SSH traffic (and also fill up your logs).
If you know you're only going to access this server from certain IP addresses, you can allow only those IP addresses and block all others.
Disable login as root - the vast majority of bots will try to target the root username.
Check the login logs from time to time for unauthorized access.

If you take these steps you should be ready to open up SSH to the Internet. As long as you keep your keys safe and your server packages up to date, you shouldn't have any issues with SSH security.

EDIT: If you have two machines you need to access but only one public IP address, you have two options: You can set up port forwarding to one machine, and if you need to access the second machine, you would log in to the first one and SSH to the private IP address of the second one from the first one.

Your other option is to change the SSH port of the second machine from 22 to something else (2222, for example). Then you can forward port 22 to the first machine, and 2222 to the second machine. If you need to access the second machine, then you'd specify port 2222 in your SSH client. (Side note: If you want, you can use non-standard ports on both machines to cut down on bot traffic.)


What happens if my VPN drops momentarily while using an SSL connection?

The "tcp" in your network stack will happily compensate for an outage less than the the tcp timeout, asking the server to resend any packets it has missed. The existing socket connection will not be switched across a different route (this is often done on routers but not on endpoint devices). Since the tcp network stack is very good at this, there is no capability within the browser to handle such events.

I don't see how content could be delivered without any network connection. Note that rendering and javascript execution occur asynchronously from the content retrieval (both from servers and local cache) hence the screen may change without data packets being exchanged.


Moving all servers to routeable IP Addresses

A properly configured firewall protecting routeable addresses provides equivalent security to the de facto firewalling provided by NAT.  There may be a slightly greater risk of holes opened up by misconfiguration with routeable addresses, but as the old saying goes, "Nothing is foolproof, because fools are so ingenious."

You'll want to examine assumptions - what advantage do they think this will provide them?  Are they sure they can get the number of addresses needed to cover their systems?  But your concerns that routeable firewalling vs. NAT is insufficient is not true with today's firewalls.


There is nothing hindering you from testing within your own network. To get a rudimentary understanding of what is involved with testing, I suggest you familiarize yourself with the Penetration Testing Execution Standard, OSSTMM, and other similar pentesting frameworks. Once you begin establishing the who, what, when, where and why, it will make things easier for you to set up your own environment. For testing I never set up anything in my network (there is no trying to mimic a client) because I can never know what patch levels they have, what software is installed, and so forth. Rather than re-invent wheels, there are plenty of "hackable" virtualized instances you could download. I suggest NetInVM. But to answer your question, what you do in your private network is not bound by any of the common USC (US law) computer related laws.


Generating one time URLs which can be revoked

Looks like you have a pretty good idea what you're doing.

The one-time link pattern is pretty common for things like email verification. Typically, you'd store the expiration date in a database and/or use a signed string in the URL which includes the expiry in the string-to-sign. These are just precautions to avoid trusting user input.

If you want to be really thorough, you can send them the actual random ID or token URL, and then store a hash in the database to avoid someone using the token if you have a data breach.

You're pretty vague about the context of the proposed AES-encrypted parameters. I would usually include sensitive information which is not required for the URL-routing in a message body, instead of the URL. That way, it doesn't appear in web server or proxy logs. AES-encrypted data may also push you over the URL length limit pretty quickly, depending how large the plaintext content is.

Edit: For completeness, Azure Storage SAS Tokens are a great example of a cryptographic method that requires no database record, and is revokable. Revocation is done by changing the service's API Key... which would revoke all tokens issued by the same key.

Given that I don't have a lot of information about the system in use,
I would recommend the simpler database lookup, over any solution that requires cryptographically sophisticated measures.

Also, for cryptographic methods to work as a one-time link, some parameter known by the service, and included in the URL, must be changed when the link is used. This parameter doesn't have to be a database lookup, but there does need to be a persisted change. For example, if the link is a one-time upload URL, the presence of a file in the upload directory might invalidate the URL.

Lastly, the database-stored value is simpler in that there is only one source to check for validity. With the no-database solution, you'd need to check against the secret (ie. the encryption key), and also whatever factor invalidates the link after first use.


Blocking brute forcer with multiple IPs in range

The inetnum and range come from the following IP whois information and simply represents the IP range used for BGP by the Internet Service Provider.

The changing of IP addresses could actually be a number of different things but it could simply be them using a pool of IP's from the ISP, a Chinese bot net or a group of Tor exit nodes (unlikely but possible, and something you could look up).

In any case, you need to stop this. It's great that you have Fail2Ban setup but it would be wise to move your SSH daemon to a high port (I recommend above TCP/30000)

Likewise as @tlng05 mentioned switch from password only to public-key authentication if you can as that tends to stop a lot of brute forcing. Note: when doing this make sure password auth is really disabled and not an option after public-key authentication times out.

If your organization has no business from China you could block that IP range for a few days but I don't generally recommend blocking countries except in very specific cases.

Finally it may be worth setting up a honey pot with a bad password on SSH to see what the attackers next steps will be and also waste more of their time (increase their cost of attacking).

It's worth e-mailing the abuse@ e-mail they provide in their IP Whois results but there is no guarantee anything will be done. Some providers are great at helping to block things like this others will ignore your request. None the less it's wise to do so if you have time (BTW: I've seen this automated).

Can you limit access to this host from certain source IP addresses ? If so that would allow you to block 99% of the Internet which would be a much better solution.

Likewise connecting to a jump-server via VPN first would also help. (Many ways to solve this problem).

If it's an option one way or another you definitely want to block that attacker and watch for their return.

IP Whois results from looking up one of the IP's you listed:

Source: whois.apnic.netIP Address: 221.194.44.223 (China)
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '221.192.0.0 - 221.195.255.255'

inetnum:        221.192.0.0 - 221.195.255.255
netname:        UNICOM-HE
descr:          China Unicom Hebei Province Network
descr:          China Unicom
country:        CN
admin-c:        CH1302-AP
tech-c:         KL984-AP
remarks:        service provider
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CNCGROUP-HE
mnt-routes:     MAINT-CNCGROUP-RR
status:         ALLOCATED PORTABLE
remarks:        --------------------------------------------------------
remarks:        To report network abuse, please contact mnt-irt
remarks:        For troubleshooting, please contact tech-c and admin-c
remarks:        Report invalid contact via www.apnic.net/invalidcontact
remarks:        --------------------------------------------------------
mnt-irt:        IRT-CU-CN
changed:        hm-changed@apnic.net 20040329
changed:        hm-changed@apnic.net 20060124
changed:        hm-changed@apnic.net 20060125
changed:        hm-changed@apnic.net 20080314
changed:        hm-changed@apnic.net 20090508
source:         APNIC

irt:            IRT-CU-CN
address:        No.21,Jin-Rong Street
address:        Beijing,100140
address:        P.R.China
e-mail:         zhouxm@chinaunicom.cn
abuse-mailbox:  zhouxm@chinaunicom.cn
admin-c:        CH1302-AP
tech-c:         CH1302-AP
auth:           # Filtered
mnt-by:         MAINT-CNCGROUP
changed:        zhouxm@chinaunicom.cn 20101110
changed:        hm-changed@apnic.net 20101116
source:         APNIC

person:         ChinaUnicom Hostmaster
nic-hdl:        CH1302-AP
e-mail:         abuse@cnc-noc.net
address:        No.21,Jin-Rong Street
address:        Beijing,100033
address:        P.R.China
phone:          +86-10-66259764
fax-no:         +86-10-66259764
country:        CN
changed:        abuse@cnc-noc.net 20090408
mnt-by:         MAINT-CNCGROUP
source:         APNIC

person:         Kong Lingfei
nic-hdl:        KL984-AP
e-mail:         konglf5@chinaunicom.cn
address:        45, Guang An Street, Shi Jiazhuang City, HeBei Province,050011,CN
phone:          +86-311-86681601
fax-no:         +86-311-86689210
country:        cn
changed:        konglf5@chinaunicom.cn 20090206
mnt-by:         MAINT-CNCGROUP-HE
source:         APNIC

% Information related to '221.192.0.0/14AS4837'

route:          221.192.0.0/14
descr:          CNC Group CHINA169 Hebei Province Network
country:        CN
origin:         AS4837
mnt-by:         MAINT-CNCGROUP-RR
changed:        abuse@cnc-noc.net 20060118
source:         APNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (UNDEFINED)


How to prove a password guessing theory from Matt Bishop's book "Introduction to Computer Security"

With mathematics:

Suppose there are n possible passwords. Password number i has probability pi of being selected. It is assumed that the attacker knows the exact values of the pi and tries them in due order. Without loss of generality, I assume that p1 is the most probable password, and so on (i.e. pi >= pj whenever i < j).

Let qj the sum of all pi for i ranging from 1 to j. qj is the probability that the password is part of the j most probable passwords (necessarily, qn = 1: the password is part of the space of possible passwords). The following holds true:

  For all j, qj >= j/n

Because if qj < j/n (for some value j), then there must be one value i lower than j such that pi < 1/n. The condition on the pi (non-increasing values) then implies that all pk for k > i are lower than 1/n, and this implies that qn < 1, which is not possible.

qj is the probability that the attacker succeeds by doing at most j guesses. Higher values imply faster success, i.e. if there are two distribution probabilities P and P' such that q'j >= qj for all j, then the attack for P' succeeds at least as fast as the attack for P. Note that two given distribution probabilities cannot necessarily be compared like this (there could be some, but not all values j such that q'j >= qj), but, if they can be compared, then the conclusion follows.

The uniform distribution (pi = 1/n for all i) implies qj = j/n for all j, which, as explained above, compares favourably (for the defender) to all other distributions. Therefore, this is the distribution which makes the attack slowest.

With physics:

Attack success speed is higher when password entropy is lower. Uniform distribution maximizes entropy.


What does hacker need to steal from my PC to compromise my Facebook session?

The other answers are bad enough I've decided to post a clear answer...

  So if someone would get on my PC, he could steal some files and put it into his browser to compromise my session. Is that possible?

Yes, if someone has physical access to your machine, and you have not secured your data with something like full-disk encryption, yes, session hijacking would almost-certainly be possible.

Browsers store their user profiles (including session cookies) to disk somewhere, and anything stored to an unsecured disk can be copied to another disk. You can essentially clone a profile in this manner.

There may be some minor tricks or issues involved either on the browser's or the website's end, so it might be slightly more difficult than a simple copy-paste job, but the basic issue is the same. If someone has access to your data, they can copy it and use it to impersonate you.

Physical Access is Total Access:

Of course, when a malicious individual has access to your device, there are a number of other attacks they could perform, such as replacing hardware to add hardware keyloggers and so-forth. Physical security for your device is still important.


How to be sure content was generated on a specific software?

No there is no way to future proof the content output of an open source product against mimic software acting as an impostor.  By definition, any open source project can be forked to do exactly the thing about which you are concerned.

You can (must) address this issue with trust rather than technology.   Trust is precisely the opposite of an API.  Trust relies on humans making risk decisions rather than code somehow watermarking output.


After having changed wifi password the client list shows devices, which do not know yet the new password

I'm not particularly familiar with the router model you're working with, but I can think of two possibilities for why this might be, without a vulnerability in the router being involved.

DHCP Leases

One Possibility is that the Client List you're referring to is generated using DHCP Leases. In this case, the device might not actually be connected - just listed for historical reasons.

To summarize (very briefly), a DHCP Lease enables a device to keep the same IP Address on the network as long as the device continues to renew it's association with the network before the Lease expires.

DHCP Leases are usually associated with a few properties of the device, on a list stored by your router. These properties are:

MAC Address (this is usually like the primary key - even if the hostname changes the device will still get the IP Address if the MAC matches)
Hostname
Expiry
Last time the device was connected

So even though you've changed the WiFi password and rebooted the router, the router may have kept the existing Lease list so that when devices reconnect it can remember their IP Addresses.

Guest Network(s)

Another possibility is that the device is connected to a Guest Network. The Guest Network may have a different password - or no password at all. This would leave the device's connection settings unaffected if you change the password on the main network. In this case the device would actually be connected to the WiFi, but would normally not have access to any of the devices on your main (non-guest) network.

Check the device settings for a way to disable guest networks if this is the case. Or you may be able to assign a different password to the Guest Network.

Other Possibilities

Without going into too much detail on these, here's some wild possibilities to look at for diagnosing this issue:

Router Bugs (get latest firmware, check with manufacturer for known issues)
Another WiFi access point connected with Ethernet to your main router. Possibly a range extender? The device may be registered with DHCP to your main router, but connected to a different WiFi Access Point.
If the device you're referring to is a Phone - and a device linked to an account that shares the Phone's KeyChain was already updated - the device could have synced the new password via the system's KeyChain over cellular data. My iPhone does this when I update the password for my network on my MacBook. Could also happen with ChromeBook and Android or two Android devices.
Common for people working in development or IT: If you have Virtual Machines running on your computer (VMWare, VirtualBox, Parallels, Windows Hyper-V, etc.) and the VM is connected in "Bridged" mode, it will acquire a DHCP lease with your router under a virtualized mac address, without needing the WiFi password. The VMs would operate on a low level of the network without being aware of the physical network device on the host machine, because the virtualization software would provide a "virtual" network card.


OCSP: What is "hackedirl.files.wordpress.com"?

hackedirl means HackedIRL -> Hacked In Real Life

It is a name used by sites of the Cheezburger network (fail blog and others) - just a funny name, nothing to do with hacking.

The reason you see all these IPs is that Cheezburger network uses the wordpress platform for the content of its sites and wordpress does load balancing and redundancy using DNS.

Moreover, as this tool can verify that all the certificates of the multiple servers are fine.

hackedirl.files.wordpress.com uses the same certificate with all other wordpress sites, it is issued to *.files.wordpress.com. The OCSP responder mentioned in the certificate is

  Authority Information Access:
                  OCSP - URI:http://ocsp.godaddy.com/

The error you see means "The OCSP server experienced an internal error." as you can see here.

I don't know exactly why it fails for you, but a packet capture would be usefull. All is working fine here with that site and the OCSP request.

EDIT: Looked further into the source code, and here is what really happens:
This error will be presented if any of the following conditions holds true:

the http server session is not created, for whatever reason
the http client session is not created, for whatever reason
the http request with mime subtype "application/ocsp-request" is not made correctly
the response from the ocsp server is very large
the response has a flag set that says that it an internal error happened server side

So, my guess is that you have some connectivity problems of some sort, and you are unable to contact http://ocsp.godaddy.com/ successfully.


Is it bad to give www-data user access to Postgres client certificate?

Ultimately, the web server needs access to its database.  Using file permissions for a limited user is a tried and true way to do this, so I don't think you are doing anything inappropriate here.  There are some tools - like Hashicorp's Vault, KeyWhiz, etc - that provide some alternatives to this, but even those ultimately need SOME way of identifying the valid user (though they give you some alternatives, like allowing one and only one request from a given EC2 instance which may be more secure in some instances, especially in a situation where you are autoscaling and if an instance fails it is torn down.)


Can my company see the contents on my iPhone if I used my work email on it?

I doubt that they can actually see the content of your phone, however an exchange administrator is able to remotely wipe your device at any moment.

This is usually done in case of a critical security risk coming from your device, which can also be the phone being lost.

They can also turn off phone functions such as bluetooth, web browser, camera, etc..

Please see this answer which shows what an exchange administrator can do on your device remotely:
Microsoft email servers "require remote control of Android device security features"

By the way you have to accept this policy when you add your exchange account to your smartphone's email client.

As a personal advice, I recommend you next time to use the web access if your company allows it. In that case you would just login to a web portal (Outlook Web Access = OWA) with your company credentials and they will have no access to your phone whatsoever.
It has not the same functionalities as having the mailbox on an actual client, but for just sending an email for being late you shall be fine.


How to enable self signed certificates in Windows 10?

Better late than never:

Go to regeditor to the path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

Add SelfSignedCertificates as DWORD entry (if non exists).
Update the value to 1.

This will allow you to use SelfSignedCertificates with BitLocker.

Your certificate needs to meet the following requirements:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd875548(v=ws.10)

Or you can use a cert generated from the EFS wizzard and follow the following instructions:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd875530(v=ws.10)#sharing-an-efs-certificate-with-bitlocker


Does a malicious android WebView break the DoubleSubmittCookie countermeasure against CSRF?

It's an app. It can send your server any cookies it wants. It can save the password as the user types it. It's in complete control. You have no more "defense" against this than you do against Mozilla Firefox or Google Chrome.


Configure SSL to prefer RC4 ciphers over block-based ciphers - BEAST

The cipher suite is (mostly) orthogonal to the certificate. The RC4-based cipher suites are:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Both require a certificate with a RSA key, and "suitable for encryption" (that is, a certificate which has not been marked as signature-only). There is high probability that your certificate is already fine for that. Beyond that, the certificate is not related to the choice of symmetric encryption algorithm.

The configuration of cipher suites employed by your server depends on the server type. If your server is IIS, see this previous question which describes how it is done.

Apparently, there was an old draft from a decade ago, which defined three additional RC4-based cipher suites:

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_WITH_RC4_128_SHA

The first two use a key of only 56 bits, which is not enough for serious security (although it may deter some low-power amateurs); these were defined in order to comply with the US export rules which were briefly in force at that time. The third cipher suite provides the only way to use RC4 with a large enough key, when your server asymmetric key has type DSS; it also enables Perfect Forward Secrecy, which is neat.

These suites are not standard (they are not in the IANA registry) but some browsers use them, in particular Internet Explorer. I suppose IIS can be made to support them.

(Certificates with DSS keys are pretty rare nowadays.)


The client sends a list of cipher suites that it supports. The server then chooses the cipher suite that will be used, among those sent by the client. So the server chooses the cipher suite, within the constraints of what the client supports (or is willing to admit that it supports).

Also, the list of supported cipher suite sent by the client is supposed to be ordered by preference; a courteous server should select the suite most preferred by the client, among the set of suites that both client and server support. Not all SSL/TLS servers are courteous.

The certificate impacts the choice. For instance, cipher suites "TLS_RSA_*" assume that the server's public key is of type RSA, and suitable for encryption; they cannot be used if the server's key is not a RSA key, or if the extensions within the certificate (i.e. the "Key Usage" extension) forbid encryption-based key exchange (e.g. a signature-only certificate).


What is the most secure way to do OCSP signing without creating validation loops?

During normal chain validation, you are supposed to check the revocation status of each certificate in the chain. To check the revocation status, you must obtain a CRL or an OCSP response; both types of objects are signed, and, before usage, must be validated. Validation of a CRL or an OCSP response entails verifying a signature, relatively to the public key of the object's issuer, public key which is obtained from... validating another certificate chain. The whole process is recursive and you can end up with validating many certificates in the process.

Of course, recursion has potential for loops, and loops are bad.

Consider a simple path: Root -> SubCA -> EE.

You are validating the path, verified all signatures, and reached a point where you also checked that SubCA is not revoked. Now you are considering the EE certificate. The EE certificate contains an AIA extension which points to an OCSP responder; you talk to that responder, and get an OCSP response. Great ! The OCSP response appears to have been signed directly by SubCA, using its private key (the same private key as the one used to sign the EE certificate). This is good: you have already validated that key, including revocation status, so it suffices to check the signature on the OCSP response, and then you can use it ("using" an OCSP response means looking at its contents and trusting them).

This model above is "situation 2" from section 4.2.2.2 of RFC 2560: the certificate used to validate the OCSP response is the same as the certificate of the CA which issued the target certificate ("SubCA" in our example).

Another model is supposed to be supported, described as "situation 3" from section 4.2.2.2: the OCSP response is signed by a dedicated responder, which has a certificate (let's call it "Resp") which is issued by SubCA. The Resp certificate is embedded in the OCSP response. How do you validate that ? It is easy enough to check the signatures, and also to check that Resp features the specific EKU which marks delegated OCSP responders. But how do you make sure that the Resp certificate itself was not revoked ?

The three possible ways are:

You use a CRL or another OCSP responder which will give you the information. This, of course, makes the process recursive.
Resp is made to include the specific id-pkix-ocsp-nocheck extension, which makes the Resp certificate "unrevokable" (thus you do not need to get its revocation status, since it is unrevoked by definition).
The CA does not care, and includes in Resp an AIA which points to itself as an OCSP responder. Thus, to validate Resp, you must first validate Resp. Face to this chicken-and-egg problem, you weep, then join the CA in its apathy and simply consider that Resp is "probably fine".

Unfortunately, I have encountered the third way in big PKI sponsored by huge corporations or sovereign states who really should know better.

Section 4.2.2.2 of RFC 2560 also hints at a "situation 1" where the OCSP responder is "something else" which the validation engine somehow knows to be safe through some "local configuration" (the expression "local configuration" is RFC-speak to mean "by the magic of the Fairies").

The text you quote means that Windows, up to Vista, knows how to handle situations 2 and 3. From Vista SP1 onwards, it also handles situation 1, with the following twist: the OCSP responder certificate can be "any certificate" but CryptoAPI will require CRL to validate that one. This is a drastic way to avoid validation loops.

Summary: if you are building your PKI, the method which will cause the least trouble is to use the CA key for signing OCSP responses. If you really need to use a distinct key (e.g. the CA is supposed to be offline, but the OCSP responder, by nature, is online), then make the CA issue a dedicated certificate for the OCSP responder. This dedicated responder certificate shall contain the id-kp-OCSPSigning EKU and the id-pkix-ocsp-nocheck extension. Since an unrevokable certificate can be viewed as a gross breach of policy, the recommended way is to make it very short-lived: set the responder certificate to be valid for a fortnight or so, and issue a new one very week.

As others have noted, many implementations do not check revocation status for "extra" certificates (certificates not in the main chain, but which are used to verify revocation objects like CRL or OCSP responses), which is sloppy but often made necessary (in a commercial way) to cope with big PKI who do not do things properly. It is your moral duty to do better than that (as I expose above) so as to bring us closer to the point where PKI will actually, you know, work and provide security.


Does injecting my own key material into the authenticator undermine authenticator's attestation?

The argument is that, if you supply your own key material, the key manufacturer has no way to verify that the key material is sufficiently random, not stored elsewhere, etc. Imagine if you are the victim of a sophisticated targeted attack, and you generate the key material on a computer that has malware on it which exfiltrates it to the attacker. Or perhaps a supply chain attack, Alice sets the key material then hands the authenticator to Eve to deliver it to Bob, but by the time Bob receives it Eve has changed the key material to a value she knows. This would be fixed by Bob setting his own key material, but then Alice has to trust Bob to do that correctly.

It sounds like Yubico wants to be able to say "if an attestation is verified up to our root cert, we guarantee that the associated keypair comes from a Yubikey, and the key material used to create the keypair was generated securely by us and is stored only on the authenticator." If they allowed you to set your own key material they would no longer be able to make that guarantee.

Now this doesn't really matter for public websites, and most (or all) public websites that allow U2F or WebAuthn for 2nd factor don't bother checking attestation at all. But for something like a high security intranet, there could be value in auditing a small number of authenticator manufacturers and using attestation to only allow authenticators from those manufacturers. In that scenario not being able to modify the key material could be seen as an advantage.

  Also, it looks a bit ironic since these days financial institutions tend to trust SMS and not U2F, even though SMS is anything but secure.

I imagine he's talking about employees of a financial institution rather than clients.


How can an online hack be traced back to the perpetrators?

Your points are good ones, and this is the interesting thing about tracing hacks: it is easy to cast suspicion, but is very difficult to conclusively prove where an attack came from.

Some things that narrow the field:

The language in which a program was written can often be determined, as you suggest.  This is of course suggestive, but not definitive.
As you also suggest, motive is a consideration.  Perhaps a bigger consideration is resources.  As usual, the physical resource constraints of the real world do a lot to narrow down possibilities.  This is why "following the money" is such a valuable tool in investigations.  It takes a lot of time and effort to do a really good job of hacking a network.  In this regard, it's fairly easy to distinguish between a well-funded and well organized group and script monkey messing around.  There are only so many people with motive AND resources.  Again, not definitive, but helpful.

There are several ways in which hackers might do something stupid

leaving their real name in a message/log/etc...
using their real login credentials to some known service
leaving metadata in a request that they send that can be used to identify them.  You allude to this when you talk about the user agent string.  In fact, there are many more things that a server can use to fingerprint a user.  This all presumes a web browser, though, and there are many more ways to carry out an attack.
the metadata-in-the-request problem is only really a problem if (1) the metadata gets logged, and (2) the hacker isn't careful enough to erase the log.

Barring the hackers doing something stupid, I would argue that tracing an IP down to it's source is the only real way to de-anonymize the attackers: other things help but are circumstantial.  Some things that make this hard:

clever and well equipped hackers will indeed use multiple layers of VPN software to protect themselves.  Often, when possible, VPN accounts are purchased in ways that are as anonymous as possible, making it difficult and time consuming (but by no means impossible) to trace back to the original IP address.
things like server logs will often preserve the ip address of the final hop in this VPN chain, at least giving you a starting place, but these are often doctored by clever, careful, and well-equipped hackers, making it difficult even to get started.
If you don't get to watch the attackers as they are actually working, tracing back by asking the VPN service to cough up the originating IP address may not be feasible, as they simply may not have the logs, or may have deleted them.

mitigating factors to the difficulty of tracing IP addresses:

there is no way to spoof a TCP connection, as setting one up requires a three way handshake: client sends a SYN packet, server sends a SYN ACK packet, and client sends another SYN ACK packet.  The client must thus provide a real IP address to the server (one that actually lets packets get back to the client).  This means that you can always at least get a start if you watch the attack happening.
if you can get timestamped logs of the right traffic data, there are correlation attacks that you can use to de-anonymize someone behind a vpn redirection service, or even multiple such redirection services.  The tor project people have details about many of these attacks, and have had recent issues along these lines.  Think of the packets coming from the attacker and the corresponding packets arriving at the attacked network (through multiple layers of vpn).  The time delay through the interleaving networks will be mostly the same for those packets, and some statistical analysis will then let you match them up with high confidence (see here, for instance). Clearly, the difficultly here is obtaining the requisite timestamped packet logs.  It is also possible for one of the interleaving networks to wait a random amount of time before forwarding packets, which would break this correlation attack.  It is my understanding that the wait time would have to be pretty long and would significantly degrade the usabililty of the newtork, which is why the tor network explicitly doesn't do this.


Can a DNS "route" change cause an SSL certificate error?

Changes to DNS aliases (CNAME) or IP addresses do not matter at all to certificate validation.
All what matters is that the hostname as seen by the client (for example the name in the URL) matches the subject(s) of the certificate. This name will not change on any changes to the DNS.

Often a DNS CNAME gets confused with a HTTP redirect. In the case of CNAME the name stays the same and thus the CNAME is irrelevant for validating the certificate. In the case of a HTTP redirect the name might change and this is also reflected by the change of the URL as seen in the browser.


Google has complied with 1% of requests for user data from Russian authorities, according to Google's Transparency Report.

Russian authorities can also make such requests via other countries who regularly break their own laws, like E.U. countries or the U.S.


How to use metasploit java exploit with custom payload?

You may want to
disable the payload handler
set payload to custom_exe
and
set custom::exe /custome.exe

This should get it done. You also have to keep in mind that the depending on what the exploit is doing, and how much memory space is is using, or rather how much memory space you have to execute shellcode, you may not be able to use a custom exe with this exploit.

let me know what happens.


Verify that input is a string - is it safe?

Yes, verifying the input is a string will sanitize it.

MongoDB doesn't parse strings, only JSON. A common attack on MongoDB is:

{"$gte":""}

When put in a query, this will return all objects. An attacker can pass this as a parameter, and some parsers will automatically expand it into an object, which will make your JSON look like this

{
    username: "root",
    password: { $gte: ""}
}

When this find command is run, it'll return the root user even though a password wasn't supplied.
(Note: Do not verify passwords like this)

Now here's an example where we ensure that the input is a string

{
    username: "root",
    password: "{\"$gte\":\"\"}"
}

As you can see, there's no injection, and we're literally looking for that password.


Bypass Stack Canary by going past the return address

It's terminating as a result of the canary detection.  Just because GDB shows the stack frames including your other return address does not mean code execution would have ever gotten there -- GDB is just reading the addresses up the stack ("unwinding the stack") to display the information to you.  You would only have gotten to yo if you had successfully returned from all of those functions, but since __stack_chk_fail results in the program dying without returning, that would not happen.

To bypass stack canaries, you pretty much need to leak, guess, or brute force the canary value, find an arbitrary write (e.g., write over EIP without overwriting the canary), or find an exploitable bug in the stack canary handler.


Is it possible to stay anonymous on Windows 10?

I think much of that "Tor on Windows 10 is no good" is hyperbole.

It's true that Windows 10 sends an awful lot of data home to Redmond. But this is completely independent of Tor. If you use the Tor Browser to browse the net, I don't see how Windows 10's tendency to phone home would negatively affect your anonymity in Tor, since it will phone home in the clear, while your browsing will happen over the Tor network, so the two data streams have nothing to do with each other.

There are risks, most notably the following:

The large number of installed Windows platforms makes Windows an interesting target for attacks. So zero-day attacks which target the mozilla browser variants on windows will often work against the Tor browser bundle, too. Once the Tor Browser is compromised, you really are in trouble because it then becomes possible to deanonymize you. I think the FBI did exactly that a few years ago to identify visitors of illegal services provided through the Tor network.

There's another problem if your computer is stolen. It might be possible, maybe even easy, to find out what you've been browsing in the Tor Browser due to Windows's less than ideal handling of user privacy while you're working with your computer. For example, parts of your browsing history may find their way onto permanent storage, maybe via the paging system or as deleted files etc. Its harder to counter this in windows than in, say, Linux or even a live distribution such as Tails.

But basically, if you're not trying to stay hidden from organizations with very large budgets, I'd say Tor on Windows works just as advertised. And if you do want to stay hidden from said organizations, you should think much deeper about opsec than just use Tor.


Is there any security issue while two different process using different hard link of same file?

It is not uncommon especially for software for embedded systems (BusyBox etc) to have a single binary which has everything in it and then to hard link this binary to different names in order to provide the expected command names. This approach by itself is not a problem: while the different invocations of the binary will share read-only (or execute-only) code and data segments they will all have their own read-write stack and heap, strictly separated from the rest as with different binaries.


"X-Original-URL" and "X-Rewrite-URL" Related Vulnerabilities

As mentioned in the comments, these are custom headers in some PHP frameworks.

  Many web frameworks such as Symfony 2.7.0 to 2.7.48, 2.8.0 to 2.8.43, 3.3.0 to 3.3.17, 3.4.0 to 3.4.13, 4.0.0 to 4.0.13 and 4.1.0 to 4.1.2 , zend-diactoros up to 1.8.4, zend-http up to 2.8.1, zend-feed up to 2.10.3 are affected by this security issue.

Fun fact: This was reported by Albino Wax

https://www.acunetix.com/vulnerabilities/web/url-rewrite-vulnerability/


Is connecting to the Internet directly (without a hardware firewall) risky?

Everything is risky, the question is, how risky. IT security is mainly about the effective estimation of the risks and costs and manage them.

The main fun in it is that the costs are so or so estimatable, but the risks can't. If you would know, how can your system be attacked, you could (in most cases) easily close the hole. This makes IT security more like an art.

In my opininon, your system is okay for ordinary home PC usage for common circumstances, i.e. turning your PC off and then running to the nearest hw store for a needless router would be an over-reaction.

Watch for that your firewall has a negative list (most ideal if only outgoing connections are allowed, or by default all incoming is denied, except the few what you allow). Furthermore, check that you have some DNS spoofing protection.


How to force all connections to my Apache server to use TLSv1.1 or TLSv1.2?

(This is a software configuration issue, I sense a relocation to superuser.se coming up...)

There are two pre-requisites for this configuration to work:

Openssl-1.0.1 (yes)
httpd-2.2.23 (no!)

Sadly, the SSLProtocol documentation doesn't state the require httpd version (though it is noted in the comments section, right at the bottom of the page).

The code is a little convoluted: it iterates over the list of protocols it's aware of, and eliminates those that you didn't enable. This explains the behaviour you see.

The code up to and including httpd-2.2.22 does not parse "TLSv1.1" or later (see modules/ssl/ssl_engine_init.c and modules/ssl/ssl_private.h).


Shouldn't

"/abcdefg/:pass=^PASS^:incorrect password"
 be set to

"/:usr=^USER^&pass=^PASS^:incorrect password"

to match your form action as <form action="./" and username input as <input type="text" name="usr">?


Is a Windows XP virtual machine with no network connection safe from hacking?

No - because your VM is inside a machine connected to the Internet it is not safe.

It is protected, yes, but that protection is only as good as the protection the host machine provides.

An attack could compromise the host machine via its connection, subvert the hypervisor and compromise your VM. Read this question and others in the Related sidebar to the right.

The only way to make a machine "safe" from being hacked is to have no Internet connection, no ports, no USB, no hard drive, no keyboard...in fact you'd need to unplug it, remove its RAM, bury it in concrete, etc...

This is the reason for a lot of the clarification around "safe" - you can make a machine sufficiently safe for what you want to do with it. It would require a lot more detail than your question provides.


Is it safe to monitor java process via JMX

You can configure JMX to be exposed on the local network with SSL and various authentication methods and controls enabled.  JMX will be listening on a port different from the Java application.  Assuming that the nginx server is configured to only proxy to the Java server's application port, then without that machine getting compromised, then JMX will not get exposed outside your internal network.
JMX is generally considered safe in this regard.  If you application exposes more metrics through JMX, then there maybe a leakage there, but typically not through the default JVM provided resources.
This wouldn't be any more secure than normal JMX.  If you utilized a local agent to query JMX and push data to Nagios/Zabbix/Graphite, that would be more secure.
Oh, dear lord, no.


How can I decrypt traffic on a WEP encrypted network?

WEP and WPA are different, so I will assume you are asking about WEP.  (Ask a separate question if you want to know about WPA.)

Wireshark should be able to decrypt WEP traffic if you have the cryptographic WEP key.  For instance, here are instructions for decrypting WEP and WPA traffic.

So all that is needed is a way to find the WEP key.  There are several ways to do it:

If you are connected to the WEP network, then your laptop must have the WEP key.  So all you need to do is extract it.  The way to do this will be OS-dependent, so if this is what you want to know, ask a separate question about how retrieve the WEP key for a wireless network you are connected to, and specify the OS.  (e.g., on Linux, iwconfig will show you the WEP key.)
If you are not connected to the WEP network, but want to find the WEP key anyway, there are tools to do this by eavesdropping on a bunch of traffic.  I recommend aircrack-ng (see this tutorial on aircrack-ng).  Here is a tutorial on using aircrack-ng with Backtrack to recover a WEP key.  Or, you could use the link you provided.

WARNING WARNING WARNING: Do not do this without authorization of the owner of the wireless network.  Hacking other people's wireless networks without their consent is highly illegal in most countries.  Don't do it!

Old information from the previous iteration of the question (you can ignore this):

For WEP, if you only have the password and not the cryptographic key, then you will need to recompute the crypto key from the password.  It is computed as a deterministic function, and if you Google for WEP key converter or WEP key calculator you should be able to find utilities that will do the conversion for you.  Or, you can just go to your access point's web configuration, and it will usually tell the WEP key (indeed, you could enter in a new passphrase and see the resulting WEP key).

For WPA, you may need to capture the traffic associated with the initial association between the client and the access point (if you just come in later and capture it after the client has already connected to the access point, you may not be able to decrypt).


Pre boot authentication for Android phones

What would the use be of preboot authentication when Android doesn't support full disk encryption for all files and folders? none.


A private netowrk is a network consisting of cables and computers which are physically separated from the rest of the World. This makes for good security, and, furthermore, convincingly good security (having security is part of the goal, but you also want to know it).

A VPN is the cheap emulation of a private network: the wires are still linked with the Internet; the isolation is done with mathematics (cryptography) instead of physics.

Compared to "secure transmission protocols" (which work), the good point of a VPN is that it works at the OS level: as the system administrator, you configure the VPN once, and it protects the data transfer from all the applications, regardless of how poorly these applications were designed. Doing a proper SSL/TLS is not easy; for instance, many applications don't check for certificate revocation. Even if applications do the work correctly, going through the configuration of all of them is tiresome. A VPN saves time, so the sysadmin can more easily concentrate on ongoing attacks or other crucial tasks like resetting users' passwords or "continuous Internet-based training" (aka Websurfing).