Cipher used for request data encryption used by browser

The browser will generate a session key and encrypt it using server's public key. But which encryption algorithm (or commonly
  called as cipher algorithm) will be used by the browser?

  How is cipher selection determined, and will browser and server both use the same cipher/key size for encryption and decryption?

The browser will send a list of cipher suites to the server that it supports.  This answer will explain what a cipher suite is in detail, but basically a cipher suite is a list of algorithms to use for the secure communication.  A cipher suite contains:

TLS Version
Key Exchange Algorithm
Signing Algorithm
Symmetric Encryption Algorithm
Integrity Algorithm

For example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The browser sends a list of supported cipher suites to the server, and the server chooses the most secure cipher suite that it supports.  If it doesn't support any in the list then the connection fails.  The symmetric encryption algorithm is what the session key is used for.  In SSL/TLS, keys are generated from the pre-master secret.

  Once SSL handshake is completed, all communication will be encrypted using the symmetric session key, but again which encryption
  algorithm will be used by the browser?

Again, the symmetric algorithm in the cipher suite will be used for the encrypted communication.  In the example above it would be 128-bit AES in GCM mode.

  Is the encryption algorithm used by browser in any way dependant upon certificate received from server?

  Or is all encryption performed by the browser performed with the same cipher algorithm?

It is in no way dependent on the certificate.  All encryption is performed by the symmetric encryption algorithm in the cipher suite chosen by the server.

  Please correct me if I am wrong, the algorithm or cipher information is also present in the certificate? How does that
  information stored in the certificate?

  While generating the certificate do I need to state which algorithm, how many bits encryption, padding etc.?

The algorithm and cipher for the secure communication is not in the certificate, but as stated above within the cipher suite chosen by the server.  The certificate only contains information relating to the certificate itself.  Which includes, but not limited to, validity information, signing algorithm, issuer information etc.

  Based on the above answer I will have the most important question -
  suppose I am providing my server's private key to somebody so that he
  can monitor the SSL traffic for my server, then apart from providing
  him the private key what all other things I need to take care. And do
  I need to tell him the algorithm or cipher I am using at server?

I would highly recommend not providing your server's private key for SSL traffic monitoring (for reasons outside the scope of this question).  However, if you do decide to share your private key the other party doesn't need any other information.  As the algorithm and cipher are not included in the certificate.


How to steganograph ownership information into members uploaded images?

Steganography is about concealing information in a medium (e.g. pictures) in a way that people who look at the medium are unaware of the presence of that information.

