What damage could be done if a malicious certificate had an identical "Subject Key Identifier"?

The Subject Key Identifier does not play a role in validation, at least not in the algorithm which makes up section 6 of RFC 5280. It is meant to be an help for path building, the activity which takes place before validation: this is when the entity who wants to validate a certificate assembles potential certificate chains that will then be processed through the section 6 algorithm. Section 4.2.1.2 describes this extension, and includes this text:

  To facilitate certification path construction, this extension MUST
     appear in all conforming CA certificates, that is, all certificates
     including the basic constraints extension (Section 4.2.1.9) where the
     value of cA is TRUE.  In conforming CA certificates, the value of the
     subject key identifier MUST be the value placed in the key identifier
     field of the authority key identifier extension (Section 4.2.1.1) of
     certificates issued by the subject of this certificate.  Applications
     are not required to verify that key identifiers match when performing
     certification path validation.

These "MUST" are obligations on the CA: to conform to the profile which RFC 5280 describes, CA must take care to match the Authority Key Identifier of the certificates it issues to its own Subject Key Identifier. Take note of the last sentence: this match is not part of what validation must verify.

It is recommended by the RFC to compute the key identifier through hashing, because it will minimize collisions, thus guarantee maximum efficiency of this extension for path building. However, hashing is not mandatory. CA can choose the identifier in any way as they see fit; and verifiers certainly do not recompute identifiers. This is pure byte-to-byte equality test. Also, I know as a fact that Microsoft's implementation of path validation is ready to build and try to validate paths where key identifiers do not match.

The worst that a rogue CA could do by reusing key identifiers is to make path building more difficult; this might trigger a kind of denial of service for verifiers who do path building through key identifiers and are too lazy to try otherwise. In practice, verifiers tend to build paths by matching the subject and issuer DN, not the key identifiers, so the practical impact should be close to nil.


Does Tor browser work with college network?

The short answer is that any internet connection you access that is also tied to you personally (e.g. the login credentials on a college network) can be traced back to you. Therefore it is not suitable for full anonymity online. You enter your login credentials to access the network, the network admins can trace your connections through their network to a Tor node. Theoretically that should be all they can see because your traffic should be encrypted. But if your adversary is some No Sugar Added ice cream it might also be monitoring exit traffic of their hosted Tor nodes. This would make you risk a pairing up of your traffic with exit traffic.

If Tor will connect is a different question. This would depend on if your ISP (sometimes the college for many universities and colleges) has blacklisted any IPs.

So, it really depends what you need the anonymity for. Investigative journalism critical of your host country? I'd say probably not a good idea. Avoiding the eyes of malicious non-state actors - You're probably okay to use it.

One other thing to consider is if your college bans Tor traffic and what policies regarding this are on your campus.


One improvement you could look at for this is conducting malware scans of uploaded files.  Whilst this won't be a 100% protection, it could help reduce the risk of one of your users accidentally (or deliberately) uploading a malicious file which could then infect other users.


Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database as-is.

On the other hand, hashing on the client side is nice in that it ensures the user that the server has no knowledge of the password - which is useful if the user uses the same password for multiple services (as most users do).

A possible solution for this is hashing both on the client side and on the server side. You can still offload the heavy PBKDF2 operation to the client and do a single hash operation (on the client side PBKDF2 hashed password) on the server side. The PBKDF2 in the client will prevent dictionary attacks and the single hash operation on the server side will prevent using the hashed passwords from a stolen database as is.


Technical requirements applicable to IT department for GDPR

The general Data Protection Regulation doesn't require a massive amount of technical understanding. They would need to know about the technical Infrastructure of the organisations and all the locations personal data is stored, processed and in transit, making it easier to handle Subject Access Requests.

The company would need a reasonable understanding of security, ensuring adequate security controls and procedures are in place. This also goes for personal data stored on paper, ensure they are also secure.


Tracking a backdoor by recording packets

Would this work in the idea that I would eventually see some odd ip address?

Generally, yes. If the malware is actively communicating, you will be able to capture the traffic and eventually conclude which servers it's contacting (and read the traffic if it's not encrypted).

The problem with your approach is that you can only confirm that there is malware if you do discover something. The reverse is not true. The backdoor could just remain inactive for an arbitrary amount of time. Also, chances are that you don't recognize malicious traffic as such:

A clever backdoor could be designed to only send traffic if other processes are communicating at the same time. For example, if you are browsing the web, it is really hard to dissect all connections for all loaded resources. Your backdoor could just mimick a request to an image hosted on a seemingly unsuspicious AWS server and it would be hard for you to tell if that request originated from your web browser or the backdoor. Also, it is possible for malware to evade detection by using seemingly unrelated protocols, e.g. DNS or ICMP. Finally, malware is often communicating over TLS and you will have to be able to decrypt the traffic for definitive conclusions about what is going on.

So capturing all traffic will only lead to a conclusion under the assumption that the malware is actively communicating and that you are able to recognize  traffic by the backdoor as such.


Has there ever been a case of a CDN spying on proxied HTTPS traffic?

If you don't trust the CDN, don't use it.
You have absolutely no way to know it the CDN reads your data or not. The CDN probably reads the data, to mitigates attacks.
If the data require a high level of protection, use a CDN under your jurisdiction.
If the data require a medium level of protection, you could bypass the CDN, and if you are under DDOS attack, switch to the CDN (switch your back-end to another IP too)
For static data, you can use a less trusted CDN if you :

use SRI to ensure the integrity of your resources
mask your referrer to preserve the privacy of your visitor (ex: <meta name="referrer" content="origin"> )


Is a firewall required for a SOHO network?

There's very little that's required.  However, is it a good idea?  That's possibly a better question.

Given that the O in SOHO stands for "Office", it would be a good idea to firewall that traffic off.  IoT devices, as a rule, aren't built with security in mind and some of them can be/are used in botnets.  If nothing else, blocking incoming traffic would be a useful principle to place on that network to keep those devices from being attacked.


How to decide what information should be shown to an user?

Like commented by @tim this is a very broad question. I think it boils down to two things:

Look at the privacy laws in your region (GDPR in Europe for example). These are legally binding and should always be adhered to especially when talking about personal data (like combination name, birthdate, address). These laws normally (and should) contain the want for a privacy statement that explains what data is stored and how the data is used/shared. These laws always include what I will say in part 2.
Principle of least privilege (or how you would say that for data) should apply. Everything you show publicly (and everything that you store!) you should ask yourself: "Do I need to show it for correct use of my application?"

So actually read the law (or articles that summarize it) and try to limit what you show and do not hide behind the: "they gave the data voluntarily so it is mine now to do with whatever I want!".

Further, your explanation of the application is a bit vague so I am not sure what it should do. But let's answer the more detailed questions:

After adhering to point 1 and 2 all data that you need and a user has provided you can be shown to the user that owns that data.
If you want to share videos/photos or other personal media you can but be sure to have a clear privacy statement that explains the who and how of data sharing.
I would say never share anything with anonymous users. Unless it is the whole idea of the application then again clearly state it in your privacy statement.
Never share: addresses or phone numbers, and I would say do not store them unless absolutely necessary.
E-mail addresses: make those opt-in to share. So a button that someone can choose to share this (default is OFF)

I hope this helps you google around for templates and how other sites have implemented their privacy (-by-desing), here are some links:

GDPR wikipedia

Privacy policy/statement template


Switching to new encryption method (without losing data?)

The best way to do this is simply to migrate the crypto when a user logs in, or invalidate their password and data if this hasn't occurred after a few months.

So, for passwords, the user logs in, we know their plaintext password, so we just compute the new hash. Optionally force the user to pick a new password. For encrypted data, the user logs in, we know their password again, so we just re-encrypt.

The problem with re-encrypting is that you still need to know the password for the new cipher to use. It's also prone to situations where the underlying cipher is weak against timing or power analysis attacks.

The problem with re-hashing is that any collision vulnerabilities in the first hash scheme are perpetuated into the new scheme.

So for both, it's better to just wait for the user to log in and then migrate them over.

An alternative is to double-hash or double-encrypt as a temporary measure, then migrate on login. It's more development work, but works out a bit safer.


Cryptographic Hash vs. MAC (or, why hash alone is insufficient)

Just as you added the authentication tag to your question, that is actually the answer to it.  The MAC involves a piece of information that should be known only to the parties that are communicating: the key.  When paired with encryption (as in your questions), MACs are used with symmetric encryption, therefore the key shall be the same and known only to the two parties communicating.

Contrary to a simple hash (which provides integrity) a MAC also provides authentication.

(In asymmetric encryption digital signatures provide these features.)

This is not extremely important when performing encryption since an attacker would need the decrypted message to generate the hash anyway.  The authentication part of the MAC is much more important in not encrypted communication.

Hell, assuming that K is key of a block cypher and M the plaintext then:

Encrypt(M, K) || MAC(M, K)
Encrypt(M, K) || Hash(M || K)

Are equivalent on high level meaning.  Since a cryptographic hash that receives a secret key as the input is a valid way of generating a MAC.


Why don't despotic countries simply block all encrypted traffic?

Because HTTPS underpins a lot of websites. Anywhere you authenticate, you should be using HTTPS. So that's things like:

banking
social media
government sites like tax submission
anything with an account