What you want is something else called watermarking: how to embed some information which is hard to remove. A good watermark does not alter (too much) the medium in the eyes of onlookers, but resists minor modifications such as colour filters or image cropping. On the other hand, these onlookers may be totally aware of the presence of the watermark (even if they don't actually see it).

Steganography and watermarking are quite distinct things. Usually, good steganography is fragile (minor alterations will remove it) because it hides into what can pass as simple "noise"; in a sense, robust steganography can be said to be bad because robust information is information that is much more likely to show up during statistical analysis. On the other hand, watermarks MUST be robust.

In all generality, watermarking is a lot harder to do than steganography. If "attackers" (here, people that want to grab pictures and remove ownership information) are technically inclined and have access to some system that can tell them whether the mark is present in a given picture, then they will be able to reliably remove watermarks without much altering the pictures. This means that whatever mechanism you use, you will have to keep it quiet and do not let your users ever suspect that it exists. Of course, discussing it over a public Internet-based forum like this one is kinda counterproductive...

(If your users are just normal humans, not bored geeks with too much time on their hands, then simply adding the ownership information in the EXIF metadata could already be sufficient for your needs.)


Wireless devices with default configurations

I believe that you should not trust other users in the network, I believe that you want to use it as a black-box that is serving for a specific purpose for your clients. So they are receiving some hardware that helps to achieve some goal but they have no reason to look inside how it works..even if it could be challenging to achieve.The way I see it is that you want to use the device similarly as the boxes we receive for our TV services that are connected to the Internet.

So you should work on it to secure it, similarly as the IP Cameras we have.

I know that Google's ChromeCast can be accessed as by anyone who has access to the network, and they have decided to go in favor of easiness of usability instead of security and now any kid can start to broadcast anything on TV. The risk is not high, but our this situation where this device serves for example to open the garage and if the attacker was able only to penetrate in the network of your client, we could authenticate to that box with the default password and send a the request to open the garage allowing them to access in da house.

It is similarly problematic when routers were having default passwords, allowing malicious users to login,change network configurations to read their network traffic.


I think the operative word in the question here is "afraid."  The aversion is based on fear, not fact.  The reality is, the threat model isn't particularly realistic.  Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS stolen by a competitor and then been driven out of business because of it.  I'm quite confident that it hasn't happened, and isn't likely too.

Too your second question, do companies like Google obfuscate their JavaScript?  Yes, but not for security!  They obfuscate to minimize the size of the code, in order to reduce the download size and minimize the page load times.  (See the Google Closure Compiler.)  This is not necessarily how you'd obfuscate for security because the only goal is to minimize the number of bytes that have to be delivered to the client.   This is what you should be focused on with JavaScript, not worrying about whether someone will be able to read it or not.


How to know if my webcam is being used to spy on me?

It's extremely unlikely. For a start, many of the camera-enable LEDs are driven by a microcontroller on the webcam itself, switching on when the camera is in use, so the driver doesn't make a difference here. In fact, last I checked, most webcams use a generic driver (e.g. WIA) for image capture.

If you're really worried, install a privacy cover over the camera.


What information is collected because of signing into Windows 10 with a Microsoft account?

This question bothers a lot of our customers. There are three major effects switching from a local-only account to a Microsoft account:

Identification

Microsoft will be able to identify the users from within different applications, websites and services. Even if they are using other hardware after a successful login (e.g. mobile phones or your friends computer).

This identification might lead to a advanced profiling which may cause highly personalized ads. The same effect can be observed on other OS ecosystems with advanced cloud technologies like Apple iOS and Google Android.

Synchronisation

Microsoft is using Windows 10, Office 2016 and other products of the current line-up to push their cloud services. In case of Windows 10 this includes synchronization of settings between devices (e.g. theme, browser settings).

This might also include passwords (browser, WiFi) which would increase the risk of breaches. However, Microsoft is using transport encryption and I assume they are also using some kind of encryption for the stored data. This would limit the risk of an incident. But still: Your sensitive data is leaving your local storage which increases the attack surface.

The same goes for OneDrive which is used to sync files between devices (like Dropbox). You are able to define OneDrive as your main storage which causes additional security-related and in some cases even legal-related implications. Under some circumstances and in some sectors this might not be allowed. This is one of the problems Swiss financial institutes are facing with Windows 10.

Linked Services

Some features and services require a Microsoft login to be used. This might include the Windows Apps Store and Cortana. Using these services might introduce additional risks of profiling (Personal Ads), data leakage (Cortana phones home) and further exploit vectors. But this is nothing new and also part of every other OS and online service. I don't have good example (yet?) where an exploitation of Windows 10 was only possible because of a Microsoft login.


The minimum allowed password length for WPA2-PSK is 8 characters. So APs that don't have any password (or other form of authentication) are actually open. They use no encryption at all.
In fact, the 4 way handshake is never encrypted. HMAC-SHA1 is used to prove that both parties know the PMK, but the ANonce, SNonce and MAC addresses are always transmitted in clear.


Determining the accuracy of a biometric system

Well, I am not sure if this what you are looking for. In general, the performance of any biometric system (e.g fingerprint, voice, facial recognition, etc) is described using several metrics.

FAR or False Acceptance rate is the probability that the system incorrectly authorizes a non-authorized person, due to incorrectly matching the biometric input with a template. The FAR is normally expressed as a percentage, following the FAR definition this is the percentage of invalid inputs which are incorrectly accepted.

FRR or False Rejection Rate is the probability that the system incorrectly rejects access to an authorized person, due to failing to match the biometric input with a template. The FRR is normally expressed as a percentage, following the FRR definition this is the percentage of valid inputs which are incorrectly rejected.

CER or Crossover Error Rate is the rate where both accept and reject error rates are equal.

FER The Failure to Enroll Rate (FER) is the percentage of the population which fails to complete enrollment.

EXAMPLE:

let us assume we have a fingerprint biometric system. We also, have 100 users. During the enrollment stage 5 users where not able to enroll (e.g we can not establish a fingerprint signature/template for them). This means the system has a Failure to Enroll Rate (FER) = 5%. This means only 95 users can use the system.

Then, during the testing out of the 95 users, 10 users were rejected when the system match their fingerprint against their enrollment fingerprint template. This means the FRR =10.52%.

Also, 3 users out of the 95 users were accepted by the system when the system match their fingerprint against other users fingerprint template. This means the FAR = 3.15%

The lower FAR and FRR , the better the system


Understanding Windows local password hashes (NTLM)

Using

[Jason, :, 502, :, aad3c435b514a4eeaad3b935b51304fe, :, c46b9e588fa0d112de6f59fd6d58eae3, :, :, :]

as the example

Jason is the user name
502 is the relative identifier (500 is an administrator, 502 here is a kerberos account.)  (adsecurity.org/?p=483)
aad3c435b514a4eeaad3b935b51304f is the LM hash
c46b9e588fa0d112de6f59fd6d58eae3 is the NT hash

Details on difference between the hashes can be found here:
LM / NT Hashes


How to safely synchronize time over Internet?

Full-fledged NTP implementations only allow a limited skew. For example, the de facto standard (formerly ISC) implementation on Linux will not deviate from the local clock by more than 1/2000 by default (a bit less than one minute per day). Hence an attacker cannot cause a huge clock deviation with such an implementation. In a typical site-wide or server setting, an attacker who can cause your clock to drift can also do far more worrisome things including significant DoS.

If you need more precision, get a clock that doesn't rely on the Internet. You can get time signals from many radio transmitters, from GPS, etc. Receivers start around $10 or so. An atomic clock makes you more independent, but it's, ahem, significantly more expensive.

NTP implementations on embedded devices (including many network appliances) are often dumber. Many of them will reset the date once a day or so without performing any consistency check (especially those without an internal clock, that must obtain a date at boot time anyway). So if at all possible be sure to configure all such devices to get the time from a reliable server in your internal network, not over the Internet.

If you do need extra security, NTP supports integrity and authenticity checks on time signals. These are enough to protect against an attacker who only injects fake NTP response packets. If the attacker can delay legitimate packets in transit, authenticating the packets is not enough. Your only option in that case is to reject responses if they take too long (the threshold depends on how much drift is permissible).


Using HTTP Strict-Transport-Security with preloaded

To get your site preloaded by the browsers you must submit it to https://hstspreload.org/. The site there clearly states:

  Submission Requirements ...
  3.Serve all subdomains over HTTPS. In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.


One way to do this is to have the client app (which must already have the message in plaintext) send the message to the third party chat system directly instead of through your system. Depending on how you authenticate with the third party, this may mean that you'll have to disclose your API key to the client or provision a unique API key for each client users and somehow restrict their permissions.

Alternatively, if you authenticate with the third party app using an algorithm like HMAC, you may be able to split the HMAC calculation into two. The client app should calculate a hash of the plain text message, send the hash to your server, which should then calculate the authenticated hash from the given hash and your API signing key. The client then can make a connection to the third party server (possibly proxied through your server if there are IP address restrictions) and send the authenticated hash and the plaintext message using your credential without disclosing the content of the message to your server. This is a form of blind signing. However, you need to be careful with this as blind signing means that you also have no control over what you're signing and it may be possible for a malicious client to construct message that allows them to do things they shouldn't if your API signing key have greater privilege than what the client is supposed to have.


How to steal source code through clickjacking?

It is not possible to use clickjacking to get cross-origin access to the source code of a web page. This access is restricted by the same-origin policy and clickjacking does not bypass it. This means that, similar to a CSRF attack, you can cause a cross-origin action with clickjacking but you cannot read back the result of this action.

Thanks for Arminius for pointing out in a comment that it was once possible to exfiltrate content using clickjacking by using cross-origin drag and drop. See for example Clickjacking 2.0 with drag & drop or this bug for Firefox. This seems to be forbidden in the browsers for a while now, i.e. modern browsers should no longer be affected by this.


With BREACH attack, is session-based CSRF token still secure?

If your site is vulnerable to BREACH, an attacker can guess anything in the body of the response one character at a time. The attacker does multiple requests, one per guess, and can see if he guessed correctly. For example, the attacker may try these guesses:

csrftoken=a
csrftoken=b
csrftoken=c
etc.

After a while he figures out the first character of the token, and moves on to the next character. As you can see there are hundreds of requests needed to guess the whole CSRF token.

This attack only works if the same CSRF token is returned in all requests. If the token differs between requests, the attacker can not use multiple requests to guess it. So to protect against the BREACH attack, the CSRF token should be different on each page.

However, it is not necessary to create a new token for each request. Simply obfuscating the CSRF token is sufficient. You could encrypt or even XOR the CSRF token with some salt you include in the form, as Django and Rails do. This means that the token is different on each page, but you still have to check only one value in the backend.


Exploits inevitably "cost of doing business on the Internet"?

I'd say that it's not so much that exploits are inevitable but that the security industry for a long time focused more or less exclusively on the idea of preventing exploits and didn't put enough effort into detecting or reacting to problems when they occur.

Unfortunately what's transpiring is that preventative efforts (in a lot of cases) aren't good enough, which is down to a number of factors like poor understanding of what "secure" means in a given setup, lacking economic incentives to invest properly in good development security practices, the prevalence of "snake-oil" in security product sales ("Here buy this black-box and you'll be "secure"!"), etc, etc.

The result is that a lot of companies are now getting compromised, as attackers are moving faster than defenders in many cases, and the defenders have years of security debt built up due to under-investment.

So I'd say that it is sensible advice for companies to realise that it's likely they'll suffer a breach and plan accordingly.

If you want more information on the state of play, I'd recommend the Verizon Data Breach reports, the Mandiant M-Trends reports and the Veracode state of software security reports amongst others.


Server + Client certificate vs Server certificate + Client password

When only the server sends a certificate, but not the client, the SSL connection is fine and dandy, but the server has no clue about who it is talking too. What SSL provides in that case is that the server can be sure that it talks to the same client all along, with no possible eavesdropper in the middle. If the server must still know who the client may be, another additional authentication must take place, e.g. the client sends a username+password to the server. This is how things go on usual HTTPS Web sites.

Certificate-based client authentication is most useful when the client wants to demonstrate its identity to the server but not give any secret to that server. This really makes sense when the client certificate has been issued to the client by a Certification Authority distinct from the server owner. If the server itself is giving certificates to clients, then using a client certificate does not has much conceptual advantage over a simple show-the-password authentication.

(Client certificates may have some implementation advantages: they can be used with certificate-aware smart cards; and since the certificate thing is done in the SSL handshake, it avoids the need to include a show-the-password authentication protocol within the application data.)


Single token in cookie for e-commerce site to store all data related to user in DB, is it secure?

Do not use a GUID as a session identifier, GUIDs may be cryptographically secure, but they are not always. Since you're using PHP you should use PHP's default session cookie implementation since it uses a CSPRNG (as of 7.1, for older versions see here).

Session hijacking can be avoided by:

Using a CSPRNG to avoid predictable session identifiers
Set the Secure flag on the cookie to avoid sending it over an unencrypted connection
Set the HttpOnly flag on the cookie to prevent javascript from reading it

Recent versions of PHP do #1 for you, and session_set_cookie_params allows you to do #2 and #3.

Related: Are GUIDs safe for one-time tokens?


How to report error if redirect_uri doesn't match?

According to the specification, you should display an error message on the authorization server (option 1):

  If the request fails due to a missing, invalid, or mismatching
  redirection URI, or if the client identifier is missing or invalid,
  the authorization server SHOULD inform the resource owner of the
  error and MUST NOT automatically redirect the user-agent to the
  invalid redirection URI.


Once in a while, when entering or leaving the house, look to see if anyone has spliced into the cable.  If the cable looks OK, you're good.

This has no set-up requirements at all, and zero impact on your network speed.


By default, sqlmap tries all possible parameters, hence it should include both menu_id and news_id in its execution sequentially.

If, on the other hand, you'd like to skip menu_id and go straight for the second parameter, you could run it as follows:

./sqlmap.py -u "http://www.example.com/index.php?menu_id=1002&news_id=5" -p news_id


Encryption method that would encrypt alphanumeric data to alphanumeric data

Encode the input as some bytes, encrypt that, and encode the encryption output in hexadecimal, which is, by definition, alphanumeric. This is simple enough to implement and will piggyback on an existing implementation of AES or whatever encryption system you envision.

Now this will imply some growth in size, because:

Encryption will need some IV (characteristics depend on the mode of operation with which you use AES) and that IV will have to be made part of the output (that which you convert in hexadecimal) because it will be needed for decryption.
Depending on the mode of operation, some padding may have to be applied, so that the input data length is a multiple of some value.
Proper symmetric encryption also includes some sort of MAC, because most situations where encryption is warranted also need, in practice, some protection against active attackers; and that MAC will again increase the length.
With hexadecimal, each byte becomes two characters.

Some of these growth elements can be mitigated. For instance, if the encryption mode you use is GCM or EAX, then there will be no need for padding, the extra size for the MAC part will be limited (16 bytes)(and a very nice property of GCM and EAX is that they take care of the MAC in a cryptographically sound way, contrary to most homemade constructions) and the IV needs only be unique, not random, and thus can be a simple counter (which could be encoded over four bytes or so, depending on the context). Also, you could replace hexadecimal with Base64, which implies less growth (note that raw Base64 uses both lowercase and uppercase letters with distinct meanings; also, it uses two extra non-alphanumeric characters '+' and '/'; but a Base62 encoding which uses only digits and letters would not be hard to design and implement).

If the output must have the same size as the input, then things become a lot more tricky. You won't be able to reuse an existing library, or even AES at all. This is the realm of Format Preserving Encryption, which is more a research area than a tool ready for production, unless you are a trained cryptographer and you know what you are doing, in which case everything I wrote above was trivial (for you) and you needn't read it.


Impact of Metcalfe's law on the quality of security

Here are some things to point you in the right direction:

First of all forget the conclusion you are trying to draw. That's how
you end up never seeing anything. Think, and let that process take
you to a conclusion right or wrong.
Remember that equations, even proportional ones, can be interpreted as easily as well defined ones. Think about what that means. For example if [value (V)] ~ [# of users (U)]^2 that means that the change of value dV ~ 2U. A linearly increasing function.
If the change in value (dV) is always increasing, what will that do for the interest of criminals in said system?
Remember # of Users includes criminals.
Remember the opposite is also true, as value increases what happens to those who wish to protect said system?
I bet you there is a relation between the value of a system, and the amount of work users are willing to put into it to break/protect it. I might be highly correlated to our initial premise.
Now that you have a system of equations (you should have 3 or more at this point) What happens as U->infinity and U->0. Does this change the perspective of the other points at all? yes or no?
Remember that if you are really clever there exists a logical path to relations you can create, some you have, some you need to make yourself, and some very interesting conclusions come out of it.

These points should help you get started the right way. Dig into it. It's actually a really interesting thought experiment.

EDIT:

As an extra little hint, bullet point 6 above was worded very specifically and is central to the epiphany. Especially if you also want to analyze the effect of the "lemon market" as you say. It was really cool to see what was developing as I kept writing.


Perform man-in-the-middle attack on HTTPS website with same certificate

I'm not familiar with Cloudflare, so this is more general.

In theory, it's possible for someone to change the Cloudflare front-end configuration to point your site at somebody else's server, then redirect back to your server, but it seems unlikely.

You can always test for incoming IP addresses to see if they're the ones you're expecting from Cloudflare. If they're not, the chances are they are coming from another server. In order to MITM, they would have to forward the intercepted traffic to your servers, so you can inspect the IP addresses to see if they're the ones you're expecting.

Other than that, I'm not sure what signals you would look for; the MITM server would try to masquerade as a Cloudflare server (and might actually be one, if the attacker could take over such a server). Burp Suite might be to indicate what a false signature looks like. You could also try a timing probe, browsing to your web site, and seeing if the timing is as you expect, or whether it is longer than expected; the latter might indicate that the connection has been routed through another server.

Of course, for any of this, you'll need baseline data, indicating what the "normal" state of affairs is.


Are there totally isolated processes or services possible under Windows?

One way to do this would be a kernel-mode software device driver (or, as other OSes would term it, a kernel module). Drivers are technically just another Windows service, in most ways (they don't show up in services.msc, but if you look in the registry, they're there alongside the user-mode services). However, they have advantages no user-mode process does. Most notably, they can read the memory of any user-space program, no matter how protected it is; with enough effort they can even read the memory of processes that run in isolated VMs on the same host. They are also in the best position to do things like make the OS lie to other processes about running processes, files and file contents, and registry keys and values; this is useful if you want to hide your service's existence.

Of course, the technical term for what you've written at this point is "rootkit". Nobody is going to want to install this thing on their own system, and if you do it without their permission you will be sued and/or arrested. It doesn't really matter what you're doing with it; no Legitimate process needs to hide itself that hard.

Additionally, there are limitations on how far you can go. Your driver can try to prevent any process from tampering with its file(s) on disk, but it can only do that while it's running; somebody with access to bootable media (such as a Windows install disk or a Linux liveCD) could easily find the files, registry entries, etc. and modify or remove them (this is, in fact, how the Sysinternals "Rootkit Revealer" tool works). Similarly, anything you can do, another driver could also do; yours might be able to prevent even another driver from noticing its existence, but only if yours starts first. Finally, a kernel debugger attached to a machine running this driver will almost certainly be able to detect (and tamper with or remove) it.

There's lots of problems with the driver approach, too. Writing drivers is tricky, and they need to be pretty much perfect. If they crash, the system goes down (BSOD). If they hang, the system may also hang. If they have security vulnerabilites, an attacker who finds one can use it to take over the machine. If they want to get really deep into the OS, they're run into parts that are not officially documented and therefore subject to changing when updates are installed, and that could turn a working driver into a crashing one (there's been a problem with pre-release "Fast ring" Windows builds and certain game DRM crashing them for months now, because the DRM was hooking parts of the kernel that it shouldn't). If they try and tamper with stuff too deep into the kernel, the kernel itself may fight back; there's a feature called "PatchGuard" that detects modification of many kernel data structures, and while you may learn to bypass one version of it, the next one might catch you. Finally, if you want to load your driver on 64-bit Windows, it will either need to be blessed by Microsoft (signed with a code signing key that authenticates your code) or will only be loadable if the kernel was booted in "testsigning" or "debug" mode. Both of these modes cause (deliberately) visible modifications to the desktop, and also disable certain parts of Windows (mostly related to media DRM), since otherwise a driver like yours could see what they're doing; to users, this will manifest as certain functions of the OS not working anymore.

There's a user-mode option if you don't want to go all the way into the kernel, but it's not going to work any better. Windows does have the concept of a "protected process" that can inspect and debug (meaning, among other things, read or write memory) other processes but cannot itself be inspected or debugged. These are called "protected processes", and while their presence is not secret, what they do is. However, protected processes cannot access as much stuff as a driver, are even harder to create than drivers (they're less delicate, but they not only must be signed, they need a special signature), and as mentioned they're less secretive.

Is there a particular reason you're trying to do this?


The QR code you're supposed to scan when setting up your authenticator app contains a secret key (the seed) as well as the hashing algorithm and the number of digits. Nothing prevents you from scanning this code on multiple devices or taking a photo of it to enroll future devices later.


Is UDP used for applications that require less security?

If data needs to be secured does not depend on the transport protocol (UDP vs. TCP) but on the kind of data. For example there is HTTPS to protect HTTP traffic which is deemed to be often sensitive. And there is HTTP/3 for the same purpose as HTTP but on top of UDP - and it is secured on the same level as HTTPS is. Similar WebRTC uses UDP for real time transport of audio and video but these get encrypted too (SRTP). Also, the VPN OpenVPN by default uses encrypted UDP for data transport.

But it is kind of true that encryption does not see as much use with UDP based protocol as with TCP based. For example the majority of RTP traffic used in VoIP protocols like SIP is still unencrypted even though there are protocol like SRTP or ZRTP which support proper encryption on top of RTP (and thus UDP). Incidentally SIP itself (as the control layer in VoIP) is usually unencrypted too even if there is SIP over TLS (SIPS). This might be because some things like surfing the web or sending and receiving mail are more in the focus of attacks and there is more public awareness and pressure to implement encryption for these than for the other protocols.


You cannot encrypt the MAC address itself and "send that packet to the router" - the MAC is required to enable the packet to reach the router and enable the router to send packets back.  It's simply not possible to "hide" the MAC address.

While it's theoretically possible to put some sort of signing (related to encryption) in place, using encryption primitives to attest to the validity of packet-MAC pairings, the protocols do not currently support that to the best of my knowledge.  I think you'll find that anyone approaching this problem does so at a higher level - transport (IPSec) or application (HTTPS).  Not least because any authentication of the physical layer is non-routable; the MAC address only has significance within the local network, and any work done to secure it will not scale more than one hop.

As an exercise allow me to suggest that you perform a packet capture of traffic during at least two routed hops (e.g., at the web client, at the web server, a router in between).  Look at the MAC addresses involved.  They change and have no authoritative relation to the sender or receiver.  Taking the measures you've suggested to secure them would not be applicable.


Is it secure to use ChangeHats for Web Application?

From the linked article I'd say that the answer to your first question needs to be considered in relative terms.

Relative to not using AppArmor at all no it doesn't as at least you have some better isolation than would be allowed by default and from what they're saying, if an attacker can bypass the ChangeHat protection they just get as far as being constrained by the containing profile.

Relative to using individual profiles for each piece of code the security is weaker, but I don't think that would always be a practical proposition.

Again from reading the doc. it seems to me that they key is essentially the mechanism by which a piece of code claims the level of rights for that hat.

So if an application has 3 hats defined the problem is that if there's a bug in a piece that uses hat1 the exploited code may be able to read the keys for hat2 and hat3 thereby negating the protection that they provide.


Nmap reporting almost every port as open

You're most likely hitting a well-configured IDS/IPS appliance.

snort can easily detect your port scan in progress with the sfPortscan filter (the -sS is practically a "portscan in progress" signature), and in addition to logging your attack, it can be configured to perform an active response.  These responses can be as simple as sending you an RST, or as rich as the "react" rule.  The "react" response's default behavior is to respond with an HTTP 403 Forbidden message, but they can also configure it to send any arbitrary data desired.  The reaction behavior is not limited to port 80 requests, either.  snort will send the reply regardless of port number.

To test this theory, while undertaking a portscan of the target, from the same machine that's doing the scanning, try opening any old port on that target with a browser or netcat.  If you receive the HTTP 403 Forbidden response from a non HTTP port, that's likely what's happening.

I am guessing that nmap doesn't interpret the response, it only reports that the socket connection was established, therefore it is reporting it to you as an open port.  Rather than guessing, however, you could set the --packet-trace option on nmap to see what you're actually getting back.

You can read the snort manual here.


Are all security requirements expected to be testable?

Absolutely not.  Security is in general not something that can be verified through testing.  As Dijkstra once wrote, "Program testing can be used to show the presence of bugs, but never to show their absence!"  This is especially true for computer security.

There are a whole bunch of misconceptions embedded in the idea that requirements need to be testable:

Wishful thinking.  Gee, wouldn't it be nice if all of the requirements I have were easily checkable using some black-box tests?  Wouldn't it be nice if I had a pony?  Sorry, that's not how reality works.  Suck it up and deal with it.

I'll put it another way.  Have you heard the story of the late-night drunk who lost his keys while leaving the bar on his way to his car?  Bystander asks him why he is looking under the lamppost 100 ft away, and the drunk says "that's where the light is".  People get like that.  We have to remember that requirements analysis is not about what's easy to check.  Rather, it's about what we need.  It is about the customer's needs.  That's why they are called requirements, not achievements.
Misplaced expectations.  Most developers spend most of their life building features.  If you want to check that the feature is present and appears to work, testing is a great way to do that.  Consequently, many developers get used to thinking of testing as the way you go about all kinds of quality assurance tasks.  But that's narrow-minded, blinkered thinking.

Security is not a feature.  Features are about ensuring that good things happen when the user asks for them to.  Security is about ensuring that bad things never happen when the user wasn't expecting them.  You can't verify security with feature testing.

Put another way, security is about ensuring there are no surprises, when there is a malicious adversary out there poking at your system in unexpected ways.  Testing is about poking at the system in expected ways, and consequently doesn't tell us very much about what happens when the system gets poked at by an adversary.
Thinking that testing is all there is to quality assurance.  Ensuring that a system will be secure is in some ways a quality assurance problem.  When it comes to security assurance, testing often isn't the right tool for the job.

Security demands different methods.  Some of the methods that are most appropriate to checking whether a system is secure and meets its security requirements tend to involve: threat analysis, architectural security analysis, security code review, application of static analysis tools, fuzzing, and penetration testing.  Folks who aren't familiar with the security domain tend to be unaware of these methods, or don't realize the important role they play in evaluating the security of a complex software system.

Gary McGraw likes to call penetration testing a "badness-ometer".  It's a meter with two extremes: on one end, "Your Security is Really Bad", and on the other hand you get "Don't Know".  It can never tell you your security is good; it can only deliver bad news, but the absence of bad news does not mean you have good security.

There are some security requirements that can be verified through testing: primarily, "security features".  But security is about a lot more than just security features.  Software assurance is fundamentally different from security features.

Example: One plausible requirement is "the system should contain a way to reset my password".  That's a feature, and one that can be reasonably checked with testing.  On the other hand, another plausible requirement is "the password reset feature should not endanger security".  That's a security assurance requirement, and no way you're going to be able to check it with testing.

So, no, security requirements aren't necessarily testable.  There are plenty of security requirements that cannot be easily checked for compliance using testing; other methods are needed.

P.S. Last word: You must read Bruce Schneier's essay on security assurance.  It's exactly on target.  Schneier points out that we often think about security the wrong way: we start out by assuming the system is secure, until proven wrong.  Schneier points out that this is backwards.  He suggests that if you want your system to be secure, a better way is to start by assuming it is insecure, until proven otherwise.  (And, I'll interject, testing ain't gonna be terribly useful at proving a system is secure.  Just a fact of life)


Decrypt TLS traffic on same machine (Mac + mitmproxy/other)

As the system proxy settings seem to affect the application, you can run any intercepting HTTP proxy (I'd recommend Burp proxy, but you can use mitmproxy, too) on your mac.

Set your system proxy settings to 127.0.0.1 and port 8080 and start the application.

To decrypt TLS, you also need to import the root certificate of the proxy into your trusted certificates.


How to use OpenSSL generated keys in Java?

If you have a public key in this form (and not within a certificate), I'd recommend using BouncyCastle's PEMReader. Its readObject() method can read a lot for formats: public keys, certificates, private keys (although you may need to use the method with a password)...

If you don't want to use BouncyCastle, you can read certificates using a CertificateFactory (see examples). With a certificate in PEM format in an InputStream:

CertificateFactory cf = CertificateFactory.getInstance("X.509");
Certificate cert = cf.generateCertificate(inputStream);

For private keys, if your private key is a PKCS#8 structure in DER format, you can read it directly using PKCS8EncodedKeySpec. For example:

KeyFactory kf = KeyFactory.getInstance("RSA");
// Read privateKeyDerByteArray from DER file.
KeySpec keySpec = new PKCS8EncodedKeySpec(privateKeyDerByteArray);
PrivateKey key = kf.generatePrivate(keySpec);

You can convert your private key into PKCS#8 using openssl pkcs8 -topk8 (remember -outform DER, you may also want to check the cipher suites as not all might be commonly supported by both Java and OpenSSL).

From a keystore usage point of view:

If you don't want to do much programming for handling the keys, to go between Java and OpenSSL, it's convenient to use the PKCS#12 format.

If the keys and certs you have produced with OpenSSL are not already in a p12 container:

openssl pkcs12 -export -in cert.pem -inkey key.pem -out store.p12

In general, you can make use of the directly, using Java's "PKCS12" keystore type (instead of "JKS" by default).

If needed, you can convert this PKCS12 keystore into another format (e.g. JKS) using keytool (Java 6+):

keytool -importkeystore -srckeystore store.p12 -srcstoretype PKCS12 \
     -destkeystore store.jks -deststoretype JKS

(Essentially, the opposite operation as the one described in this question.)

Either way, whether from using PEMReader or by loading your key/cert from a KeyStore, you should be able to get instances of PrivateKey and Certificate (or PublicKey directly).

You can verify the signature of a Certificate has been done using by the private key matching a given public key using its verify(PublicKey) method.

With them, you can also use the digital signature API. It's a more general API for any document signature, and I wouldn't necessarily verify a certificate signature with it (I'd rather use the certification path API for this, since it will also build the chain).


Differentiating server and client in Mutual TLS authentication

1.
No, it's generally not possible, as long as all the certificates are generated with proper Extended Key Usage (EKU) X.509 field value and all your TLS servers respect RFC.

For a client certificate, EKU should contain the TLS WebClientAuthentication value, and for a server certificate, should contain the TLS WebServerAuthentication value.
(Note that I'm providing human-readable description of the fields and values, not the actual OID values.)

It is common for certificate authorities to include also TLS WebClientAuthentication value in a server certificate, which is not bad in and of itself (at least personally I don't see an attack scenario here), but not vice versa.

Take StackExchange certificate as an example:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication

2.
Also, a server certificate contains the domain name of a server in either the Subject or in the Subject Alternative Name X.509 fields. For StackExchange it looks like this:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        <...>
        X509v3 Subject Alternative Name:
            DNS:*.stackexchange.com, DNS:stackoverflow.com, <...>

Here, the Common Name in the certificate equals to *.stackexchange.com, and Subject contains the Common Name.

Now, to start issuing client certificates, you usually have to come up with a naming scheme, i.e. what you put in the Subject field and the nested Common Name field. How you do that is completely up to you, but better make sure that under no circumstances could a Common Name within a client certificate coincide with a Common Name of one of your domains, in case either your CA or some of the TLS-enhanced applications in your infrastructure do not obey RFC strictly.

A simple way to ensure this is to put the full name of a user into the Common Name and then make sure that each client certificate issued either does contain a space, or doesn't contain a dot. As far as I know, at least one of those two requirements could be satisfied with pretty much any full name which exists in the world.


Blocking ports makes the domain almost 100% secure?

If a port is not needed, keep it closed.

However, for day-to-day operation, you'll need to have a few ports open - 25 (SMTP), 80 (HTTP), and 443 (HTTPS) for example.
Via these, a payload can be delivered - viruses spreading by mail being a famous example, XSS attacks another one.

If you completely disconnect your computer from the internet, you're pretty safe nowadays, as most attacks are made via the net. But complete disconnection is rarely feasible - you wouldn't be able to browse the web, or to offer an online service (like a website).

Even if you can afford to have your computer completely disconnected, a number of attack vectors remain. Gullible users/operators come to mind.


Is it safe to include timestamps in error codes that are shown to the users?

I don't see an issue here because the user will know the exact time they did something. Considering that a server needs to sync their time with an authoritative time source, there will be nothing "leaked" to the user that the user won't already know.

If you wish to hide some aspect of your server (like what time zone it resides) you can process your logs as UTC time as a generalized time format.


To choose a specific certificate among many

The selection which certificate is send to the client is done at the TLS level based on the information in the ClientHello. Since there is no distinction in the ClientHello between these the clients B and C it is impossible to decide which of these certificates to serve based on these information.

Depending on the environment you are in and the server software you use you might be able to make this decision based on the IP address of the client. For example if your are able to divert the incoming connection to a specific local IP and port based on the source IP of the client you could then setup a server to provide different certificates and these ports. But, the exact setup depends on your environment and is off-topic here.


is it possible to craft exploits for non-open source C/C++ software without fuzzing?

Yes, it's completely possible.  You can read through all of the assembly, determine what conditions are not accounted for, and then exploit them.  In fact, even when using fuzzing, you will need to read through the assembly to figure out a) is there an exploitable bug, and b) determine how to create that exploit.

All fuzzing does is help you determine where error conditions might exist by trying as many inputs as possible.


How to detect Meterpreter and similar malware?

First of all 'meterpreter' is not malware. I gather you mean how to detect open Meterpreter sessions between a compromised machine and the attacker.

Most antivirus can detect meterpreter payloads in memory - they are public, and that's why Metasploit has special polymorphic engines to try to hide the payloads.

A nice factoid: Commercial tools like Canvas exploitation framework make special agreements with antivirus companies to have them not detect their payloads.

Also, you can detect things on the network level if the session is not encrypted (defaults to SSL nowadays): most IDS can detect meterpreter, Snort has signatures for example. You can also detect the initial meterpreter DLL upload.

Also, tools exist for the job: Antimeter - http://packetstormsecurity.org/Win/antimeter.zip - it can detect processes that have the malicious DLL injected and kill them.

On the host, netstat and Process Explorer will show funny connections and DLLs loaded.

Finally, it isn't true that nothing ever touches the disk: The script first uploads the malicious DLL on disk and then injects it into a process.


Storing RSA private/public key pairs in a file, on linux

There's always a chicken and egg problem when you want to store private keys securely, but the app needs automated access to them. If you poke around this site you'll find plenty of related questions, for example:

Is it possible to automate use of passphrase-encrypted private keys?
automated decryption
How do automated systems store their keys securely?

Ask yourself what your threat model is; if you're only worried about remote attackers, then focus your efforts on hardening the perimeter of your server. If nobody can get in to your server, then encrypting it with AES might already be overkill.

If your threat model includes malicious users on that system, users introducing malware onto the server, or if whatever app the server is running is complex enough that it could become compromised, then protecting the keys at rest becomes a good idea. As you say, nothing is 100% secure; a software-based approach will always be breakable by someone with root access to the server and enough time to study memory dumps of your program. It sounds like what you're doing is reasonable. Some possible improvements:

Rather than have the AES key embedded in the source code, have an admin enter a password at process startup that is used to derive the AES key. That way an attacker really does need to be on your server taking memory dumps rather than being able to extract it from your binary or source code, which I assume is easier to acquire than a memory dump of a prod server.
You could maybe encrypt each private key with its own AES key just to increase the barrier between getting one key and getting all the keys.
The next big step up would be to generate the keys on dedicated crypto hardware so that the private keys are never on the server at all. Cheap option: a bunch of PKI Smart Cards dangling out of the server on USB dongles. Expensive option: a network HSM.


Are there open by default ports with Centos 7's firewalld?

My CentOS 7 apparently came with ports 10010-10020/tcp, and services ssh and dhcpv6 open on the public zone, the default active zone.

You should specify which zone you are asking about, as there are 9 predefined zones, as of v.0.6

8083 and 8086 are both used by ITunes, according to this source.

One of the first tasks when setting up a server connected to the internet is to configure the firewall. In my case, for example, it was a VPS that should only be accessed from my home network, so I activated and opened the home zone to my local network IPs, and closed the (default) public zone to everything, loosely following this guide.


What are the security implications of people downloading addons, wrongly thinking that they are safe?

If people do not read the big fat warning that is displayed on every installation of a Addon or Plugin by Firefox, they have lost. Addons are full programs that can do anything, you have permission to do.
The warning message is really obvious:

You should only install add-ons from sources you trust.
Evil software can harm files on your computer or violate your privacy.


Is it a bad idea to provide a "testing" OAuth ID and secret?

It's a perfectly reasonable use. We actually have localhost as the endpoint for our testing API keys, and our OAuth provider allows plain http for localhost callbacks, so it makes testing very straightforward.

You can easily revoke the credentials if they're compromised and you don't really need your company name on the display name either.


How to disallow specific ssh ciphers and/or MACS (blacklist approach)

It depends on what OpenSSH version are you using. In versions below 7.5, you have no other option than you already said -- list all the white-listed algorithms.

Since OpenSSH 7.5 you can use - modifier, which will blacklist "bad" algorithms from the default set, such as

Ciphers -arcfour
MACs -hmac-md5


How is OAuth2 secure vs man-in-the-middle attacks

You brush upon an important part of the OAuth2 standard.

Namely, all access is bound to IP and is time-limited. (as in x minutes).
After that you need to request a new token through the authentication mechanism.

Another part of the standard inplace to secure against eavesdropping is that all OAuth2 Acces providers MUST implement a TLS or SSL connection. (no HTTP allowed).

But you are correct in that if someone can actually eavesdrop the full connection from the start (as in first authentication with the full oauth  authentication and authorization process) has all the information to connect to the service from your IP.

This is however the same whether you would logon directly to the service.


Mallory stops capturing with Segmentation fault Debug: UDPprotocol[m]?

After encountering a similar issue, I suspect you might not have installed Mallory's certificate in Windows. This is located in

mallory/current/src/ca

Installing this resolved the seg faults I received when testing iOS.


Does any database let you disable non-parameterized queries and therefore disable SQL injection?

There's no DBMS that does that.

The main problem is that there is no way for a database server to tell what parts of an SQL query were generated from user input, so no way to disallow queries that were formed with user input. Once your pieces are added into one string, you can't get it apart to work out what was what any more.

However, what a DBMS could perhaps do is observe that the majority of SQL injection flaws are in the form of literal values:

"SELECT * FROM things WHERE id='"+id+"'"

and ban this by disallowing literals (at least strings and ints) from queries. This would be a bit inconvenient in that you would no longer be able to write queries with static literals in:

"SELECT * FROM things WHERE id=? AND active=1", id

instead you would have to use a parameter for everything:

"SELECT * FROM things WHERE id=? AND active=?", id, 1

This would definitely be an interesting feature for a DBMS to introduce as an option. However, it still would not catch user input used for other purposes, for example column names:

"SELECT * FROM things ORDER BY "+sortcolumn

which happens more often than one would like.

  The network protocol of the database must have the ability for the driver to communicate that the parameters in the query were replaced by the driver safely and not by the calling code.

Or, better, use a protocol that passes parameters separately to the body of the query. Some DBMSs and data access layers do this, some don't.


Does Using VPN on a Dubious Custom Mobile ROM Reduce the Risk to the Network?

A VPN sits on top of, and is dependent on, the Operating System and the hardware. If the Operating System or the hardware is custom, it can simply choose to ignore the VPN for its malicious activity.

That means that it is possible for the compromised phone to attack the network at will, targetting the WiFi Access Point/Router or creating an "Evil Twin" network in order to capture traffic of other nearby devices.

Note that just having a malicious device does not mean that all other devices are instantly compromised. Those other devices need to have vulnerabilities that the malicious device can access. So you can't say that the situation reesults in "compromised" devices, but rather that they can be attacked.


Why would an attacker ever want to sit on a zero-day exploit?

It's more likely that you'll burn a 0day by using it than by sitting on it.

There's a fine balance between sitting on a 0day so long that it gets discovered by someone else and patched, and using it too early and unnecessarily, burning it. The balance tends to weigh in favor of waiting longer, since a good 0day is going to be obscure enough that it won't be quickly found. The biggest risk actually isn't discovery in that case, but obsolescence when the vulnerable code is re-written or removed for completely unrelated reasons, and the 0day exploit no longer works.

Most of the time, however, an attacker simply doesn't need to use it. If I have a valuable Linux local privilege escalation exploit, why would I use it when a little bit of extra reconnaissance tells me I can use an old exploit against an improperly patched privileged daemon? Better to keep it in the rainy day fund.

There are a few other reasons 0days may be kept for long periods:

Some people simply hoard 0days for the sake of it. This is all too common.
Maybe you borrowed the 0day from someone, in which case burning it would piss them off.
Sometimes a 0day broker is sitting on them while waiting for the right client.
The 0day may be useless on its own, needing to be chained with other exploits to work.

There was some interesting research presented at BH US which analyzed the life of 0days.


How do attackers gather remote feedback for identifying and exploiting buffer overflows?

You mentioned the most common answer in your question - for things like firewalls, proxies, high end servers etc., attackers will acquire them. They may then lease out shells for practicing. The market in this side of things is incredibly professional and well organised, with entire trading platforms set up to manage tiers of researchers and exploiters.

The route when an attacker does not have access is educated trial and error - for example the attacker may know that an appliance is based on a particular OS, so makes some educated guesses at stack sizes etc. to build a remote shell exploit and NOP sled of a size that may work and just try it and see if their exploit code returns a shell.

If at first nothing happens - try again.
If the server fails to respond - they may be close, but causing a problem - try again
If the shell is created - profit!


What is the protocol used for authentication/authorization of my internet access using account inside web browser?

This technique is called a Captive Portal.

There actually is an RFC standard for this since 2015. This RFC extends the DHCP and IPv6 RA protocols to inform the client about the URL of the captive portal as soon as it connects to the network. But this method is not yet very widely used. I am not even sure how widely it is supported by end devices (it would need support from both the operating system and the web browser). The usual procedure is to do it with a HTTP redirect like this:

When you connect to the WiFi network, the router (acting as a DHCP server) gives you an IP address. But that IP address gets marked as "unauthenticated" by the router.
When an "unauthenticated" IP address makes a http or https request to an external website, that request gets intercepted. The router replies with a redirect to the login page. Depending on your browser's security settings, this might generate the "Your connection is not secure" error on HTTPS requests, because the reply doesn't come from the website it is supposed to come from.
When you enter your login credentials, your IP address gets marked as "authenticated" and can now access websites normally.

The "You must log in to the network" below the address bar is a special feature of Firefox called "Captive Portal Detection". It works by requesting the URL http://detectportal.firefox.com/success.txt and comparing the response with the expected one. If the browser receives a redirect or a login form instead, it assumes that the user is blocked by a captive portal.

  Are there any software or configuration which can skip user name/password prompt and authenticate automatically under windows or android

I don't know any, but if you use the same wifi regularly, then you could do it with a little shell script which uses wget to POST your login credentials directly to the captive portal URL. But you would need to write this specifically for each network, because the login URL and the POST fields will be different.


Can ISPs replace a website's HTML/JavaScript/HTTP headers with something else?

Your ISP is per definition a MITM (man-in-the-middle) and therefore can serve you any content it desires.
You mentioned HTTPS and this is of course a game changer. Yes, the ISP can server any arbitrary content when you access e.g. Facebook, but it does not have access to the private server certificate of Facebook and your browser will detect that it is not speaking to the correct server.
Now comes the critical part - the user will get a warning and has to decide what to do with it. If the user ignores the warning and tells the browser to load the fake website nevertheless, the browser will comply. A security aware user will realize that something strange is going on, leave the site and maybe even investigate further.
This means, your ISP can serve any content it likes, but as long as you are using state-of-the-art TLS encryption and validate server certificates, you have the ability to detect that some tampering took place.


Can a third party passively read transmissions if WEP / WPA / WPA2 key is known?

The simplified answer for home routers goes something like this:

In the case of WEP it is trivial to decrypt the traffic being transmitted over the wireless network, since the WEP key is used for encryption of packets.

In the case of WPA it is possible, but not as easy as WEP. WPA makes it harder by introducing a four-way handshake during the authentication phase. In this phase, your computer and the access point "agree" on a key which you will use to send future communications to each other. The problem is that if an attacker intercepts the handshake (and knows the pre-shared key), they can figure out what key you're using for encryption and therefore decrypt your data.

Is it possible to avoid this?

Yes. There are other authentication protocols for WPA which are not centred around a pre-shared key - too many for me to provided detailed answers on each. Have a look at "Extensible Authentication Protocol" (EAP) for more information on these.

Depending on the authentication protocol, it can become very difficult to intercept and decrypt traffic. For (an oversimplified) example, public key cryptography may be employed during key exchange in order to ensure that the handshake is properly authenticated; or Diffie-Hellman might be used to set up a an encryption key in such a way that, even if all of the handshake is sent in "clear-text", the key is not known.

These authentication protocols are commonly used in enterprise wireless setups, where a pre-shared key is obviously not sufficient for security.

Final Note: The problem you're describing is not exclusive to wireless networks. Whenever there is encrypted traffic between two entities, we must consider the security of the key exchange in determining the security of the whole system.

As was pointed out, HTTPS would be adequate to hide your traffic: even if the wireless packets can be decrypted, the content contained within the packet would be encrypted and therefore unreadable** (** not entirely true).

Further Reading:

https://crypto.stackexchange.com/questions/5927/why-does-wpa-psk-not-use-diffie-hellman-key-exchange

Four-way Handshake in WPA-Personal (WPA-PSK)

What are the difference between WPA2-PSK and WPA2-EAP-PSK?


Is it OK to tell your password to an admin?

I have working with many companies, and the technical answer is that no one should know your password.

In practice, you really have to weigh that against any real threats, and why you are giving it to him. Also, if your password is used for many things (you should not do this either), like your banking, then really NO.

If you really ever have doubts, you can do one of two things: You can temporarily change it, so giving it to him is not an issue, or you can type it in for him. I often ask people to type their passwords in for me.

That said, an administrator can change the password when they need to, but the only problem is that they have to get the user to change it again.


Securely Connect Employee PC to Business Private Network

I'm thinking that business hardware can be considered secure in a private network behind a firewall, whereby all incoming/outgoing connections are done via VPN.

The assumption that the business hardware has no connectivity apart from the VPN cannot be made in all environments. In some cases there is some form of captive portal which require non-VPN access first. There might also be polluted DNS caches or use of local DNS server. See this talk (presentation and white paper) from Blackhat 2020 for more.

What I'm more worried about though, are employee PCs. I'm currently considering a VNC client ...

This is even more tricky and there are a variety of approaches with different risks.
The most secure version is probably to temporarily take full control of the computer, i.e. essentially make it "business hardware". This can be achieved by booting an alternative OS from an external medium, typically a USB stick. To do this often some pre-configured Linux system is used. There are also companies which offer products based on this idea.
Mostly secure is also some kind of remote desktop, i.e. virtually sharing screen, keyboard and mouse (and maybe audio and local printers) with some remote computer or VM in the company, for example with protocols/applications like VNC, RDP, NX or even from within a web browser. One commonly exploited weakness here is the access control, i.e. such systems or often accessible from the internet with either no or weak passwords or the credentials can be retrieved with the help of very common phishing mails or if the access is used from a compromised system. Thus it is strongly recommended to have some kind of 2FA/MFA in this case.
Tunneling the remote desktop protocol inside some VPN and/or SSH can reduce the weaknesses of the protocol itself (like no or bad encryption, or bugs like this) and can also add additional authentication on top. It does not by itself reduce the risk of compromised credentials, so 2FA/MFA is still recommended.
Additional weaknesses with this approach occur if the client system is somehow compromised. Apart from grabbing the login credentials it can also do screenshots, hijack keyboard and mouse, make use of weaknesses in the sharing implementation for example by attacking channels for sharing audio or printing.
Less secure is the option to simply install a VPN client on the users system. Assuming that the users system is compromised this essentially allows an attacker an easy way into the company network.
And then there is the option to providing only limited access to specific applications, instead of to the full computer and network in case of RDP or VPN. For example it might be possible to limit access only to mail and to some specific business applications. Apart from access to applications which are in the cloud anyway (i.e. Microsoft 365, Google Workspace etc) various companies (like ZScaler, Cloudflare, Akamai) also offer limited connectivity to company-internal applications this way and also offer protection of the web traffic. To prevent credential phishing 2FA/MFA is recommended here too.


CEH as a requirement would suggest that the business area does not totally get what it is they are needing. This exam does nothing to confirm that the person holding the certification can effectively or safely deliver a test.

CEH is based on being able to retain a huge amount of detail that is not directly valuable in the real world. Examples would be around being shown a snort command with flags and being asked to remember what each flag does. Personally I find using the man snort or snort -? works just as well.

The exam was focused on tools and flags for tools - so if your aim is to understand how 200+ tools can be used rather than the best of breed then go for it. Again, 20 different ways to port scan a system rather than understanding how best to use AMAP and NMAP was a frustration, and the section on the use and deployment of real world 'Trojans and Viruses' was a worry as I would not expect a tester to be running around on an internal live network with real Trojans and Viruses!!!

In terms of comparison to CISSP and Security+ - both are focused on information retention and knowing the exam answer rather than the real world way of doing it and I would say to an extent that CEH is the same.

As an alternative and potentially more benefit to you in terms of wider progression, could be gaining the OSSTMM Professional Security Tester OPST which tests your ability to complete a number of real world exercises using the tool of your choice. The exam paper is also marked by a real person and graded rather than a multiple choice computer scored approach or the Global Information Assurance Certification GIAC route. This is a SANS based approach where you can complete training courses run by SANS or have the knowledge required and then complete the relevant GIAC exam. For Penetration testing the relevant course would be the GPEN Certification. I have not personally completed the GPEN but do hold the Certified Intrusion Analyst GCIA award and found the mix of knowledge and application to be of real value.


What are the security risks of resetting your password every time you login?

Slack does something similar: instead of logging in with your password, you have an option to receive an e-mail to a registered account with a one-time login link. Clicking on the link logs you in. So this is used a bit :)

The main issue with your suggested scheme is indeed the convenience issue. Notably:

Login delay. Depending on current server load and your email provider, it can take between 5 seconds and 10 minutes to receive an e-mail with a reset link. If you're logging into something like your bank account, which you log in at least daily and always log out, this wastes quite a bit of time unless your workflow is well-planned around it.
Password reset procedure might get broken after site update. Broken login is likely to be spotted immediately, but password reset is used much less often, and this would take longer time to spot and fix.
Password reset procedure might be insecure itself. Some sites would even generate and send you a new temporary password by email (ughh!) - and some of those passwords I've seen were very weak.
Password reset procedure might be quite complex (asking username, security questions, some other info about you, then letting you to choose a password, and then you have to log in with this password). This would make login quite burdensome.
In this scheme your email is essentially the key to everything, and if it gets hijacked, blocked or deleted (such as when Lavabit shut down their email server - imagine if you had that email as registered?), you're now in a really big trouble, since you don't know any of your passwords and have no means to easily reset it.
Finally, after many resets your account might get locked on the server - it is unusual behavior for users to reset password daily, so it depends on how zealous their fraud department is. In this case the customer support would not be likely able to do anything for you besides unlocking your account once, and telling you that it might get locked again tomorrow if you reset your password again.


It depends on where the receiving phone is located.

In the USA, you aren't likely to ever see a spoofed SMS work, it's locked down pretty tight.  In other countries though, there is less validation at the carrier level.

Spoofing of any message is usually done by one of 3 ways.

Pretending you are a proxy relaying the message for someone else.  This is commonly how email spoofing is done, as there's commonly no validation, and email passes through multiple separately controlled networks.
Cloning a legitimate users credentials and pretending to be them, so that the service provider believes it's a legitimate message from their user.
You can run a fake base station - Phones will connect to your base station as it has the strongest signal (if it's closer than a legit tower) then you can spoof any sender address you like. There have been many instances of this happening. For example, in the People's Republic of China where they recently locked up 1600 people for running fake base stations involved in SMS spamming.  This only affects the end user the base station is close to, you can't use it to send an SMS to someone across the country.


A potential possibility of improvement of PKI for personal communications

You are proposing that, instead of using a standard PKI, where someone (goverment or not) controls a CA that signs certificates, would be simpler to just have a (big) list of government recognized public keys associated with the related person. In other words, a big searchable list of certificate contents. You claim that this would avoid "the difficult issue of trust on the common CAs (or their equivalents)"

First of all, to be sure you are checking the right and trusted list, the search server would need to be authenticated somehow (to fully avoid PKI, that is used in TLS/SSL, probably you would have to put the certificate of the server in your trust it and check out-of-bounds if it is valid). It is not clear how would you solve this in an scalable manner without using PKI. It is possible, of course, but not easier or simplier than the standard PKI trust challanges.

BTW, part of my master thesis work is about how a PKI could be to solve some of the problems of standard PKI, and we use online servers to provide certificate status and discuss many problems with standard PKIs. In many ways your proposal fits with ours, except it is not targeted on solving the trust issues of PKI, but other problems. Part of the work is available here: https://www.cdc.informatik.tu-darmstadt.de/reports/reports/TheNotaryBasedPKI.pdf

While NOT solving the trust issue, your proposal adds many other problems:

1) It is not offline verifiable. One may claim that this is not a problem nowadays, when everything is always online, and while not strictly true, I agree that for most applications there is no big advantage at the offline characteristics of x509 PKI (thats why we proposed NBPKI too)

2) For signature/verification, you need to be able to verify at any time in the future if a key binding was valid when the signature was done. For some scenarios that can take years and decades between the signature and the last needed verification. That means that even if the binding between person x key is lost, the server still needs to at any time in the future be able to give the key that was valid in a certain time in the past. So, the list only grows; That is not good because it wont scale whell, will not be efficient;

3) You have a single trust point to be attacked. Not good at all;

4) To solve all this problems is exaclty why PKI is how it is. Instead of a list, you have proofs of link between each key and each person. Those are small, and actually EASIER to validate (cost less computational power and resources). Those proofs have a presumed valididty usually based on how protected the private key is, and can be revoked if needed using a list of revoked certificates (that tends to be smaller than a list of valid ones, and can be made smaller using OCSP).

You mention the problem that is hard to trust in the common CAs. That is not strictly true, and can be solved by some means: Federated CAs, or TSL (Trusted Services List, used on Europe) or just have a national root CA as is done in Brazil that signs all other trusted CAs, so you need only to trust a single trust point. If thats the main reason to choose your proposal, I don´t see a real advantage between having a single national CA and your proposal. Other than that, PKI has so many advantages over your proposal on real usage scenarios, that explain why it is widelly used until now.

Having that said, PKI have its own problems, but most of them are exactly on the centralization of trust in FEW points, and may be solved by more decentralized approaches. Your porposal is going in the oposite direction, by proposing centralizing even more the trust in a single list.


Validating correctness amongst untrusted answers

Distributed.net solved this by assigning the same search space to multiple users, and validated them that way. (They are probably still doing it.)

Depending on computation cost and participation levels, you might wish to double check only a fraction of packets. Comparing 5% should give you a statistically valid chance of catching a cheater. Be sure to randomly distribute the duplicate challenge blocks around, so that you don't only have User A validating User B's packets. Don't identify the test blocks in any way, such as sending a different size or range, or a cheater may tamper with them. And finally, know that one positive result does not indicate a malicious cheater. It could be a hardware or software problem. You need to see a pattern of abuse before you pull the plug on someone.

EDIT:

Here's a link to distributed.net's Operational Code Authentication document.  It describes the security mechanisms by which they handle validating work work distributed to untrustable clients.  Of particular interest are some of the other security problems they've identified, such as "solution stealing", where a malefactor distributes a modified client to someone else.  The modified client suppresses the "winning results" signal, and instead sends the results to the attacker, who unfairly claims and collects the reward for the find.


As per my answer on your other post - have a look at the anomaly detection stuff over on the Snort forums. There are many aspects you will need to consider so try building on the work they have already done.

You will need to understand 'good traffic' for your network during the 'initial tuning' phase, use whitelists and blacklists of signatures, and then build heuristic analysis if you want to alert on deviation from the norm.

This is very resource-intensive, and complex to maintain, which is why many companies now outsource this entire piece to the big managed service providers.


How much risk arises from password aggregation?

This is a difficult measure to quantify. Certainly, if the cryptography protecting your password store is poor, or in the case of a cloud-based tool their host system security is poor and their storage scheme allows an attacker to recover your password database, then all password data is freely available to the attacker and you have a near-100% compromise of everything stored there.

However, life is not necessarily that straightforward. There are two really important factors to consider:

Do you use two-factor authentication mechanisms for your accounts? For example, consider that your google mail account has 2-factor auth turned on. If its password is leaked, you have a problem certainly, but the attacker requires access to the other factor before they can gain access to the account. This is a defence-in-depth approach to your accounts, which you should use if you can.
What is the likely behaviour for yourself or other users if you do not have the convenience of a password manager? With a password manager you have no excuse to use anything but high entropy passwords. However, if you are required to remember all your passwords you will hit upon the human-brain-storage limit pretty quickly and find yourself using correct horse battery staple 1 for everything, adding a different number each time.

In this case, a password leak may give a persistent nuisance the chance to evaluate how you generate your passwords (badly, most likely. I'm as guilty as the next for this) and therefore probably log in to a great number of accounts.

  How do we evaluate the trade off between convenience and security?

I think I have answered the how above, but I'd like to add an additional consideration into the mix: it depends on what you are storing in your aggregated password safe. Despite the emergence of technologies like OpenID, almost every site wants an email address and password from you - the motivating reason behind this discussion.

That does not mean that all such accounts are created equal - indeed, 99.99% of "stuff" users register for online they don't actually care about one hoot, a statistic I made up just now. So on this basis, such a user would probably be well served splitting their accounts into three types:

Those which have direct access to their financial details and can cause considerable financial loss, damage etc - e.g. bank accounts, insurance, etc. I would probably include your email in this category.
Those which have access to large quantities of socially-identifying information and direct communication links to your friends, e.g. Facebook, LinkedIn. You might also include in this category accounts which have access to financial information, but need to go through a system such as 3D-secure to authorise payment, as this requires additional non-site-specific authentication.
Everything else, especially sites like this one that email you your password in cleartext.

On this basis, you could decide that the risk of storing your most risky stuff in a password manager is too great (and you can expend some of that precious human memory stuff on memorising a difficult to remember password and turning on two factor auth), so you don't do it.

You could then decide which, if any, of the socially identifying sites pose the biggest threat and optionally not include these.

Finally, all the junk sites that seemingly want you to create an account can have a randomly generated password of sufficient length.

Evaluating password managers themselves is a much more difficult proposition. I'd fit them into two categories:

Desktop. This benefits from the security advantage of being (mostly) not directly available all of the time which also adds to the inconvenience. You may be able to evaluate the cryptographic on disk algorithms used, but above all else like any encrypted data unless you protect the physical target and ensure the virtual target is malware free, you put your data at risk.

In addition, in a desktop-based solution it would be possible to harvest the entire database, something that is not so easy from a secure cloud based solution.
Cloud. These are less easy to evaluate as they are typically harder to reverse engineer. You do not have access to, or knowledge of, the underlying algorithms, transport mechanisms etc. However, these facilities are convenient. On the upside, a leak (however small) would put any cloud password management company permanently out of business, so they do have an incentive to stay well ahead of the curve.

As I say, cloud based service evaluation is a hard one to do and each type of manager has their advantages and disadvantages. This really boils down to deciding what risks you wish to accept and the level of convenience you desire.

Hopefully, however, this is food for thought.


PCI compliance when using credit card details on behalf of another person

Here are the PCI-related services your are providing to this client:

You have access to a third-party's card number.
You are initiating transactions on behalf of the client.

Based on the PCI SSC's definition of a service provider, you might be consider to be acting as a service provider for this client:

  [A service provider is a] business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data.

Your company needs to decide if it wants to assume the risk of acting as a service provider for this client. As stated in the comments there may be other ways you can perform the requested services without having to have the client's card number.


What are hardened ACLs for the Windows %systemroot% folder?

No such thing
I don't think that there is an official, Microsoft-supported way of doing this.
Here's an MS blog post that urges users to only use official hardening methods (namely  Security Compliance Manager and Security Configuration Wizard) (And AFAIK even those two don't touch the NTFS ACLs at all.)

Microsoft TechNet, Premier Field Engineering (PFE) blog, 2014-05-29, Why you should avoid manual ‘server hardening’ (Archived here.)

The security baseline for Windows Server 2012 R2 also mentions nothing about NTFS ACLs. So I guess you shouldn't touch them.

Microsoft TechNet, Microsoft Security Guidance blog, 2014-08-16, What's New in Recommended Security Baseline Settings for Windows 8.1, Windows Server 2012 R2, and Internet Explorer 11 (Archived here.)


What to consider when generating random code as part of two-factor authentication?

Summary. No, that code does not look safe.  It doesn't have enough entropy that will be unpredictable to the adversary.  I would not re-use that code.

The right way to do it. To generate a random code, I suggest that you read the desired number of bits from /dev/urandom.  This is a one-time code, and it needs to be random and unguessable and cryptographically strong.  That's exactly what /dev/urandom provides.  The OS manufacturer has already worked out how to do this securely, after great thought, and that approach has been vetted by security experts.  I suggest you simply re-use their existing work.

Analysis of second_factor_regenerate_token.  I don't know if I'm understanding the code properly, but it looks like it doesn't have enough entropy.  It hashes the user's username, user's password, HTTP headers, and the current time.  That's not enough entropy.

Remember that the purpose of a second factor is to prevent unauthorized individuals who somehow have come to know the user's username and password from gaining access to the system.  (If the unauthorized individual doesn't know the user's username and password, then we don't need a second factor; the first factor already blocks them.)  So our analysis should start from the assumption that the attacker knows the user's username and password.

Once we make that assumption, the only remaining entropy comes from the current time and the HTTP headers.  The time definitely does not have enough entropy: it will be known, or almost known, to the attacker (possibly off by a few seconds, due to imperfect time synchronization, but the attacker can just try all possibilities).  I don't know how much entropy will be in the HTTP headers, but it doesn't sound like a solid basis for security.

Therefore, based upon my interpretation of second_factor_regenerate_token, assuming I am correctly understanding how the code works, I do not think it represents good security engineering.  I would not re-use that code.


What to do when iPhone is successfully phished

From the scenarion you describe, she rather has been a victim of a drive-by download attack that leads to installing -in most cases- adware or spyware but this attack can be even more dangerous depending on the malware that has been installed.

This attack uses the browser vulnerabilities or the browser's plugins vulnerabilities using mainly malicious obfuscated JavaScript code.

The attack can be triggered passively by a simple visit to a given webpage as it happened for example on 2011 to Amnesty International's homepage where lot of visitors got infected by simply reading articles on their homepage.

In an other scenarion, the attack needs the visitor to be active (which is the case of you describe here): the visitors sees pop-up windows that a simple click on the OK, Cancel or even Exit (X) button will trigger the attack.


Ideally, no.
A honeypot is a word used to define the purpose of a machine, but has no bearing on the machine itself, how it's configured or any particular software running on it.