If you suddenly took away HTTPS, you'd be ensuring that any authentication traffic would be gone. It's not like you can petition Facebook and Goldman-Sachs to create HTTP-only versions of their websites. If the government tried to implement an HTTP-Only* authentication model for internal services, it would be a useless service. You'd be able to grab credentials easily, casting doubt on everyone's online identity.
Simply being on the same network as someone (say, your despotic leader) and running a packet dumper on your machine will capture their credentials, and there's nothing they can do about it.

Blocking all HTTPS traffic would be highly disruptive to a country's online activities, and would stamp out the very thing they are trying to monitor.

* encryption-less, port 80 only, etc.


Detecting attempts to manipulate help desk support

I'm not sure about "standard", but my company does the following:

User forgets password
User calls IT / Help Desk / etc.
IT gathers basic info for making sure the user exists (name, branch, office, etc.)
IT says "Thanks, we'll get right back to you" and hangs up
IT calls back the user on the desk-number / cell-number listed for them in the corporate directory. (odds are if the attack has pwned these already, there's a much bigger problem...)
User picks up, IT vocally confirms their password request, and if it is confirmed, gives the one-time-password. If it is not confirmed, IT forwards the event to our security team.

This way, the IT desk has a much lower chance of being socially engineered into giving passwords orally to someone over the phone, even if they have all of the victims corporate info (barring physical access to their phone).


Hardware security tokens as mentioned can provide some security against piracy.

Not knowing what your software is, or what it does, it's hard to know what solutions could work.  Are you putting the box on-site because it is more efficient?  Are you putting the box on site so that the customer can administer it themselves?  Is it because the customer is running it on an isolated network?

Many enterprise grade solutions use strict license agreements and cryptographicaly secure software keys with the name of the purchasing enterprise and the date of expiry clearly in them.  It means that even employees who steal code only have limited use of it as the origin and time limits on its usage are clear.

But all this does little to nothing to protect against reverse-engineering.

Code obfuscators and obfuscating compilers might help you a bit.  Again, it depends on your application, your application team, etc.

Physical tamper-resistance might also help, but it limits your ability to support the physical hardware.  The payment card industry uses wire mesh inside some of their hardware with keys stored in volatile memory so that if the case is tampered with, important decryption keys are lost, rendering the device useless.  Similar techniques are applied to HSMs (Hardware Security Modules), which are effectively tamper-resistant vaults for storing important crypto-keys.

The whole game is risk management.  The expense of launching a lawsuit, the damage caused by a leak, the cost of securing the code, it all has to be weighed.  Few secrets are so important that they need to be protected at all costs.  The delay to market may cost you your time advantage, allowing a competitor to reach a comparable solution at a better price before you can get your locked down version out the door.


Are pwgen's default passwords "good enough" for online accounts and encryption?

It's somewhat hard to quantify what is a 'real security risk'.  A password created with pwgen defaults (all lowercase letters, 8 in length) stored using a fast hash (MD5 or SHA1) could be offline brute-force cracked with a single modern GPU in anywhere from a few minutes (just trying lowercase) up to around 9 days against all characters (trying lowercase, uppercase, numbers, symbols).  If this same password is stored using a stronger hashing algorithm (scrypt, bcrypt, argon2, etc.) then it might be cracked using a brute-force against only lowercase letters but probably not by a full brute force against all characters (because it would take too long).

Your password manager and disk encryption should be using these slower hashing algorithms for key derivation.  With online accounts you often don't know what type of hashing they implemented so the safe bet is to assume fast hashes.

By my estimates, moving to a minimum password length of 11 characters for slow hashes and a minimum of 14 characters for fast hashes should help offset the weakness of using passwords constructed with only lowercase characters.  You can quickly increase strength by adding more length as your memory (or password policies) allow.

I will caution that these estimates assume attackers must use brute-force attacks (even if against a restricted selection of characters, like lowercase) to guess your password.  My understanding of pwgen is that, by default, it doesn't randomly create the passwords and instead attempts to structure them in a more memory friendly arrangement of consonants and vowels.  This probably causes a significant reduction in the number of possible passwords out of the total pool of lowercase random passwords.

So theoretically an attacker could identify only the possible passwords generated by pwgen and target those in their password cracking attempts to save time.  If this pool of pwgen passwords is 15% of the total lowercase possibilities (I have no idea what it actually is) then 11 characters would probably not be a sufficient minimum length.  You'd need to go with a 12 characters minimum, adding more characters to satisfy your particular paranoia and future-proofing preferences.


Is it possible to retrieve data from a intermediate node in Tor browser

Is my internet services provider able to see the websites I visited

No. Your Internet service provider can not see which website you visit (I suppose you use Tor correctly without your personal settings/configurations you may have done. Tor will take care of your DNS leaks and so on)

  Is it possible to retrieve a login information like username and password of my email account from intermediate node between Tor
  browser and web server

First of all, using your credentials to log into this or that website breaks, by time, the anonymity Tor provides you. Also, an attacker may eavesdrop the exit nodes where Tor does not control the traffic.

  Is it possible to retrieve email content like mail body and attachments from intermediate node

Once again, using your credentials through Tor breaks your anonymity. Tor intermediate nodes are too hard theoretically to break (of course, there are buts). Real life eavesdropping that targeted Tor users has been done on exit nodes such as when this Swedish researcher compromised username/passwords of lot of Tor users (in which case, of course, your attachments and so on are also compromised)


Safe ways to store passwords without hashing them

If you're talking about a Windows desktop application, you should use the CryptProtectData API, which stores the credentials in protected memory regions and encrypts them with a key that is part of the user profile. This is the standard protection mechanism for Windows applications.

On Linux you could look into using the GNOME keyring or KDE wallet, and OS X has a set of APIs for its keyring too. This would ensure that the security settings for the user's keyring take overriding control - they can decide how often they want to have to re-enter their master key.

Any procedure you choose to obfuscate passwords is an exercise in futility against any half-determined attacker, so at most you're creating an illusion of security. My suggestion is to include a setting that says "remember my password", but warn your users that the password will be stored locally in a reversible format that offers little security, so that they're aware of the issue.


What if an attacker gets access to public key through an insecure media in digital signature?

Signature and encryption are entirely separate things although they use similar technologies to accomplish their goals.

Signature is used to verify the identity of sender. If attacker has access to A's private key, he could create fake messages that appear to originate from A.

Encryption is used to scramble a message so that only receiver can read it. Typically the sender A would use the public key of the receiver B to encrypt a message, not the other way around as your question suggests. The message is encrypted using the public key of B, and decrypted using the private key which only B has access to.

This way both encryption and signing can be safely accomplished even if attacker has both A's and B's public keys. They are called public keys because they can be safely given out, shared and published, and only private keys need to be protected.

Your question implies public and private keys are used incorrectly (wrong "direction), which might be possible in some weird system, but it wouldn't be secure, and the attacker would indeed be able to read the messages.

Done properly, the sender A would sign the message using his own private key, and encrypt the message using B's public key. Receiver B would then verify the identity of the sender using A's public key, and decrypt the message using his own private key.


What would cause a port scan to an email server in an office?

The CSF log message you provided states that it found "21 hits in the last 261 seconds."  So the question is, what was hitting?  The CSF configuration file describes their port scan detector as follows:

###############################################################################
# SECTION:Port Scan Tracking
###############################################################################
# Port Scan Tracking. This feature tracks port blocks logged by iptables to
# syslog. If an IP address generates a port block that is logged more than
# PS_LIMIT within PS_INTERVAL seconds, the IP address will be blocked.
...
# This feature blocks all iptables blocks from the iptables logs, including
# repeated attempts to one port or SYN flood blocks, etc

So, your iptables configuration is blocking individual connections from your customers, and CSF watches the iptables logs and reacts when it sees too many individual block log entries.  Since it is using your iptables logs as its raw data point, the same raw data must be there for you to review.

So what you need to do is review your iptables logs for the time period in question and see what port they were reaching for that was being blocked.  If it was 465/tcp or 587/tcp, for example, that might indicate their mail client is trying secure alternate ports first before going to 25/tcp for SMTP.  That implies a sort of legitimate false positive, and you might compensate by configuring iptables to block without logging on those two ports.

If, on the other hand, they're trying a broad array of ports which aren't mail related, (21/tcp, 22/tcp, 23/tcp, 139/tcp, 161/udp, 445/tcp, ...) then someone or something there is truly portscanning you.

Based on the comment below, your logs state that connections on port 585 are triggering the blocks.  Port 585/tcp is associated with Apple email clients.  You could ask the user to fix their email client, but since it's an Apple client, all the online mentions of this say it's hard to figure out how to do that.  So you can instead adjust your firewall rules to not log this traffic.  If you look at your IPtables INPUT chain, you'll see the last two lines are probably LOG and DROP:

# iptables -L INPUT -n --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination
...
20   LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
21   DROP       all  --  0.0.0.0/0            0.0.0.0/0

You can then INSERT a new and specific DROP rule at the location of the current LOG rule:

# iptables -I INPUT 20 -p tcp --dport 585 -j DROP
# iptables -L -n --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination
...
20   DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:585
21   LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
22   DROP       all  --  0.0.0.0/0            0.0.0.0/0

and now the port 585 connections will DROP before they would be LOGged, and your CSF tool will no longer react to these connection attempts (but they will still be blocked!).


Is using separate stacks for return addresses and function arguments a viable security measure?

The problem with most operating systems is that they follow a specific "calling convention." This convention requires putting function parameters on the stack, being some derivative of the C-style calling convention. You must use this convention for ABI (Application Binary Interface) compatibility with that OS. So, without OS support, you could only use this feature for calls made within your application.

This would complicate compilers quite a bit and probably require a fair amount of work. In short, you could protect your own programs if you had a compiler that supported this calling convention, but you'd still be at the mercy of the OS whenever you had to do things like reading/writing a file, etc. A buffer overrun in a DLL, for example, can't be fixed by you changing your calling convention.

Secondly, until recently, with the advent of virtualization, it really wasn't feasible to set up a separate area like this, because segmentation was expensive, and memory virtualization even more so. Today, this would practically be a non-issue, but since we have to deal with historical software (e.g. stuff written ten years ago that still require the conventional calling methods), the OS would then be forced to support both models for some indefinite period of time.

If a new OS with no compatibility concerns were written, it could certainly do this, but it probably won't happen, because there are more viable methods. Microsoft's own Singularity OS is completely immune to buffer overruns (according to them), because the OS statically validates that each program cannot possibly misbehave. Interestingly, this OS uses no "memory protection" as used by Windows, Linux, Mac OS, etc. The programs are validated for correct behavior before they run, not as they run. Of course, if a virus were capable for this system, it would have unlimited system control because of the lack of protection at the hardware level.

In short, even without any serious research on the topic, it's clearly possible that this approach would work, but outside of FOSS (Free and Open Source Software), it wouldn't be possible for this approach to work from a financial standpoint. Linux could be re-written from the kernel up to support the new model, a compiler rolled out for it, and then all the software out there could be re-compiled without too much effort (note: "too much" being relative to, say, Microsoft).

Microsoft, Apple, and so on do not have this benefit, because the code is already compiled by millions of different developers, so anything that couldn't be updated would be instantly obsolete, or they'd have to write emulators to support the old software. Basically, until someone comes up with an OS that has this feature built-in, with compatible compilers (at minimum C and C++, plus probably Cocoa and Win32 C++), and it gains enough support to become a contender against Linux, Microsoft, and Mac OS, it'd be pretty hard to justify moving to a new model. Linux would be the easiest to move over, although all software would have to be compiled until RPMs and other package types supported the new calling model.

Finally, DEP (Data Execution Prevention) pretty much solves the problem in most cases, making it harder to execute code that shouldn't. This also reduces the need to switch to a new model, although, as Singularity demonstrates, hardware could be a lot faster if it wasn't constantly forced to protect against programmers' bugs and the exploits they present.


S/MIME certificate expired and renewed, do my correspondents have to do anything?

Theory is that everything works automatically. Practice sometimes differs.

I suppose that you are talking about S/MIME and X.509 certificates. With S/MIME, when you send an email:

The email is encrypted with the public key of the recipient, so you have to know the current recipient's certificate.
The email is signed with your private key and the signature format normally includes a copy of your own certificate.

Thus, other people learn your current certificate when you send signed emails to them. Once they received such an email, they can send encrypted emails to you. If these people also signs their own emails, then you learn their certificates as well, and you will thereafter be able to send encrypted emails to them.

When you get your new certificate, your correspondents don't know it yet; they just know the previous one. When your old certificate expires, they will cease to be able to send encrypted emails to you. But, as soon as you send them a signed email, they will learn your new certificate and everything will be fine again. Storage of copies of the certificates of other people is supposed to be done automatically by your emailing software, so there is never some manual import to do. At least when everything works fine.

If you want people to be able to send you encrypted emails without first receiving a signed email from you, then you can put a copy of your certificate (not your private key, of course) on your personal Web site, Facebook profile, or anything similar.

(In the dreams of the original X.509 designers, certificates for everybody would be found at any time in a worldwide, shared directory called the Directory, with an uppercase D. This is why the main identity in an X.509 certificate is a Distinguished Name: this is a hierarchical path within the Directory. But this never happened: the Directory remained a purely theoretical beast.)


Should Flash be disabled, or are sandboxes secure enough?

Obviously, this method is safer.

Surely. Running a program within the browser's sandbox is always safer because the browser creates a contained environment for the third party program (Adobe Flash, in your case) -such as scratch space-to prevent  the eventual malicious code from leaving the browser and installing itself to your hard drive.  You can think of running an untrusted third party application within the browser's sandbox, at a certain degree, as running a program within a virtual machine instead of running in your host machine's operating system.

An other advantage of Chrome sandboxing Adobe Flash programs is that:

  However, Adobe recommends that non-developer Chrome users use Flash
  Player integrated with their browser. Using manually installed
  versions of Flash Player, by following the steps below, means that
  users no longer benefit from the automatic Flash Player updates that
  Chrome provides.

It means the recommended way of running Adobe Flash makes the user benefiting automatically from security updates (as not all users are prone to do that manually, and thus exposing them to threats)

  than running Flash as a plugin in either Firefox or IE

Recently, Mozilla added a feature in Firefox that enables the user to sandbox any program (including Adobe Flash) you want individually -this is may be an advantage for Firefox as it allows to sandbox Java applets unlike Chrome-

As I am not using IE you mentioned, I am not sure whether it sandboxes Adobe Flash programs or not yet. But I think so as I landed on this article (Adobe sets IE as next target in Flash security work) written three years ago.

  But isn't it possible to find a zero day vulnerability in Flash and a
  way to break out of the sandbox as well?

You are right. Sandboxing mechanisms are not that perfect. Whether the sandbox is related to Flash or any other third party programs, it is common for attackers to break the security constraints of the sandbox.

Speaking about Flash and Chrome, just last month there has been a real world example where the Flash sandbox in Chrome has been escaped (Hacking Team’s Flash 0-day: Potent enough to infect actual Chrome user). But as I said, not only Flash sandboxes can be escaped: I can mention to you randomly (CVE-2015-0016, escaping from IE sandbox) and you can find so many at your will there for different browsers.

  Isn't disabling the Flash plugin altogether the best option?

If you are talking only about Flash player plugin, then you are right. It is no longer recommended (Facebook calls for end to Flash as Firefox blocks it over hacking holes). HTML5 is the recommended technology instead (Comparison of HTML5 and Flash)


Instead of using self-signed certificates for internal sites, I suggest you set up an internal CA and use it to sign certificate requests. You can import your CA's certificate into each browser used internally (either manually or via automated deployment mechanisms) and this should be as good security-wise as using certificates issued by a major CA -- as long as you take proper measures to secure the system used for signing certificate requests.

This is a much better solution than self-signed certificates and, depending on your environment, your domain controller may already offer CA services (MS Active Directory, FreeIPA, etc).


I think you have either over-complicated the issue in your head (common practice for us developers) or you have a design flaw in your system. Could be both.

Your question states:

  How do I prevent users from using my iOS apps unless they have been authenticated on a server?

The answer to which is: don't allow the app to start until a user has logged in. When you start the app, start it straight to a login screen. But, it appears you already have that in place:

  When a user launches an app they must log in before they can use the app

So, really your question appears to be:

  how I can restrict use of the application...?

Your user accounts need to have roles. At minimum, a free and premium user role.

Upon successful authentication, the user should obtain a token, which gives them use of the app. For the purposes of this discussion, I'll say "unrestricted access to the app" to avoid the complexities of unlocking only this feature or that feature, which is completely possible depending on your architecture.

The token should not only give access to use the app, but also have an expiration option, but that's up to you. (If a free user is perpetually free, and a premium user is a one-time-fee yields a perpetual license, then expirations are not necessary).

Once the user logs in for the first time, your user authentication server will issue a token based on their role and status. If they are a free user, they will receive this token, which gives them unfettered access to the app. If they are a premium user, then the server will withhold the token unless the premium has been paid.

Although the implementation method is a little out of scope for security.stackexchange.com, I'll do a simplified version here because I think its part of the underpinnings of your original question.

The complication comes at this question: how do your premium users pay to unlock the app? You can't have a free and a paid app because everyone would just download the free one and never pay.

You're only left with the option of a single app and altering the user role based on a paid (or even subscription) status.

Since you've posted this in iOS, I'll reference In-App purchases. The app should be free by default with in-app purchase options. When a free user downloads the app, they can request their free account (or, if they belong to a given group that has a coupon code, etc... they need the option of entering that, which will change their role on your server to a free user role).

Otherwise, you can leverage the in-app payments to upgrade the account to a premium / unlocked version.

This being said, having an app be "free" and then immediately require an unlock code or an in-app purchase will be a "high friction" implementation.

If you decided to go with a free and paid version in the app store. The free version would simply require a coupon code to activate the free subscription. Or, in the alternative, it would have to wait for your staff to approve the new user. (Lots of work for a free app).

The paid version would work right after the download. Here, you're restricting the "high friction" implementation to users who are getting free stuff anyway. Paid users have a smooth as butter transaction.

  The authentication takes place on a server and is already sorted

If your authentication server does not support roles, then this isn't sorted, which may be a design flaw that needs to be revisited. Especially considering that if you don't currently have user roles, you certainly would need to have code that either queries Apple's API for subscription status, or have code that receives an event when a subsciption / fee has been paid to change a user's role.


How reliable is Virustotal's file signature check?

Does it mean, that the file is 100% the original file from the developer company and there is no way to tamper with it in any way, without breaking the file signature?

That means with practically 100% that the file is signed with the companies key, i.e. the cryptography behind a digital signature itself is fine. But that does not mean that it can be fully trusted.

Since such a key might have been stolen this does not mean that it was actually signed by the company. Also, the company name in the certificate does not necessary is the company you assume it is since it is possible to register the same or similar sounding company somewhere in the world and get a code signing certificate for it. In general you cannot simply assume that the certificate was issued for a legitimate and trustable company just because the issuer is a well known CA - misuse of trusted code signing certificates is actually common. And apart from getting certificates for fake certificates or compromising the original certificates the attacker might also have compromised the companies infrastructure and introduced a backdoor into the code which as part of the shipped program is also included in the code signature.


Should a refresh token be linked to a single access token, and what is the ideal refresh flow?

Refresh tokens cannot be tied to access tokens if the access tokens expire "cleanly" (that is, leaving no trace), or else the whole point of the refresh token - obtaining a new access token to refresh the session when the old token expires - won't work. If the access token will stick around even after expiry, you can tie it to the refresh token, but in general this doesn't add much security. How do you propose an attacker steal somebody's refresh token without also being in a position to steal their access token?
The new access token is generated the same way the original one was. E.g. If you're using JWTs, you mint a new JWT and sign it. If you're rotating refresh tokens after use, you generate a new one (hopefully via HSM or cryptographically-secure PRNG) and return that too.
Session data stored alongside a token is usually used for things like showing the user a list of their active sessions, and detecting fraud. You can do things like allow refresh with a change of IP within a country, but require re-authentication after crossing a border or traveling far, by looking up the IP.
A refresh token of random bytes is not only sufficient, it is the usual option. JWTs are poor choices of refresh token; they are overly large if all you need to prove is "this was given to the user at some point", and their primary advantage - no server state - isn't feasible for refresh tokens (they need to be long-lived, which means you need a way to revoke them, which means you need to store state on the server).

One thought: if you're concerned about somebody gaining read (but not write) access to your auth DB and retrieving refresh tokens from there to then use against unsuspecting users, the easiest solution is to run them through a fast secure hash function. Taking 16 bytes from /dev/urandom, and then both returning those bytes to the user as the refresh token and running them through SHA-256 before purging them from the server, will produce a hash value that can be stored in your database, compared against extremely quickly, and reveals absolutely nothing about the actual refresh token value. It's sort of like password hashing, except you don't need a slow hash because the entropy of the actual refresh token is higher than almost any human-generated password.


How to handle as a Tester if the website is kicking out the user for recreating the session?

Burp has session handling functionality that allows you to make a request to check if your session is valid, and if it has expired then it will login again. You can find it in the Project Options > Sessions tab.
Official documentation is here: https://portswigger.net/support/configuring-burp-suites-session-handling-rules


Yes, its added by this code: https://github.com/zaproxy/zaproxy/blob/develop/zap/src/main/java/org/parosproxy/paros/core/scanner/VariantAbstractQuery.java#L148-L153

This is added to see how webapps react to queries - if they handle them badly then yes this can introduce vulnerabilities.

If you think ZAP has reported false positives then please report them too us: https://github.com/zaproxy/zaproxy/issues/new?labels=bug&template=Bug_report.md

Note: As of ZAP 2.8 the addition of parameters to requests that didn't originally have them is now optional (and default off). Ref: https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsAscaninput#add-url-query-parameter


How private is RAM from other users on a VPS?

tl;dr: Virtual machine RAM is reasonably private, given your stated assumptions.

I'm not an expert on virtual machine security (real experts, please come correct any errors in this post), but I found this question interesting enough to do some Googling. Here's what I found.

From a NIST publication titled Security Recommendations for
Hypervisor Deployment:

  One of the common threats in virtualization platforms is a malicious
  VM accessing areas of memory belonging to other VMs. This is called a
  VM Escape attack. Processors with virtualization extensions provide
  safety against this through features such as Direct Memory Access
  (DMA) remapping limiting DMA access to what is valid for the VM (i.e.,
  preventing a VM from performing DMA beyond its allocated area).

This paragraph is saying that hardware-accelerated virtualization (which is pretty much all virtualization you will encounter in 2015) can enforce memory access restrictions pretty well--at least better than software-only virtualization.

The NIST paper goes on to suggest the following:

  Security Recommendation HY-SR-6: The ratio of the combined configured
  memory of all VMs to the RAM memory of the virtualized host should not
  be very high. A typical ratio adopted is 1.5 : 1. In other words if a
  virtualized host has 64GB of RAM, then the combined configured memory
  of all VMs running on it should not exceed 96 GB.

  Security Recommendation HY-SR-7: The hypervisor should have
  configuration options available to specify a guaranteed physical RAM
  for every VM (that requires it) along with a limit to this valu, and
  to specify a priority value for obtaining the required RAM resource in
  situations of contention among multiple VMs.

Popular virtual hosts, like EC2 and DigitalOcean, are likely to follow these guidelines for security and performance reasons. Their VMs would run rather slowly if they oversold the RAM. However, for a less popular VM host, I would not know if they followed the guidelines or not. Depending on the workloads of the guests, the host might find it profitable to oversell.

Now remember that the host can definitely store the state of your RAM, and any sort of vulnerability that allows arbitrary  code execution on the host can result in the reading of arbitrary VM RAM contents.

The NIST paper also suggests a vulnerability where the images used to create virtual machines are compromised, causing VM users to spin up instances that are already compromised. Amazon and DigitalOcean are likely to follow the NIST recommendations here as well--that VM images must have valid digital signatures and that the images for new instances cannot be modified from a machine running existing instances. Once again, a cloud hypervisor run out of some college dorm room might not have equivalent security on the images.

The whole NIST paper is worth reading--it is not very long--and so are the following Stack Exchange questions:

Memory Dumping - Cause for concern in Virtualization?
Does a Virtual Machine stop malware from doing harm?
Can a virtual machine (VM) “hack” another VM running on the same physical machine?
How secure are virtual machines really? False sense of security?
Are there ways to protect the guest kernels at the hypervisor level?


Does order of Rules matter ?

Of course. It's mostly about performance.

Even if your firewall only implements an accept/deny policy (it could, for instance, decide to route the request elsewhere) then the length of time it will take to decide what to do with it will depend on the number of rules it has to process in order to reach a decision and the effort required for resolving those questions. Hence ordering has a huge impact on performance.

Further, most such firewalls benefit from fuzzy rules - a single rule (or even a single web request in session) may not carry enough information to determine whether a request should be processed or not - the firewall therefore maintains a lot more state than a layer 5 stateful firewall.

  How inconsistent rules are handle.

No idea what you mean by this.

  How redundancy is removed from the ruleset

By design.

  Can rules be bypassed for static application layer signatures

Yes, if you configure the rules to allow this.


Preventing Server-Side Request Forgeries in Java

This is the code I'm currently using:

if(!url.getProtocol().startsWith("http"))
    throw new Exception();
InetAddress inetAddress = InetAddress.getByName(url.getHost());
if(inetAddress.isAnyLocalAddress() || inetAddress.isLoopbackAddress() || inetAddress.isLinkLocalAddress())
    throw new Exception();
HttpURLConnection conn = (HttpURLConnection)(url.openConnection());
conn.setInstanceFollowRedirects(false);
conn.connect();
IOUtils.copy(conn.getInputStream(), out);

It enforces HTTP or HTTPS, forbids local addresses, and disables redirects. However, it still has the TOCTOU (time of check, time of use) flaw.


Nuke It From Orbit - Your computer has been compromised, and even running an anti-virus program will not guarantee a clean computer. One of the first things most pieces of malware will do is install a backdoor into your system to ensure it can get back in once your computer thinks it's clean and re-execute itself.

Installing windows from scratch is the only way to reasonably ensure your computer is no longer infected.


Understanding the philosophy of recovering data

As you said you were not interested in technical detail, I will give a rough, top level approach to answer your question.

First off, flash drives have a built-in process called wear leveling where the controller does select the sectors that will be written to level the wear on all available sectors (which are more than those offered to you to be written to, usually). Thus, when you randomize all sectors available to you, there might be still "old" data in the sectors currently not on wear leveling duty.

Apart from that, there are minor differences in between memory sections that contained a 0 before an 1 and one that did contain a 1 before another 1. (technicalities differ between magnetic disks flash devices) and thus, assuming you have written random data and the data written before wasn't random (i.e. has intrinsic structure), you can statistically remove the noise from the random data and have some good guesses as to what was written before the random data.

That is the reason, multiple rewrites with randomness are considered more secure than one single go. Yet, the capabilities to make out those minor differences mentioned before are sparse and usually consider a state actor of some kind being the attacker in your threat model.


Employer makes me use what I believe to be an insecure website for HR functions. What to do?

To start with the easy bit: you do not have to put real information as the answers to the questions. Random strings work best if you are really paranoid and store them in a password manager just like a password.

The rest (no brute force protection, potentially outdated software) is a shame, but there is nothing that you can do, from a security perspective. I would raise the issue with HR/Payroll and ask them to investigate. If you are in Europe, then you can also talk to your DPO to suggest that their "Data Processor" has troubling account security practices that need to be investigated.

Otherwise, this is more of an internal office politics issue.


Could the thief who stole my phone access my pics?

First of all, resetting the phone will wipe its internal storage (though not the SD card, by default) and is probably the best you can hope for. Use Google's "Find my phone" (https://myaccount.google.com/intro/find-your-phone) to check where the phone is (you might have just misplaced it) and, if it's stolen, remotely wipe all the data. If that doesn't work (for example, because it's off), you can still make it useless for anybody else: contact your mobile operator (the company that you pay for cellular service, such as Verizon or T-Mobile) and report the phone stolen (you can usually do this online).

If the photos (or anything else you care about) are stored on the SD card (usually the user can set it up that way or not, as they choose) and the SD card isn't encrypted (it's usually not, unless the user specifically sets that up), then the thief doesn't need to do anything but remove the card and put it in a computer.