That said, someone creating a honeypot typically has the goal of luring targets into expending resources or breaking OpSec.  To do this, they would present a goal that appears to offer a significant reward and/or minimal effort required to exploit.  Provided the owner of the honey pot is not a very good poker player (knowing how much to offer without making the trap obvious), one could potentially measure the "too good to be true" value of a machine.

Sadly, though, if one were to compare this measure with the majority of internet connected hosts, a deliberately weak and valuable goal will be largely indistinguishable from one that is accidentally so.


Privacy-preserving authentication with unique user identification for Web applications

It sounds like what you really want to do IS authenticate people, then provide a method of submitting a vote which is not linked to their identity.

The whole anonymous voting crypto problem has been around for a while, and there's a lot of potential algorithms to solve it.  If you get ahold of an applied crypto textbook, there's likely an example of a similar problem in it.

There is a cryptographic technique which would allow you to authenticate a user, then could provide them a token which allows them to vote anonymously.  I think it involved 'blind signatures'.

EDIT: You may want to post in the crypto StackExchange site.


Should a host based firewall have an API accessible to other applications?

As with so many security controls, they should always be considered as part of a defence in depth strategy. A personal firewall on your machine adds useful protection, but should not be relied upon as the only protection.

(I say personal firewall here because the vulnerability you identify - if malware infects a machine and escalates privilege it can disable/modify a personal firewall running on the same machine - applies to all such products, not just the Microsoft one.)