If the password is short (for example, a 4-digit number) and not protected by a policy that wipes the phone after some number of failed attempts, the thief can quite possibly brute-force the code. Android's default lock out is only 30 seconds after five failed attempts, and it doesn't increase, so brute-forcing a short password is possible.

If storage encryption is not enabled, the thief can extract data from the internal storage without needing the password or resetting the device at all. However, this is an advanced attack that is unlikely to be attempted against a random person.


Would it be safe to connect to a shadowsocks server using rc4-md5 encryption?

Would the server intercept my data because the encryption is deemed unsafe?

I'm assuming that you mean with "server" the system where your shadowsocks proxy is running on. While RC4 is considered a broken algorithm it still takes a considerable amount of computing power and thus lots of money to actually break it in practice. Thus it is highly unlikely that somebody will take this route unless you are a very valuable target to hack (i.e. cost of attack vs. gain).

And even if you are a very valuable target it might just be easier and cheaper to capture the traffic leaving your proxy to the final target system which is no longer "protected" by RC4-MD5. Or if the attacker gets access to your system he can replace the shadowsocks binary with some other binary which seems to do the same but additionally forwards the decrypted traffic to some third party.

In summary: don't worry about RC4-MD5 in this case because there are probably far easier  attacks against your setup.


Does brute-force time depend on the length of a password only?

Length is certainly a factor, but you've hit on an underlying fact that most people miss: even a 30 char password is weak if it is guessable.
The concept that is important is "entropy". It's not just length or even the types of characters used, but how the password is chosen. The randomness, the character types used, and the length all contribute to password strength.
But if everyone uses the password: Look at me!! I'm a really long password!! (that's 41 characters), then it's not really strong, is it?
You've asked about brute-forcing, and there are different types. Trying every password length, character by character starting from abcd... is a sure way to eventually get the password, but it might take billions of years. But that's not the only type.
Dictionaries are used, common patterns are tried, known passwords are checked.
So, yes, if a 30-char password with dictionary words is used, and those words are randomly chosen, then that's a strong password.
!@#$#%$^%$ will be guessed relatively quickly because that's a common keyboard pattern.


On the wireless routers I'm familiar with, there is an admin page that lists the MAC addresses of devices that are connected. Take this with a grain of salt: a malicious user could easily change the MAC address (to either look like one of your devices, or so that it appears to be a completely different device each time he connects).


If you hash the keys, it would not be possible to show the keys to the user ever again. Hashing can not be reversed. You can only check if a given key is linked to the user.
What is oftenly done for APIs is to create a key consisting of a public and private/secret part. The public part can then be stored in your DB, whilst the secret part follows your current flow of storing/hashing. You can then list the public keys for the user (which he can then delete if lost).
Upon authentication the user would need to provide both parts which you can check in your DB. Another option would be to request a temporary token with the public/private keypair, this token can then be used for further API calls. Note that the token should have a limited lifetime and of course must be unique among all users.