What are the biggest unsolved problems in IT Security?

Social Engineering by far.

Humans will remain vulnerable to social engineering for a long time to come and as the saying goes, "Security is only as good as the weakest link."


Yes, this is a real problem and we have observed it in the wild.

As cloud-based malicious site detection systems get more prevalent, expect a corresponding increase in tightly targeted attacks that are invisible to such detection systems.

This kind of thing can be controlled by an .htaccess file in the payload directory.

HTTP Referer

Limiting access by referrer link (misspelled in the HTTP spec as "referer") won't work for phishing emails because there's never a referrer (unless the attacker uses a redirector service that happens to add one), but it could be done with a rewrite rule:

RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
RewriteRule "^"               "-"                [F,NC]

Restricting access by client IP

Here's another example that limits access by IP:

Require ip 127 172.16.0.0/12

This tells Apache and Apache-compatible servers that the current directory (and all subdirectories) should render a 403: Forbidden to any connecting IP that isn't localhost (127.0.0.0/8) or on the given private LAN IP space. An attacker could, for example, look up a region's IP ranges and explicitly require them.

If the detection system's IP range is known, you can reverse that:

# prevent access from these CIDRs
Require not ip 198.51.100.0/24 203.0.113.32/28

Solutions

  How can I as middleman verify whether a phishing site is valid if the scam listens only on the referrer link and blocks any other access methods?