keeping user names as login info is vulnerablilty in a website

There is a difference between a 'weakness' and a vulnerability. Usernames are not intended to be secret, so once a username is known, then it is subject to bruteforcing. This is a weakness with the entire username/password model and every website that uses it adopts this weakness.

There are ways to mitigate this weakness, like Two-Factor Authentication (2FA), but the weakness of the model is still inherent.

The problem is that there is no viable alternative that will work for the entire world. Sure, you could issue client certificates, but that is not easy to administer.


Progress in market approaches to software vulnerability disclosure?

Of these market types, the first two can benefit individual security researchers, but must be initiated by the vendor. Therefore, only vulnerability information regarding vendors participating in such a solution would be valuable under such a mechanism. Depending on the level of participation, this could deeply hamper a security researcher. Vulnerability brokers and cyber-insurance don’t have an immediate incentive for the individual researcher. It
would be difficult to leverage a found vulnerability into income under these two systems.

Due to the secretive nature of the market at the present time, it is difficult for them to find a buyer, determine a price for the information, prove the value of the vulnerability, and exchange the goods for money. On top of this, at any point in this process, the vulnerability may be announced by someone else, making the discovery worthless.
Some solutions exist which help to alleviate some of these problems, however their actual implementation remains far off in the future.

Take a look at this paper: http://securityevaluators.com/files/slides/cmiller_auscert2008.pdf


The program used to calculate it is public: https://pgp.cs.uu.nl/wotsap/

As is the archive data it uses, updated as of... today https://pgp.cs.uu.nl/archive/wot-0.3/


Securing mail deliveries in a multi-tenant office building

Make sure the postman buzzes your offices, and have a procedure to immediately go collect your mail.
Figure out when the postman delivers (it's probably about the same time every day) and schedule someone to go down at that time.
Arrange for your mail to be held at the post office, not delivered, and send someone to collect it every day.


Is there a base version of jQuery which has no XSS vulnerability?

To get away from the reported issues, (which will show up via projects like retire JS), you'll need to use a JQuery version in the 3.x line. At least one of the commonly referenced issues (this one) required breaking changes and as such was never fixed in the 1.X stream.

The current latest version is 3.2.1 and I'm not aware of it having any disclosed XSS issues.


XSS doesn't run on the attacker's computer; it runs on the target's.  Thus, the fact that public internet attackers cannot access the internal site where the attack happens is irrelevant.

As an example, imagine this scenario:

Attacker adds XSS into the database via publicserver.com.
Company employee visits vulnerable page on privateserver.lan.
Employee is hit by XSS attack.

This attack could grab sensitive cookie information and send it to the attacker's external server.  Or maybe it queries a number of local IPs looking for vulnerable servers, then sends that information out to the attacker (who makes use of that to update the XSS to attack those servers).  There are any number of attacks that can happen, and merely being inside the local network while the attack happens doesn't protect you very much.

This is one of the reasons you might consider configuring egress rules into your firewall, rather than only blocking incoming traffic.

This is a very valid vulnerability.


What is required to store for recognizing the machine securely?

I assume you meant reasonably uniquely and reliably - in which case, this is a hard problem. Made harder by the fact that any web application does not have access to the underlying hardware - just transient information such as browser version and IP address. Yes - you can get a lot of information about a system, e.g. as panopticlick does, but that information is changeable on demand.

Moreover, any of these metrics can change. Using CPUID? What happens if the end-user upgrades their processor? Your "trusted device" status disappears. That might be acceptable, or it might not - think Windows Activation.

In any case, in order to protect against token interception, MITM, replay and all other nasties of this sort, you absolutely must use SSL for this channel which brings me to:

  He will still have to log in using password + username, however, he can ONLY log in from given machine.

This sounds like a use case for SSL client certificates, in my mind. The usual logic looks like this:

Ask the browser for a client certificate.
If you get one, check that cert, find the user DB etc and log the user in.
Otherwise display the user login page.

I think what you're asking for, however, is a variation, in which if you find the certificate you present a login form and otherwise you display a 403.

That deals with the authentication side of things quite nicely. It also alleviates the need to store unique machine IDs and all the problems of generating them - although you could do so alongside this if you wished - and allows the user to designate trusted devices just by installing the certificate.

  Can I safely store an encryption key (private) on the machine, so the user, doesn't need to input it when uploading data etc.?

Well, you've never got any guarantee of client side security on the web. You simply have to trust users are looking after their credentials.

The same goes for cookies. Remember, users may do all sorts of things to cookies, including clean them up unexpectedly. If you're building a web app and intend to do client-side crypto in JS, and you lose that key, the user is going to lose their data.

The alternatives are:

Encrypt the data on the server. As you've probably guessed, this means anyone with access to the server can get at that data - and no protection you put in place will help.
Encrypt the data on the client outside the browser, where storage is more reliable. When I say "outside the browser", I mean via a mechanism with proper persistent storage that is not cookies.
Wait for homomorphic encryption.
Design a way of extracting the key from the cookie and ensure your users can re-input it again as necessary.

Generally speaking, the standard advice for cookies (this includes your session cookies) over https is to use secure and httponly flags so that XSS does not work and the cookie does not leak.


Is Google identity sign in product HIPAA compliant?

HIPAA compliance is a bit tricky because it relies on the ambiguous 'industry standard.'

In this particular case, I believe that you need an https:// sign-in service.  HIPAA compliance is typically satisfied by judicious use of cryptography and other standard security measures.


SQL injection attack prevention by frequently changing table names?

Changing the table name periodically will make SQL injection a bit harder (you can no longer blindly register a username of Robert'); DROP TABLE Students;-- to cause havoc).  However, there are SQL injection techniques for figuring out table names, which can bypass your defenses.

The correct way to prevent SQL injection is to use parameterized queries.  This completely stops injection, and is far less complicated than re-writing your queries every time you change your table names.


Or can we do away with SIEM and have only Network Forensic tools installed in a enterprise network.

Sure, you can probably get away with forensic tools installed in an enterprise network. However, said tools are probably scattered all over the network.

For convenience sake, you will probably want to aggregate all the data and logs generated by the tools in one location. You will probably want to create a nice dashboard for glance-able information because who likes looking at logs?

You probably also don't want to hire a guy to stare at the logs all day in case something goes wrong. You probably want a way to alert your administrators in case something goes wrong....

At this point, you are basically rolling your own SIEM anyway so you might as well use one that has already been written and battle-tested.


Should encryption key be stored remotely?

Keeping the key on the device is your best option if you have a secure place to put it. Network transport provides a much larger attack surface, even if you use TLS to transfer the key.
The usual problem is that with physical access you can easily dump the key by dumping firmware. Many embedded systems handle this with a secure key storage peripheral, either using an on-chip feature like ARM TrustZone, or an off-chip device such as Microchip's CryptoAuthentication ICs. This then acts as an oracle that can perform operations using that key (with certain defined restrictions) without ever revealing it.
Implementing this safely in practice is extremely difficult, though. It is often possible to break a lot of on-chip security features either through misconfiguration, bugs, or glitching attacks on the ICs themselves.


Ambiguous OCSP response acceptance requirements

The OCSP response does not necessarily have to be signed by the same entity which signed the original certificate, as this responsibility can be delegated explicitly.

This is discussed in section 4.2.2.2 of RFC 2560:

  4.2.2.2  Authorized Responders

  The key that signs a certificate's status information need not be the
     same key that signed the certificate. It is necessary however to
     ensure that the entity signing this information is authorized to do
     so.  Therefore, a certificate's issuer MUST either sign the OCSP
     responses itself or it MUST explicitly designate this authority to
     another entity.  OCSP signing delegation SHALL be designated by the
     inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
     extension included in the OCSP response signer's certificate.  This
     certificate MUST be issued directly by the CA that issued the
     certificate in question.

  Systems or applications that rely on OCSP responses MUST be capable
     of detecting and enforcing use of the id-ad-ocspSigning value as
     described above. They MAY provide a means of locally configuring one
     or more OCSP signing authorities, and specifying the set of CAs for
     which each signing authority is trusted. They MUST reject the
     response if the certificate required to validate the signature on the
     response fails to meet at least one of the following criteria:

  Matches a local configuration of OCSP signing authority for the
  certificate in question; or
  Is the certificate of the CA that issued the certificate in
  question; or
  Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
  extension and is issued by the CA that issued the certificate in
  question.

In regard to this part of your question:

  I mean, isn't it enough to check if the response is signed by one of the trusted CAs in my computers?

It is critical that this is not the case, otherwise any compromised CA could falsify an OCSP response for any certificate, rather than just certificates issued by it (or delegated to it). This is not limited to public CAs; imagine the case where a company's internal CA (e.g. for use with their intranet) is compromised and used to falsify OCSP responses when users visit external websites, thus bypassing HPKP and other stapling.

Subsection 4.2.2.2.1 explains check 4; the OCSP responder must also be checked for revocation to avoid a revoked CA being able to falsify OCSP responses.


How to secure identity after someone dies?

Here's my off the top of my head common sense thoughts:

Assemble a list of accounts - email, social networking, bill paying, online shopping, etc.

Use the physical machines you have to do a search, check the history in any way you can, OS logs, browser history, bookmarks, correspondence in any email account you know about.

Contact the sites for any of these accounts to let the site know the person has passed away.  It seems like it wouldn't hurt to get a letter written up by the estate's attorney, if there is one, so that there's some premise of legality.

Start with online stores
Where it's social media, it seems like it would be nice to close the account, where possible with a record of the person's death and possibly contact info for sending condolences or other information - it's possible that a person's friend network may know other accounts that should be closed.  Also, letting contacts know that the person has died would help the contacts prevent any identity theft/spoofing attempts.
coordinate closure of any online accounts with laywers relating to the financial estate - there may be final bills that need paying.  You may need to hand over accounts of this nature to the beneficiary or the estate's trustee.
Save the email addresses for last, as you may get incoming communication that needs a response.  Also, it wouldn't surprise me to find out that you need the email account to close some of social network accounts.

Could also do a common sense search for the person's typical user names on Google to identify potential other places that the person is listed - which may or may not be connected to an account.  The biggest trick would be to be able to determine which user is truly the deceased, since the possibility for name redundancy is high.

All that assumes just an average every day user.  There may be other concerns depending upon the person's employment and/or family status.  For example, if the person works in engineering, there may be company private material on the person's PCs and you may need to work with the company to make sure this information is managed appropriately.  If the person is involved in any sort of court battles, do not pass go - do nothing and proceed directly to lawyer.


Good Practice to Secure Computer Terminal?

To encrypt the hard-drive, e.g. via BIOS (if it's known to be strong), via LUKS (default Redhat software disk encryption). It protects against stealing of harddrives.
For the terminal you could use Fedora instead of Centos as there's much newer GTK3 so if you are using GTK3 applications they will benefit a lot. There are also plenty of tools built-in which are newer and more usable on the terminal.
Keep the SELinux and Firewall enabled

If you plan to connect to this PC from outside world then the most usable way is to use X2GO over SSH and XFCE desktop. SSH is safer to be exposed than home router VPN, Centos VPN (any kind of) or anything else. You can limit brute-force on the SSH by using strong passwords or keys or iptables connection limit.


Is using a switch enough to hide MAC adresses of my devices from my ISP?

The router will know all of the MAC addresses since that is part of its purpose. If the ISP has remote access to the router then they will always be able to see that information in the ARP table.

Whether putting in an inner router will help is somewhat debatable - it should help but it may not be totally possible to guarantee that no data will leak.

Does it matter? What is more important is whether the ISP might listen in on any traffic, I can't imagine that it would profit them in anyway so the risk is probably pretty low. However, the possibility exists.

What might be a better option would be to put in a VPN terminating proxy. Such a device would act as a proxy channelling all of your data down a VPN tunnel and so no unencrypted traffic would be visible to the ISP. A decent router such as the Ubiquity EdgeRouter Lite would give you that capability.

Indeed, an inner router is not an uncommon architecture when using high-speed broadband (>8M, e.g. Fibre To The Cabinet) as the ISP often puts in a "modem", sometimes referred to as a "residential gateway". What this really is is a router with a phone connection upstream and Ethernet downstream. You connect your own (or the ISP's) router to the Ethernet connection and the router "dials" the address of the ISP to connect. The gateway is typically locked down and you can't see anything on it nor make any changes. In this case you can choose whether or not to use a VPN. If you don't, the ISP would be able to sniff your traffic and could work out that you have multiple machines but isn't likely to be able to be more specific.


Is it possible to keep several files on windows partition after re-installing windows?

Although windows can be installed on top of another copy, this is not required to break into it. A simple password removal tool, like "Offline NT Password and Registry editor" will do the job.

I'm not sure I understand what you mean by "security applications". Lojack for laptops? That can reinstall itself even if you format, on supported laptop models.


can I identify the origin computer for a program?

Source code consists in a bunch of text files. The contents of a text file are exactly what a text editor shows, so you can control that "visually". Beware of revision control systems such as CVS or Subversion: they can automatically replace some specific tags in source code (like "$Id$") with an identifying string which may contain the current date and time, your login name, and other information -- that feature is considered to be good for traceability, but I understand that you would not like it in your specific case.

Compiled code is quite something else. Some compilers may automatically added identifying strings like what revision control software does, as "comment" fields in the executable structure. This needs not even be a deliberate spying device: traceability is really a good idea in the general case; no need to imagine a government bribing compiler developers into adding such things in compilers just to be able to spy on programmers. Also, executable formats often include some "blanks" -- unused parts added for alignment reasons -- which the compiler might not have bothered with filling with zeros, instead of just writing what was in RAM at that place. This has occurred with an older version of lcc-win32, which was thus writing out random excerpts of the RAM contents which could contain confidential information (I think this has been fixed for lcc-win32, but it could happen with other toolsets).

Other file formats can also embed (and thus leak) some information. For instance, PNG images can include "comments" (which do not change the visual aspect of the picture in any way). GIMP, an image manipulation program, uses the comment field to state that it was involved in the image processing; any tool could also add some information which, in your view, would be less benign.

Many potential leaks can be detected visually, by looking at the files as if they were text. But this does not cover the possibility of one of your tools being voluntarily bugged so that it includes incriminating evidence in its output (such tracing information would be encrypted so as to "look random" except for whoever knows where to look).

Unfortunately for the state of the World at large, "a revolution in my country" is not a very precise indication. There currently are armed insurrections or similar unrest in quite a few countries just now, including, but not limited to, Afghanistan, Yemen, Syria, Somalia, parts of Libya, Colombia, Sudan, and Southern Sahara; and things are not completely clear in Egypt, Iraq or Iran, just to include the few I can think of from memory.


How a professional hacker would penetrate a computer in a network?

This is an extremely broad question.
When you're learning about security and penetration-testing, you're
supposed to learn all these techniques.
There are loads of techniques each with it's own purpose, situation,...

To give a small answer on your question,
Social engineering is often used, and so are backdoors.
Lastly I had to write a PoC (Proof of concept) for a webshop.
They had a design-flaw and XSS-error, the point is, that I could hack the
computer of each visitor (not user, just visitor); this attack was a mix of:
Website exploitation (XSS & the design flaw), basic social-engineering, exploiting a browser-vulnerability using BeEF & Metasploit, triggering a backdoor (reverse_tcp_meterpreter) on the user's machine.

Like you see, this attack took four to five different things in order to succeed, but at the end, I had control of the user's machine (my own machine of course in this example, it was a PoC).

Other ways to attack a machine on your network, is by seeing if he uses a specific service which has a vulnerability using port-scanning.
On your computer you have specific services running which need to listen to a specific port, most of the time, a port-number is related to that service. (e.g, 80 & 443 are HTTP(S) and thus mostly browsers). You can scan a machine on 'open' ports, if a port is open, you can look the port-number up to see if it matches a specific service. If it does, maybe the victim is using an old version of that service-software and that vulnerability can be exploited through that port.

When software has e.g a buffer overflow-vulnerability, it can be exploited. No matter if the payload is coming from an user-input or from a socket (port).

Than, you also have frameworks like e.g Metasploit who specialise in exploiting systems like Windows. In some cases you can get shell to another user's computer without none or very little user-interaction.
Metasploit relies on vulnerabilities in the system's software like flaws in platforms like Adobe, Java,...
Maybe you also remember that a few years ago a few people took down the Playstation & Xbox-network on Christmas?
They did that with programmatically exploiting a network-vulnerability which allowed them to infect the systems on that network with a backdoor/trojan.

But if you're in the same network itself (e.g, you hacked the Wi-Fi password, or it's a public network,...) you can do things like MiTM-attacks (Man In the Middle, intercepting and manipulating packets) with almost none user interaction, or something similar like network-sniffing.

But getting access to another computersystem without any user-interaction is hard. When you e.g deploy malware to a user, and it's e.g a trojan which needs to communicate to a C&C (Command-and-control server), your trojan needs to bypass the firewall in order to be able to communicate with the outside-world. This can be done with social engineering and than user-interaction is involved (e.g tricking the user on clicking "Accept firewall exception").
If you'd do this without any user-interaction, you'd need to be able to add your firewall exception programmatically (which ain't a problem with the Windows API), but then yet you'd need to privilege escalate to get root access, to actually add the exception.
Privilege escalation without user-interaction or social-engineering would be done by first finding a system-vulnerability which allows that, and than exploiting that vulnerability programmatically.
With luck, you can use already found vulnerabilities and pre-made exploits with e.g Powershell-scripts, to use that as payload, in your actual payload.

As you see, tons of options; but your question is hard to answer because it's too broad, and it differs from situation to situation.


Brute force login attempt from spoofed IP's

Its impossible to spoof your ip address of a TCP connection due to the 3 way handshake....  Unless of course the application is vulnerable to CWE-291: Trusting a Self Reported IP address

Sure enough in ./wordfence/lib/wfUtils.php on line 77:

public static function getIP(){
    $IP = 0;
    if(isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
        $IP = $_SERVER['HTTP_X_FORWARDED_FOR'];

So yes,  the reason why you are seeing brute force attempts from 8.8.8.8 is because WordFence is vulnerable to CWE-291.  I am reporting this vulnerability to WordFence,  but to be honest this vulnerability is so painfully obvious.  If the developer doesn't understand even the most basic flaws of trusting attacker input, then they have probably made other serious mistakes that impact security, I smell blood.

Its possible that a security system can make your system as a whole less secure.  This is nothing new, remote code execution vulnerabilities have been found in anti-virus software. Complexity is the worst enemy of security.


How to enumerate all drop-down options in an html form using Burp Suit Intruder

This isn't possible in core Burp but I have coded you an extension to do this. You can download it here

This version takes quite a basic approach, using regular expressions to parse the HTML. I'm sure it could be greatly improved.


Unescaped data in div or p tags, but unable to exploit

I see a number of possible explanation for this mystery:

The browsers built in XSS protection stopped the code from being executed. Not sure if the payload would be reflected back in the document if this was the case, though. (According to Conor Mancone in Chrome the payload will be reflected in the source but highlighted in red when you choose view source.)
There is a Content Security Policy that stops inline scripts from being executed. Fire up the developer console, go to the network tab and see if you can find a response header named Content-Security-Policy.
The content is put into the document using JS. If you set the DOM elements text property (or use the jQuery .text() method) the tags vill not be interpreted as tags but also not encoded as &gt;. To see if this is the case, use view source and see if you can find your payload in the actual page source. If it is not there, it must have gotten into the document by means of JS.


Flood of email messages from @attacker.com

This is a pretty standard "mail bombing", and I'd have expected Google to cotton up to it and prevent most of the emails from reaching you.

However, if you mark them as "spam", Google ought to do just that - several almost-identical emails are a dead ringer for undesired communications.

As for the source, granted that this information may be fake, but

 Return-Path: <634231594@attacker.com>
 Received: from WIN-EB12TG1C3GU ([212.68.146.41])
    by mx.google.com with ESMTP id cw1si4703530wib.7.2014.05.30.06.17.13

at least looks as if it originated at ArtVision hosting in Raanana, Israel.

The computer appears to be a Windows Asus Tablet. You might try writing to support (at) artvision (dot) co (dot) il and ask them whether they have noticed anything, such as an unexplained sluggishness in their unsecured guest WiFi network :-), or a creepy fellow sporting an Asus 12" slate spending time nearby.

Finally as for the "why", it again looks as if we have a very sick/disturbed/incompetent person who writes to you believing he's somehow reaching someone else.

It's difficult to do more than guess without a lot more information.

For example: when you fly abroad, is the plane you travel on usually referred to as "Air Force One"? :-)


Use of server and root certificate in ssl termination and inspection

There's a difference between the capabilities of a "root" certificate, which can be used to sign other certificates and a "server" certificate which cannot.

For an SSL proxy if you use a server certificate then the only host whose traffic could be seemlessly intercepted is the one whose Common Name is included on the server cert.

The general idea with this kind of SSL intercepting proxy is that you'll have a CA certificate which will be trusted by the clients connecting through the proxy and which can be used to create server certificates that the clients will trust, on-the-fly.


This might give you a little in-site into the process needed to perform this type of thing, http://du.nham.ca/blog/posts/2013/03/08/password-cracking-on-amazon-ec2/  it uses http://hashcat.net/oclhashcat-plus/ along with ec2 to perform circa 2320.9 million MD5 hashes per second, it's maybe not exactly what you looking for but it will certainly give you some pointers.


SSH and VPN provides basically the same encryption mechanisms.
Let’s imagine they both provide the same security, and you configured them well. If an attacker is able to decrypt your VPN communication in a reasonable time, it probably means that he can do the same thing for SSH in roughly the same time.

So, you did doubled your defence, but at a relatively high cost (you could have done better using a longer key for example).

Defence in depth is a good thing ; but I think that here it would be trying to double your defence at the same level, so my advice would be to focus on one of the solution (probably SSH if your are remotely login to one server only, VPN you want to connect to a network) to know and configure it well. A good defence in depth may consist in a firewall, fai2ban (as mentioned in the article)…


If attackers can physically move the data around, from Flash to Flash, then you will need to resort to cryptography. If chip A must be able to make sense of some data bytes, but chip B (of the same model) cannot, then chip A must know something that B does not. Encryption reduces the problem: if you encrypt all your sensitive data with a secret key known only to A (let's call it KA) then your problem becomes: how can you make A store its key, in a way that it cannot be extracted ? Length of KA would typically be 128 bits, i.e. 16 bytes; that's the added value of cryptography: the size of your problem has shrunk down to 16 bytes.

The first normal method is the following: during an initial phase (typically at the end of the factory line), a device-specific key KA is injected in device A, to be stored in a tamper-resistant chip. That chip must be able to store the key (only a few bytes), do some encryption/decryption with it, and resist forceful extraction (physical resistance). A "master server" stores a copy of all device keys (warning ! sensitive !) and encrypts data elements which must be afterwards sent securely to device A. Mobile phones use that model; the tamper-resistant chip is the SIM card.

An extended method entails a tamper-resistant chip with a bit more power: it can do asymmetric cryptography (say, RSA) and generate its own private/public key pair. During the initial enrollment phase, under controlled conditions, the device generates its key pair, and exports the public key; the public key is stored externally, and is used for encryption (when some data is to be sent securely to device A) and authentication (when device A wants to prove its identity to an online server). Typically, during the enrollment phase, the public key is wrapped by a custom Certification Authority into a certificate and used in standard protocols such as SSL/TLS. Some payment terminals use this model.

A TPM is a tamper-resistant chip which can usually do asymmetric crypto, including generating and storing a private key. This is the right tool for the job, but you still have to use it: the TPM will not magically, by its mere presence, protect the data; you have to design the initial enrollment phase and do the key management. As described above, this more-or-less implies running your own PKI.


BEAST mitigation on a Cisco ACE 4710 load balancer

The simplest way to mitigate BEAST is to do nothing at all. BEAST is a client attack. Servers can "protect" clients by enforcing the use of RC4-based cipher suites even if the client states that it prefers some CBC cipher suites. However, all recent Web browser versions include workarounds which make them immune to BEAST, namely the 1/n-1 split; and the server has never been vulnerable to begin with.

Also, BEAST relies on the ability to inject in the client some hostile Javascript which can send arbitrary binary requests to an external host; this requires a hole in the Same Origin Policy. The two holes which were used in the original BEAST demo have been patched (one used a bug in Java, the other an old draft version of WebSockets).

Therefore, is BEAST is still a concern for you, then your browser is madly out-of-date and has quite a lot of other, more urgent vulnerabilities. Update it ASAP. As a by-product, it will fix any BEAST-related worries.


What ports are okay to be open on a macbook pro?

Open ports are specific to each network interface. If you performed the scan from the MacBook itself, then chances are that you are seeing open ports that are exposed to localhost only, and not to the local network. It may be that a port is reachable from the same computer, but not the local network.

To view which processes use which ports, you can use the following command:

sudo lsof -i -n -P

This will print all ports and connections. Those with LISTEN are ready to receive connections.

On my MacBook only TCP ports 8021 and 29754 are open. You seem to have more open ports, but whether that's good or bad isn't clear without more details.

MacOS has a built-in firewall to block incoming connections. You can find the settings under "Security & Privacy".


Why doesn't my IP change on manual router turn off/on?

Dynamic IPv4 address allocation is a common strategy for ISPs to reclaim globally routable IP addresses (a.k.a. "public addresses") since they have to few of them to assign them permanently to their customers. In terms of privacy that means that end users are harder to track. But like NAT, which was never meant to be security mechanism, dynamic address allocation is not meant to be a privacy mechanism (in fact, it is not). With IPv6 neither NAT nor dynamic address allocation is required. Thus, the IPv6 prefix you get from your ISP is likely fixed, at least for a while. A priori there's nothing you can do about it.

The ISP may provide a mechanism to let you have a fresh prefix, e.g. German Telekom is said to have such a mechanism to answer privacy concerns regarding static prefixes. However, even if you got dynamic prefixes, your devices will be trackable by the interface identifier. Privacy extensions may come to mind but they are of only modest use: They change only after a fixed period (typically one day) or if the NIC is reconfigured - they don't change on prefix change! (For those who are curious, see RFC 4941, Section 3.3, item #6: New temporary addresses MUST be created by appending the interface's current randomized interface identifier to the prefix that was received.) Thus, by suitable chaining your devices are trackable across  prefix and IID changes. In order to break the chain they must change simultaneously, which, given that there is no sync mechanism, would happen only by coincidence with quite small probability.


Is there any security risk in not setting a maximum password length?

A limit is recommended simply to avoid exhausting resources on the server.
Without a limit, an attacker could call the login endpoint with an extremely large password, say a gigabyte (let's ignore whether it's practical to send that much at once. You could instead send 10MB at a time, but more quickly).
Any work the server needs to do on the password will now be that much more expensive. This applies not just to password hashing but every level of processing to reassemble the packets and get them to the application. Memory usage on the server also increases considerably.
Just a few concurrent 10MB login requests will start having an impact on server performance, perhaps to the point of exhausting resources and triggering a denial of service.
These may not be security issues in the sense of password/data leakage but crippling a service by DOS or crashing definitely is. Note that I make no mention of buffer overflow: decent code can handle arbitrarily big passwords without overflowing.
To wrap up, I think when someone says "there's no reason to limit the number of characters of a password", they are talking about commonly seen small limits (eg: 10 or 20 characters). There is indeed no reason for those other than laziness or working with old systems. A limit of 256 characters which is larger than desired by most people (except those testing those limits) is reasonable and can prevent some of the issues related to arbitrarily-large payloads.


Technically, the popup does not ask you whether you really want to download the file; that decision, you already took when you clicked on the link which triggered the download. The popup asks you what Firefox should do with the file when it has been fully downloaded.

Potentially hostile files can be a security issue. Filesystems normally store files as bunch of bytes and are thus nominally immune to the file contents; but modern operating systems are not content with handling files as files. For instance, if you open a file explorer to see the directory in which downloaded files are stored, and the file has a name which ends in '.jpg' or '.png', then the file explorer will try to interpret the file contents automatically, as a picture, so as to compute and display a miniature view of the said picture. Any security hole in the JPEG or PNG support library could then be exploited by a malicious file, and it does not require any "opening click" on the file, just opening the directory.

The Web is a harsh place.


Telegram (or other messenger) message as second factor in 2FA

There is a couple of reasons that keep SMS a superior and safe choice as a mean for communicating 2AF code compared to the other messaging systems like Messenger or WhatsApp:

SMS is built-in feature on mobile phones, you don't have to install it and you can not uninstall it intentionally or accidentally.
Not every customer has a smartphone unlike a plain GSM mobile.
Hypothetically, if all customers have a smartphone, you don't control which Messaging app each one has to install.

Update:
The word "Safe" here is pointed out from business perspective and doesn't imply SMS as a system is more secure.


Hundreds of legitimate IPs are hitting my website like bots

A few hundred hits per day should not significantly affect your CPU usage.

Here are some things you can do to try to diagnose the problem:

Change your IP address or use a dynamic IP address.  This will tell you whether you are being targeted by domain name or by IP address (the latter being more likely to be an automated attack).
Take down your web server for a day or two and then bring it back up.  Does the traffic return immediately?
Pick some of the IP addresses and track them down.  See if you can contact a local sysadmin to ask about the traffic.


How to revoke certificates, or generate CRL files with Keytool

keytool does not provide the necessary functionality. As for openssl - there are several extensive documentations (like this) which are trivial to find. It makes no sense to replicate everything here again.


Yes you could do this with ARP Spoofing.

  The part I am confused on is how to make my fake AP redirect all traffic to the cafe AP.

The software you are running should forward on all packets to the real access point after interception.

  Thinking about it, is it possible to connect to the Cafe AP and simply sniff in promiscuous mode to receive packets from all who are connected?

Yes (or in Monitor Mode), although you'll probably need a USB wifi dongle, as most laptop built in  Wifi adapters don't support these modes.


Can nmap take a list of ports to scan from a file?

Not by itself, no. But with some quick scripting you can.

For example, on *nix systems:

nmap -p `cat ports.list` ...

This would allow you to maintain a list of ports in a file in a CSV format.

If you would prefer to have one port per line, you can do this (thanks @bonsaiviking) on *nix systems:

nmap -p $(tr '\n' , <ports.list)


How to force nmap to check all the ports?

You can pass in the -p- flag as specified in the nmap help page.

For example,

  nmap -p- 192.168.1.1

Another option would be to pass in the explicit range you want with the -p flag.

For example,

  nmap -p 1-65535 192.168.1.1


Shared host that is not a service provider, with no SAQ/AoC. Is compliance possible?

In your previous question, you indicated that you need to complete an SAQ-A-EP. Since all of your infrastructure is being provided by the hosting provider, you are relying on their PCI compliance. You are being placed in a difficult situation since they are not providing an Attestation of Compliance. They can say they are compliant but unless they provide an AoC then you only have their word. If you can't demonstrate the compliance status of your service providers, you run the risk of not meeting requirement 12.8.

Here are a few options:

Check the Visa Registry of Service Providers to see if they are listed.
Contact the hosting provider directly either through a relationship or customer manager. Ask them how you can be compliant without their AoC.
Talk with your acquiring bank. Since you are accountable to them regarding your compliance, ask them for guidance. They can give you suggestions for how to address the situation to their satisfaction.
Look for another hosting provider. Yes, this isn't optimal but if the hosting provider consistently pushes back on demonstrating their compliance, and your compliance is vital enough, then the hosting provider is increasing your risk. Many hosting providers actively publish their AoCs. For example, Microsoft publishes the AoC for Azure.


Does Rainbow Table Not Require Decompression?

Your basic premise is wrong: a rainbow table is not just a compressed list of every possible hash lookup, and you do still need to do some hashing on the fly. Instead, it's a way of exploiting the nature of hashes to avoid storing the lookups in the first place, and minimise the amount you need to re-compute.

Wikipedia has quite a detailed explanation and there is an existing question here with good answers, but the basic idea is you create a table like this:

Start with a particular password guess
Hash it
Take the hashed value as the next password guess (after applying some reproducible transform)
Hash that
Repeat steps 3 and 4 a set number of times
Store only the original guess, and the final hash. It is this that makes the rainbow table smaller than a full lookup table.

From the values you've stored, you can get back all the guesses generated at step 3. In a sense, each pair of { first guess, last hash } "compresses" the full chain of generated guesses.

But the trick is you don't need to try all the chains to reverse a hash, because if you take the hash you're attacking and start at step 2, you will eventually end up at one of the final hashes you stored (at step 6). Once you've found that, you can recreate ("decompress", if you like) just that one chain, by going from step 1 (the stored password guess) and generating all the intermediate guesses.

An important difference between this and compression is that you can make the stored table as small as you want, by making the chains longer - you'll just have to spend longer re-generating hashes to choose a chain, and to re-create the chosen chain. You could have a million chains of length ten, or ten of length one million, trading storage against CPU time.

It is of course possible to compress the resulting data using any algorithm you like. Some of these will require decompressing the entire table before searching it, others might arrange the data so that it is still searchable but takes up less space. But it would also be possible to store the entire rainbow table as, say, a sorted list on a fast SSD, and you would still have saved space over a full hash table because you are only storing the start and end of each chain, not every possible hash.