You should do everything you can to look like a victim. If you have access to a VPN in the purported target region, use it. If you don't know how the attack is targeted, you'll have to guess.

Forging IP addresses is hard, but there's nothing to stop you from entering whatever you want as the HTTP Referer; it's just a header. If you have to guess, try the same page as you seek to visit. That at least works for most image hosting sites that are trying to prevent direct hot-linking of their content.


Storing KeePass database in cloud. How safe?

You can increase the resiliency of your KeePass database to brute force by increasing the number of PBKDF2 iterations when deriving the database encryption key from your password. You can do this in KeePass under File > Database settings > Security. Personally, I use around 5,000,000 rounds (1 s delay). Remember that mobile devices are slower.


Proper way to allow access to systems within different offices?

Separate physical locations can share the same logical network using a VPN.  A client's IP address can be used in a multi-factor authentication system, but a password and a Key FOB is more commonly used.


Does a website have to ask permission in order to access the microphone and webcam?

That's correct. HTML5 exposes getUserMedia API to access media resources on the host.

See here for a reference implementation. This is the code in action: https://webaudiodemos.appspot.com/input/index.html

In terms of what the spec say about the security, quoting from this website:

  Security

  Some browsers throw up an infobar upon calling getUserMedia(), which gives users the option to grant or deny access to their camera/mic. The spec unfortunately is very quiet when it comes to security.

  Permission dialog in Chrome:
  If your app is running from SSL (https://), this permission will be persistent. That is, users won't have to grant/deny access every time.

This is the issue to implement permission support in the spec itself: https://github.com/w3c/permissions/issues/62

However in practice, all standard browsers ask for permission via a popup box (or a infobar) before accessing the media resources. Hence, so far as one is using a modern browser, it should ask for permission.

If one is using a non-standard browser, modified version of chromium shell, or desktop based electronjs/nwjs apps, then it could be possible that the browser doesn't ask for permission, but again in such a case all other security gaurantees that modern browsers provide (eg. XSS auditor, CORS, Same origin policy etc.) goes for a toss.


iptables is a user-mode program that acts as an interface to the Netfilter hooks that the Linux kernel provides. By it's very definition, it cannot run in kernel mode as it is a user-mode program designed to interface with a set of kernel hooks.

iptables can only be modified by the root user anyway. If a piece of malware manages to elevate privileges that high, you are screwed anyway. It's impossible (or at least close to impossible) to defend against a malicious root user.


from another forum:

  TLDR: Look at the IdenTrust numbers if you want to know the real Let's
  Encrypt numbers.

  Not many people use Let's Encrypt's own root for their validation
  chain when they use Let's Encrypt certificates. The Let's Encrypt root
  is not propagated widely enough across clients.

  We (Let's Encrypt) have a cross-signature from IdenTrust, that's what
  most people use because it's widely trusted. IdenTrust issuance is
  otherwise very small, so you can effectively consider the IdenTrust
  numbers in charts like this to be a proxy for Let's Encrypt.

  -Josh from Let's Encrypt