Custom OAuth2 Authorization Server / Identity Provider

Bit of basics: Authorization: (Check if user A has access to resource Z). Authentication: check if the user who claims being A is really A.

OAuth2 is not an authentication protocol

From the oauth.net site:

  The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication. This has led many developers and API providers to incorrectly conclude that OAuth is itself an authentication protocol and to mistakenly use it as such.

OAuth2 describes how a third party application can request authorization to access a protected resource on behalf of a user. When the RFC6749 talks about authentication, is not authentication of the user, but the client application making requests to the authorization server.

Now, you didn't mentioned it but there's OpenId Connect, which is a

  simple identity layer on top of the OAuth 2.0 protocol. spec

The IdentityProvider is a concept introduced by OpenId Connect, and its not present on the OAuth 2.0 authorization framework.

Most of the time the Authorization Server and the Identity Provider are the same application, implementing both oauth2.0 and OpenId Connect specifications, and refered as the OpenId Provider or simply OP. An OP is a OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User.

Questions

  1 What do you think about the flow shown in the diagram? I would definitely appreciate any feedback

I think its quite good but, I don't really get why you segregate the Authorization Server from the Identity provider and I don't know how you will be able to create the session cookie from one application to the other. But, if you solve this in a secure way (which I'm not sure is possible) then its fine.

  2 I've tried to understand the concepts of Identity Provider and Authorization Server and how they interact with each other. I am not exactly sure who is supposed to generate the tokens (access and refresh). I would say it's the job of the Identity Provider since token is about authentication? If so, it would mean that the part of my diagram targeting the request/creation of the token is incorrect : Authorization Server would have to request the token from the Identity Provider, whereas now it's the Authorization Server itself which generates the token.

I hope that by now you know the answer. It's the authorization server who's in charge of creating access_tokens, because at first access_tokens where like door keys, they just grant you authorized access to a protected resouce. Thing is that with OpendId Connect an access_token includes claims about the user and also the means of how the user authenticated to the IDP.

  3 I inspected some web application (google, github, stackoverflow) to see how they deal with their own authentication system. Let's use the example of Stackoverflow. When I choose to log in using my stackoverflow account I expect the application to communicate with the Identity Provider which will provide the login form. The login form that is used is the one from the web-application itself, which means no redirection - we stay put, which makes sense yes. Let's go further, imagine I want to use Stackoverflow as "social login" for my application. The Identity Server I would reach behind the Authorization Server to authenticate should be the same as the one reached earlier when authenticating from Stackoverflow. I am wondering what concretely an Identity Provider is. Can it be that the client application itself plays as Identity Provider (since it hosts the login form)? Or is it just an API that provides endpoints for authenticating and generating tokens?

Maybe, StackOverflow knows. Keep in mind that there's a lot of authorization systems out there relying on Json Web Tokens that are not OAuth2.0. I'm not saying that's the case, but maybe.

On a final note Identity Server is an implementation of an OpenId Connect Provider (OP) in .Net (and netcore) by Brock Allen and Dominick Baier who choosed this name and added a little bit more of confusion to the mix!


Is using SecureString in combination with Xor considered secure enough for standalone Windows app?

Nothing you can do about it. DRM is impossible.
You can try to hide or encrypt your keys, but this only delays the inevitable. The data is on the computer of the customer/attacker, and as such can be found by them. Let me illustrate with some examples:

Just leaving the string there
Even a casual script kiddie could run strings over your application and detect the license key.

Using SecureString
This doesn't stop attackers at all, as SecureString isn't designed to protect against what you want to protect. The idea of a SecureString is to have the user enter some secret data manually (usually a password), and then wipe it from memory when no longer needed. This means if an attacker dumps the process memory after the password was entered, it will not be in the process memory anymore. Since you need to store your license key permanently in the application, it's identical to scenario 1.

Encrypting the string and storing the key in the application
This is like locking your house and hiding the key under the doormat. A determined attacker will be able to find both the encrypted blob and the decryption key, and then manually decrypt the license key. Or, an attacker can simply debug your application and wait for the application itself to decrypt the key and then steal it from there.

Encrypting the string and storing the key on your server
This is the same as 3., except way more difficult for you to implement. An attacker can again simply wait for the application to decrypt the license key and then steal it.

Why is this so hard?
Many many software companies try to implement DRM, and all of them get cracked. The reason for this is because any software that checks whether or not a check succeeded can be manipulated by the attacker to always make the check succeed. It is essentially impossible to make software that the attacker cannot manipulate, unless you use a system that is completely locked down from the hardware up (iPhone, Nintendo Switch, etc.), and even then attackers usually find weak spots that circumvent DRM.


Norms and Compliance for storing bank account details

PCI-DSS applies only to credit card numbers so you are not in scope if you are only storing bank account details. RBI regulates financial institutions, you are most likely not in scope for that either. However if you are storing bank account details (including names of your customers) you are in scope for Data Protection Laws.

However Data Protection Laws tell you to adequately secure information, they are not as specific as PCI-DSS.  A good starting point in terms of standards would probably be NIST 800-122.


secret key not available for decryption, but still shows up in GUI

--list-keys only lists public keys. To list secret keys, use
--list-secret-keys (or just -K).

If you don't have a secret key with ID 3810D17A, you can't decrypt the
message. Creating a new keypair would not help with this, unless your
correspondent is willing to re-encrypt the message with your new public
key.

If you do have that key, I'm not sure why the software isn't just using
it. The --list-packets option may shed some light on what's in the
message, how it was encrypted, etc.


Executing vs Extracting PE32/PE32+ executable

No, attempting to extract files from within a malicious EXE is not dangerous, unless there's a vulnerability in the tools you use and the malicious EXE is crafted to exploit that vulnerability. In general, for tools that are meant to be able to safely open files from arbitrary sources (and yes, unzip tools fall into this category), the only time opening a malicious file could be dangerous is if there's a bug in the tool's parser (and hopefully 7-Zip, etc. wouldn't have such an issue).

A program is an algorithm, like a recipe in a cookbook. A malicious program is one that tells you to do something like mix vinegar with chlorine bleach (don't do this!) and inhale deeply. Running a program is simply following the steps of the algorithm. If you run code that tells your computer to do a bunch of harmful stuff, you (or at least your computer) will be harmed, just as if you follow instructions in a cookbook telling you to breathe poisonous gas or create an explosion.

On the other hand, merely reading the program (in a hex editor, or an archive extractor, or something else) shouldn't do you any harm. It should be as safe as reading a recipe or other list of instructions - no matter how malicious, such as the bleach-and-vinegar example above - in a cookbook.

With all that said, you're talking about running an algorithm (7-Zip, for example) that takes another algorithm (the malicious EXE) as input, and does something with it. That "something" usually won't be "follow its instructions", but it's still possible for there to be security vulnerabilities in the program you use, such that somebody who knew what program you would use and where its vulnerabilities are could create a specially-crafted EXE that, when unpacked by your program, exploits a bug in the program to do something harmful. Bugs like that do exist, but they're relatively rare and exploits for them usually need to be pretty targeted at one specific program.

If you're trying to analyze a known or suspected malicious file and had this question, I can't really recommend you go ahead without doing a lot more research, because if your level of computer knowledge is such that you had to ask this question then you probably don't know enough to usefully perform malware analysis (for example, opening an EXE in 7-Zip will usually not tell you much of use) and also don't know what other precautions to take while doing so (at a minimum, mark the malicious file as non-executable so it won't run even if you accidentally double-click it and/or use a VM without network or host disk access so that even if it does do some harm the harm is contained).

On the other hand, tinkering is fun and a good way to learn things. Just, start with a "malicious" program that does something not-actually-harmful, and work your way up. Or, if you just want to know whether it's safe to open arbitrary files in 7-zip: probably yes, but make sure you're using an up-to-date version.


Before I answer this, I really need you to consider: what is your threat model here? Are you trying to be secure against a malicious user of the web app? Against somebody with the power to break TLS? Against a malicious browser extension? This is important, because the first and third are impossible and the second is almost certainly a waste of time. Is this just some best-effort-to-slow-them-down thing, like DRM, or are you expecting an actual security boundary here? Are you envisioning that, for some reason, the attacker can modify the request but not the response? If you're assuming the attacker has full control over the TLS tunnel - meaning they can inject malicious script into responses, as well as modify requests - this is flat-out impossible because there's nowhere you can hide a signing key that the attacker can't access and use to re-sign their modified message. For that matter, you also need to assume that the user has been able to previously communicate securely with the server for the purpose of key establishment; if that's not the case then the whole effort is also hopeless.

Signing the message body before sending is the right idea, but there are some problems you need to consider. Obviously each user needs their own key, tied to their account, so that the attacker can't re-sign the message with a different key. Additionally, the key needs to never be visible to the attacker, which means neither the key itself nor any value used to derive it can be transmitted in a request from the client.
Option:

Session-based symmetric: At login, server generates a random symmetric key (128+ bits from a CSPRNG) and sends it to the client. Server also stores this key locally, in a session variable (tied to that exact user session). Client caches this key in some local storage and never directly sends it over the wire. Client also initializes a counter. For all subsequent requests, client takes the message body and computes an HMAC (probably something like HMAC-SHA256) over the message + counter, using the key. This HMAC is sent in a header or some such, along with the current counter value. Server verifies that the counter value is greater than any previously seen this session (storing the updated counter in its session state) and then retrieves the symmetric key from session state, computes the HMAC itself, and ensures it matches.

Fast to compute and verify.
Transmits the key, but only once, and only server-to-client.
Cryptographically simple, relatively easy to implement correctly.
Requires a common function for all requests, so that the counter is always used and incremented correctly and requests don't arrive out of order.
Requires server state, which is generally contrary to the goal of using a JWT and does not scale well to a cluster or even just a large number of active sessions.

Stateless symmetric: As in #1, but the server keeps a secret symmetric key (shared across any cluster) and computes the session key by HMACing a string that the client will send unhashed with every request (could be the client's JWT, or even just part of it, as long as it includes the client identity and ideally some unpredictable value) with the secret key. Server still needs to send this session key to the client (and needs to do so every time it changes, if it does) but doesn't need to remember it locally. To avoid needing to store the counter value on the server, instead require that the client use a timestamp in the HMAC (and send it in plain text with the request), and the server makes sure that the timestamp is within some range.

Still pretty fast, though you now have to do two HMACs instead of one to verify each request (aside from any work that you have to do to verify the JWT, of course).
Slightly more complicated, but still reasonable.
Requires no additional per-user or per-session state on the server; suitable for clusters with only a little effort.
Introduces a single point of failure for all sessions, if the attacker can get access to the server's secret key then they can re-derive every victim's session key from their JWT.
Introduces the risk that the session key will rotate (when the JWT expires, as they are wont to do), which could invalidate legitimate requests. Can be mitigated by using some value that is still unique to the user and ideally to this particular session, and is sent by the client on every request, but does not change when the JWT is refreshed. This value could be part of the JWT or even just a random string chosen by the server and cached on the client during the session.
The use of timestamps rather than a counter or other proper nonce introduces a small opportunity for a replay attack, until the timestamp expires.
The use of timestamps requires that the server and client have well-synchronized clocks.

Persistent, wrapped asymmetric: At user account creation or password change/reset, the client creates an asymmetric key pair suitable for signing (such as RSA or ECDSA). The client transmits the public key to the server. The client also hashes the user's password client-side, twice, with different salts and/or algorithms. One digest is sent to the server as the "password" for authentication (will receive additional hashing server-side before authentication, just like a normal password). The other digest is never transmitted, but is used as a symmetric key to encrypt (wrap) the user's newly-generated private key. The wrapped private key is transmitted to the server for storage. At login, the client performs the same dual client-side hashing of the user's password. If the server authenticates the user, it sends back the wrapped private key, which the client decrypts using the never-transmitted digest, and then stores client-side for the duration of the session. The server also retrieves the user's public key from storage. At all points that are neither logging in nor creating/changing passwords, the client uses its private key (which the server has never seen in unwrapped form) to sign the request body, along with a timestamp or counter/nonce (as desired; see considerations above). The signature, along with its timestamp/nonce, is transmitted in request headers. The server verifies the validity of the timestamp/nonce, and then uses the user's public key to verify the signature.

Unlike the previous approaches, THIS WORKS EVEN IF THE ATTACKER CAN READ ALL SERVER-TO-CLIENT RESPONSES although it does still require that the attacker NOT interfere during account creations / password resets.
Unlike the previous approaches, THIS DOES NOT EXPOSE THE USER'S PASSWORD AT LOGIN TIME; an attacker who intercepts the login flow will not be able to impersonate the victim as the attacker (until the attacker brute-forces the password from the authentication hash) because the attacker won't be able to unwrap the private key and hence can't sign messages correctly.
Highly complicated and prone to cryptographic (or ordinary implementation) error.
Requires the server look up the user's public key on each request, though doesn't require storing any actual session state (assuming timestamps are used).
Requires additional asymmetric operations on both sending and receiving a request; could potentially be computationally expensive to perform a lot of these in rapid succession (for the server's sake, choose a primitive that is not too expensive to verify signatures of).
STILL BREAKS if the attacker can MODIFY RESPONSES (attacker will just inject their own script to steal the private key and/or modify and re-sign the request at the client immediately before sending).

As in #3, but use SRP (Secure Remote Password protocol) rather than the custom client-side hashing and key exchange, and use the computed key from SRP to sign (via HMAC; and heck, encrypt if you want to) the exchanges. Server and client both need to remember the SRP-derived key for the duration of the session, and never transmit it.

As with #3, is secure against an attacker fully breaching TLS on requests and able to monitor response plaintext.
As is normal for SRP, establishing the passwords (including handling resetting a forgotten one) can't be done within SRP and thus requires some other channel that the attacker can't be allowed to interfere with.
Requires storing server-side session state (the SRP derived key).
Can be used to provide an extra layer of encryption, not just integrity, to the channel (though you still need to be sure the attacker didn't ever inject malicious scripts at pre-login time or any other point where web content is transmitted in the clear).
Simpler to implement because you can use existing libraries for SRP, though still not trivial (there's probably a JS implementation of SRP usable in a browser out there already, but it's not built into the JS API library the way many primitives are).


Why does javascript not show an alert box?

javascrip%74 is not a valid scheme for any production browser.  It's being evaluated, in URL encoding, as javascrip%2574.

A list of valid protocols used in Chromium-based browsers can be seen in the following file; I've highlighted the line containing the 'javascript' protocol.   https://cs.chromium.org/chromium/src/url/url_constants.cc?dr=C&g=0&l=26

The processing of URLs, again in Chromium-based browsers, can be seen in the origin files: https://cs.chromium.org/chromium/src/url/origin.h?dr=CSs&g=0


The Storage Root Key (SRK) is used to wrap TPM protected keys which can be stored outside the TPM. That data stored outside the TPM can be decrypted by passing it back through the TPM again for a decryption operation.

Keys wrapped by the SRK can themselves be used to wrap other keys, too. This method of wrapping can be used to create a key hierarchy of parent key and child keys. To load a child, first load its parent. Once the child is loaded, the parent key can be unloaded from the TPM to free up TPM chip resources.


The USB driver code in an Arduino Leonardo just lives in the writable area of the ATmega32U4. If you're worried it's been compromised, you can reflash it via ISP (in-system programming):

  [this] happens thanks to a special piece of code that is executed at every reset of the microcontroller and that looks for a sketch to be uploaded from the serial/USB port using a specific protocol and speed. If no connection is detected, the execution is passed to the code of your sketch.

Unlike uploading a sketch normally, this doesn't require connecting the Arduino directly to your USB port, is unaffected by the (possibly malicious) bootloader, and results in a known-good bootloader being installed. If the Arduino were compromised and you plugged it in via USB anyway, it would appear with extra VID/PIDs in dmesg, but by then it may be too late to avoid taking over your system.


The client usually supports more ciphers than it announces because there is a difference between both.
One thing is the capabilities - maybe a better name would be preferences - being a list of those ciphers that the clients wants the other client to use when sending messages.
The other thing is the list of actually supported ciphers, which is usually longer because the client needs to be able to process additional ciphers in incoming messages.
For example, sha1WithRSAEncryption is known to be weak, so while the client is capable of processing an incoming message with sha1WithRSAEncryption, it does not list it in its capabilities because it prefers to use a better algorithm.

Half OT:
However, the S/MIME Capabilities attribute is not written by many email clients. I assume that this is because nowadays, with IMAP mail servers and mobile devices, emails may be written and read using multiple different clients, so sending one client's S/MIME capabilities may not make as much sense as it used ro in earlier days.


entropy change when reading from /dev/urandom vs /dev/random

/dev/urandom uses a CSPRNG (Chacha20 last time I checked) to generate a stream of random data from an initial seed and allows the user to read an arbitrary number of bits from it. /dev/random pulls data out of a random pool that needs to be replenished.

It is possible to read from /dev/urandom before the system has enough entropy to provide a secure stream of data, in which case the kernel log should show a warning about an uninitialized read from it. If this is a concern, for example in embedded systems, then you'll need to use a hardware random number generator to generate additional entropy before you let programs start using it.

Provided the system gathered enough entropy, you'll get cryptographically secure random data from urandom and information theoretically secure data from random. If you're using a non-information-theoretically-secure encryption scheme or you're not generating vast quantities of encryption keys, then you might as well just use urandom.

You shouldn't read from /dev/random or /dev/urandom directly since the kernel exposes a nice getrandom system call that you can use in your programs, and it will help you avoid some pitfalls when trying to read from the character devices directly.

This answer has additional details about the differences between the two RNG devices.


Mumble's home page states it uses public-key cryptography. This is done by using the TLS protocol, which is mentioned in the FAQ.

With public-key cryptography, the private key is always known by the server. Thus, a Mumble server administrator indeed has access to the private key - usually in the form of a X.509 certificate - which can be used to decrypt the TLS handshake to derive a session's symmetric cipher key. This key is used to encrypt and decrypt all data transmitted over the connection. In other words, an administrator certainly is capable of decrypting all traffic.

Also, nothing stops a server administrator to log and record communication on the server.


NAT in the context you describe (i.a. one external and multiple internal IP addresses) works by rewriting the source IP and port of an outgoing connection and adding a state so that replies to this rewritten connection can be mapped back in order to rewrite destination IP and port for incoming packets. This means that any connection attempt from outside must match an existing NAT state because otherwise no destination IP and port can be found. This makes scanning a computer behind a NAT impossible, because there will be practically no NAT states matching the source and destination used in scanning from outside.


How to find out what websites are associated with an IP that has port 80 open?

Try 127.0.0.1/site/index.php , seems default doc root is /var/www/html/site


Responder.py and MultiRelay are recompiled for win32, but I've used the Python scripts in Win10's Linux subsystem and they also appeared to work fine from there. I prefer purpleteam/snarf for NTLM Relay, but if all you want is hashes off-the wire then any pcap library/utility will be fine.

If you are PowerShell-fluent you can use Inveigh.

If you want to focus on what you can do without escalating privs then you can use NetRipper, net-creds, PCredz, or similar. Depending on the version of Windows and other factors (protected processes 1, protected processes 2, protected processes 3), lsass may or may not be able to provide passwords.


Where should a keystore (.jks) be stored in a repository

All the organisations I worked in store credentials or equally sensitive info in a well-known location outside the application's deployment directory and is secured per environment. Devs create the files themselves with dev credentials whereas the production ones are created by ops and secured so only the application has access.

If you want the application to run without config after checkout, you can embed some dummy copies that only gets used when the file cannot be found at the well-known location.


What are the differences between ssh generated keys(ssh-keygen) and OpenSSL keys (PEM)and what is more secure for ssh remote login?

The file format is different but they both encode the same kind of keys. Moreover, they are both generated with the same code: openssl (the command-line tool) is a wrapper around OpenSSL (the library), and OpenSSH actually uses OpenSSL (the library) for its cryptographic operations, including key pair generation. So there is no direct security difference.

We could argue a bit about password-based encryption of the private keys, but there is nothing really significant here.


I wouldn't trust too much in a website just because they state they are "the good guys". If I had an malicious server, I would definitely write the same thing.
Can you track down which of your internal machines is generating the traffic? If yes, here's few suggestions:

Log into the machine and run a netstat query (netstat -ano), then you will be able to find which process is connecting to that IP in that port.
Ensure you have anti-virus installed on the machine, if necessary, update it and run a full scan.

If you're not able to determine the source of the traffic, you can capture the traffic on the firewall and use wireshark to analyse what kind of data is being transmitted.


Is this a phishing attempt? if yes where to report?

It's a clear phishing attempt. Either your coworker's machine is compromised, or he subscribed to some innocent-looking malicious service that sends emails on his behalf.

Once you supply your password, it's submitted via non-secure HTTP to

www.collectablelegends.com.au/googledoc/gmail.php

and then you're redirected to

https://drive.google.com/?urp=http://www.collectablelegends.com.au/googledoc/Sec&pli=1

which is nothing special. If you were already logged in to your GMail account, that URL will show you your Google Drive, and a gullible user will think that he logged in using that phishing service.

As for where to report it, it looks like you already have the answer for that. Also, it would be nice if you report this to your coworker and/or the IT department in your company.


No, this is not normal behavior. Most likely, the server has been compromised, and it has a backdoor installed that forwards the connection to RDP server. Probably a reverse tunnel, given that the RDP port itself is exposed to the internet and forwarding from another port wouldn't be that useful (it would just conceal the connection a bit).

I would try to find out the backdoor, so you have evidence to present that the server was indeed compromised, then wipe & reinstall the server and use the experience to get that the RDP not published. If someone really needs to RDP to that server from outside the company, that should be secured over a VPN. If you hadn't noticed the compromise in the log, your first notice could be when you come and find the server ransomwared. Or that internal information have been leaked through it (in fact, who knows that they already did...).

Good luck getting that improved


How can trusting ONE certificate jeopardize everything I do online?

Trusting one site's untrusted (self-signed or blatantly invalid) certificate could potentially compromise the connection to that particular domain, however you're still safe for other sites, except in the rare case when the other sites embed content from that site with the untrusted cert. For self-signed certs the only danger is the initial trust you put in the certificate, since you have no way to verify if you're talking to a legitimate server vs. an MITM. Once you trust the certificate the first time your browser still checks whether the cert is the same on subsequent connections (if an MITM were to appear next time you won't get owned unless you also trust their own certificate). As far as cryptography is concerned the type of certificate has no incidence on which cipher suites will be in use, and HTTPS with a self-signed cert is no easier to break than HTTPS with a trusted cert.

The nightmare begins when you start trusting someone's CA certificate (by manually downloading the cert and importing it), in that case you're telling the computer "let that entity vouch for any website you encounter", and from there you're giving that CA the power to tell your computer whether any site you visit is trusted, since any site that has a cert signed by that CA (let it be for legitimate reasons or because of the CA owner MITM'ing you) is now automatically trusted by your browser.


The difference is exactly the same as the language suggest. "Shared key" means that the same key is used by several party. It doesn't tell you how the key was distributed among them.

"pre-shared key" means the key has been shared before the current operational context.

To go you two examples:

When you perform a Diffie-Hellman key exchange in an SSL connection, you actually generate a new key that is shared by both client and server without any of them having a previous knowledge of that key. That key is shared but not pre-shared.
If you protect a ZIP file with a password, this password becomes the shared key and it must be shared between all parties. That key is both shared (everyone uses the same) and pre-shared (its distribution isn't covered by the ZIP protocol and must be performed through a different secure channel before usage)

These are only two examples, there are many more.


Police forcing me to install Jingwang spyware app, how to minimize impact?

This may not be the answer you will be happy with but how about abstaining from having any undesirable data inside your phone in the first place and instead using the right tool for the job?

According to Wikipedia:

  The app records information about the device it is installed on, including its [...] IMEI, the phone's model and manufacturer, and the phone number. The app searches the phone for images, videos, audio recordings, and files [...]

So, instead of trying to tamper with this spyware in any way (which can get you in a much bigger trouble), simply don't do anything suspicious on this phone and let this app do its job. Prepare against it by not having any photos, videos, audios, file, etc., and instead use the right tool for the job. Use some other secure software/hardware to connect to internet, use encrypted email provider and do all of your communication through the computer where you can do communication safely, and store all of your files somehow in a safe place (encrypted, somewhere on computer or USB, etc). Pretend to be an obedient citizen and use the right tool for the job to do whatever it is you don't want your government to find out.

Some people may wonder why bother having a phone in the first place (and FYI, I asked the same question under OP's question, for clarification). My answer is:

to make phone calls (and have conversations which are not going to be considered by Chinese government suspicious, in case they are tracking that too)
to use it as a "red herring" - if police asks you to give them your phone you won't have to lie to them that you have no phone, or worry that they will find out that you tampered with app, or get in trouble if you don't have app, etc. You'll just confidently give them phone, with no "illegal" information on it, they will check it, and walk away. You may, actually, even have some "red herring" files: pictures of nature, shopping list (milk, eggs, etc.), etc., just so that they wouldn't suspect that you deliberately not using your phone for such purposes, and harass you farther.

I mean, not long ago mobile phones didn't even have the ability to store pictures, videos, files, etc.

Are you willing to put your life in danger simply because you want to have some files on your phone?

Tough times require tough decisions.


Credentials in URL for Python "Requests" library

HTTP Basic authentication does not pass the credentials in the URL but in an Authentication header field. The credentials are only base64 encoded and not encrypted, so it should only be used over HTTPS - which you do here.


Is it a vulnerability if an application cookies carry sensitive information?

Putting actual information into cookies, as opposed to just storing a session ID and keeping the rest of the information server side can (but does not have to) be problematic. There are two pitfalls you want to avoid:

Trusting information in the cookie without server side validation, e.g. accepting a total price of $0.01 just because the cookie says so.
Storing sensitive information in the cookies, e.g. passwords or credit card numbers.

However, there are legitimate reasons to store things in cookies. I could imagine it could be useful when implementing a shoping cart and you want to persist the content over page loads without troubeling the server.

So to know if there is a vulnerability here you need to carefully pen test the application (just like you have already done). Try changing the price. Try to order an item that you should not be able to order. Try providing random rubbage. Try to fake discounts you should not get. Try to order non existant items to get the free shipping you only get when ordering more than five items. Try starting two orders in different browsers and see if you can hijack one of them by changing the order ID of the other. Etc, etc, etc.

Some apps that rely on cookies to keep a state will populate a form client side with the data from the cookie, and then that form is sent to the server when the order is submitted so the server will never bother with the cookie. If that is the case here, you should probably focus your pen testing on the form instead of the cookie.

To write safe code, you will need to treat cookie values with the same scepticism you treat any user input even though it was you who set the values. So you will need to validate, do authorization, calculate the correct price and so on server side.

So to summarize, the answer is a firm "it depends".


How can we embed an exe containing a payload into a pdf file

Yes! Embedding is very easy, it's a bit harder to open it. Here's the Javascript to run it:

this.exportDataObject({
    cName: "myExploit.exe",
    nLaunch: 2,
});

Adobe Reader and others won't let you just run any file although, like .exe/.vbs etc., so you need to find a way to bypass it. There are methods described in the reference article below, if you would like to go a bit deeper into that.

Reference article:
https://nora.codes/post/pdf-embedding-attacks/


Standardized?  Well, that depends; there are a lot of standards involved.

Amusingly, someone did, in fact, get IP to run over NFC (both UDP in the form of DNS requests, and TCP in the form of - you guessed it - HTTPS)!  Sockets over NFC on Android on the classycode.com blog lists how in more detail.

Their code is on github with an Apache 2.0 license.

Highlights include:

In our case, we want to exchange these messages over NFC, using ISO/IEC 7816–4 APDUs, between an Android smartphone (the socket client) that supports Host Card Emulation and an NFC reader connected to the Internet (the socket provider)

...

The socket provider is a RaspberryPi with a PN532-based reader connected via SPI. It’s connected to internet via Wi-Fi. This turned out to be a great setup for playing with NFC. For short instructions on getting the setup to work, see my last blog post.

...

The application is written in C and uses libnfc to access the NFC reader. It has no other dependencies, and is fairly compact. It consists of three modules:

pn532_socket_tunnel.c
Manages device connection, handles incoming messages.
socket_infos.c
Encapsulates the application’s state in a fixed-size table of socket infos, i.e. open file descriptors, pending read/write results, statistics.
messages.c
Parses incoming messages and assembles outgoing messages.

...

Now that we have a provider that exposes sockets via APDUs, how do we use it on Android? We can leverage a couple of useful things:

java.net.Socket can be subclassed, so we can provide a NFCSocket implementation that overrides the default behavior.
javax.net.SocketFactory is a facility for providing custom socket implementations.

...

We chose okhttp as HTTP Client library as Android’s HttpURLConnection does not provide a means to provide alternative SocketFactory instances on a per-connection basis. We also disable timeouts as our NFCSocket does not support them yet.

...

Android/Java does not provide a way to override DNS lookup, but fortunately for us, okhttp allows pluggable DNS via the Dns interface:

...

Of course we don’t want to write our own DNS client, so we just use the MiniDNS library instead.

...

The Graz University of Technology offers a commercially licensed, pure-Java JSSE called iSaSiLk which is freely available for Open Source projects. Special thanks to Dieter Bratko for providing me support for iSaSiLk!

...

Success! We downloaded the Hacker News front page via NFC, securely, including the stylesheet and image resources in just over 30 seconds. Which is an eternity of course.

With a Google Pixel and the PN532 reader chip, we get a measly bandwidth of around 1.5 KB/s. Yes, you can browse the web with this. You can even do so securely. But you won’t enjoy it.


Combining User Context in Machine-2-Machine OAuth2 Client Credential Flow

If you are able to authenticate the end-users as well as the client server, it's better to use the Authorization Code flow.

Alternatively, check the user context during the API call instead of in the authentication step.


Motion sensors - detectable when using mobile network?

If the device uses cellular

You can use devices like this or these to find the device.

If the device uses WiFi

Some enterprise AP configuration tools can locate a device in a building, so this could be used to detect the bug

If the device uses other RF

You would need to use a receiver or SDR to detect and move towards the strongest signal. These devices can be used to detect the other options too, but the more specialised devices may get better results.

Issues

These answers rely on the device transmitting when you are looking for it. If it only pulses quickly, or batches up data together, then it will be harder to find.


Plainly speaking, denial of service attacks can be targetted at anything. The point of a denial of service attack of that nature is simply to overwhelm the target.

Pointing this attack at something that takes longer (such as some sort of more complex php page/request) would yield a more effective denial of service attack, because the server will have to spend more time serving each request. If you're hitting a static page like index.html it's likely that that file could be cached or even served by a proxy - Depending largely on the target server's implementation.

To make the attack more effective, you should consider longer-running queries, such as things that talk to a database or to the filesystem.

Minor JavaScript note: You can use setInterval instead of setTimeout in a loop


PCI DSS requirement 6.4.2 separation of duties between development/test environments

It is, of course, always wisest to accept the judgements of your QSA when making judgement calls, however during your own in-house compliance work I recommend checking out the Navigating PCI-DSS: Understanding the Intent of the Requirements document whenever confused by a requirement.

Looking at page 32 of that document we see the following write up regarding requirement 6.4.2

  Reducing the number of personnel with access to the production
  environment and cardholder data minimizes risk and helps ensure that
  access is limited to those individuals with a business need to know.

  The intent of this requirement is to ensure that development/test
  functions are separated from production functions. For example, a
  developer may use an administrator-level account with elevated
  privileges for use in the development environment, and have a separate
  account with user-level access to the production environment.

  In environments where one individual performs multiple roles (for example
  application development and implementing updates to production
  systems), duties should be assigned such that no one individual has
  end-to-end control of a process without an independent checkpoint. For
  example, assign responsibility for development, authorization and
  monitoring to separate individuals.

So, by the strictest reading, then yes. Developers have access to the development system, and may have user role access to production, but a separate individual will actually perform application installs/administration and system administration of the production environment. The real purpose of all this, as discussed in the last paragraph, is that there is no single individual that has end-to-end administrative control of the service. What they want are multiple people with visibility into the process so that no single person can do make changes in development and roll them into production unquestioned.

So, whenever possible, the official advice would be best summed up with a picture.

In serious practice, however, you need to figure out how best to manage that auditing and/or segregation while documenting your processes and eventually getting it properly handled by your QSA.


The appropriate privacy level is entirely context dependent. Clearly k=1 and k=n are generally useless (for a data set of size n). One provides no anonymity, the other does not retain any utility (other than about very basic info like the size of the data set). But there could be interesting values in between.
In this anonymity vs utility tradeoff, an appropriate privacy level can be bounded from either direction:

given a certain analysis that should remain possible with the anonymized data set, what is the maximum k we can tolerate?

given the privacy guarantees we'd like to make, what is the minimum k we require?

For example, lets consider the k-anonymity model implemented by the “Have I Been Pwned?” API. To check whether your password is compromised, you can send a truncated password hash and get back a list of full hashes of compromised passwords. The number of compromised passwords per prefix corresponds to the privacy level k in a k-anonymity model.
Here, an upper bound on k is given through the size of the list of hashes returned in a response. This list should be as small as possible to keep the API efficient. A reasonable upper bound would be somewhere in the kilobyte range, indicating k<2000. A lower bound is given through privacy/security requirements. Given a known-compromised password, neither the API nor any eavesdropper should be able to reliably determine for which compromised password the truncated hash had been sent. There is no clear safe lower bound since any query necessarily leaks some information. However, k<10 is clearly unsafe, and k<100 might still allow a malicious API provider to guess the true password with a reasonably good probability. This leaves a range of 100 ≤ k ≤ 2000 that could be appropriate for this use case.
In reality, HIPB uses a level of k≈500 [1, 2], though with additional padding to prevent further information leaks.
This is a very high k-anonymity level, motivated by the quite severe security impact of leaking passwords. In other contexts, a far lower k will be appropriate. E.g. basic demographic data is far less sensitive, and would likely have an appropriate level around 5 ≤ k ≤ 20. In many domains, a low k is implicitly required due to small size of available data sets – with the only reasonable alternative being to not disclose too sensitive data at all.
It should be noted that k-anonymity and related methods alone do not achieve very strong privacy guarantees at any k, and that the required redaction or abstraction of data is detrimental to many uses. In some scenarios, a probabilistic approach as in differential privacy can be more appropriate.


Host Testing Automation in Kali using Python

I would add to this script:

Nmap NSE scripts (like "--script=http*" and other relevant scripts)
UDP Scanning (you can use "nmap -sU" or any other UDP scanner)

Also, make sure you have good wordlists for your Dirbuster/Nikto scan, usually the easiest attack vectors are on the "hidden" URLs.


Can a web-filter track my internet access over application API calls?

If your connection is https:// rather than http://, CyberRoam should not be able to see the content you are viewing.  It will just know the website.

If your connection is http://, anyone can view your content, not just CyberRoam.

Facebook, Youtube, and Wikipedia all use https://  by default.  So the content on the three example sites you listed should look like gibberish to CyberRoam.

If you want to get around the filter they use to block websites, use a VPN.


If you're talking about "real-world" applications to test, then like schroeder mentioned, bug bounties are your best bet. But then, while companies have them, there are a few online platforms where you can find a bunch. Examples -

BugCrowd
HackerOne
The Internet Bug Bounty Program

You register with these platforms and more or less just start pentesting live websites like Uber, Netflix etc (make sure to follow their terms and conditions!). These are just the tip of the iceberg. Many companies provide their own bug bounty programs, competitions and so on. Beyond these, well, you could always install instances of buggy applications (WebGoat etc) and practice more.


Doesn't an IP conflict occur when ARP spoofing?

Get to the roots ! If you know what ARP does, things will be clearer.

On a subnet (machines plugged into the same set of hubs and switches), the machines talk to each other with MAC addresses: the MAC address uniquely identifies each ethernet/WiFi card. Machines, a priori, do not know MAC addresses; they just know IP addresses. So, when machine A wants to send a packet to machine B, it sends a broadcast frame following the ARP protocol; the packet says: "hey, does anybody knows the MAC address of B" ? If someone responds with the information ("B has MAC address xx:xx:xx:xx:xx:xx") then A will be able to send its data to B.

To speed up the process, A maintains a cache of known mappings IP-to-MAC, but is ready to remove entries from the cache when the information is not renewed (information renewal is when a packet comes to A, tagged with the IP address of B as source, and, at the ethernet level, uses the MAC address of B). The ARP cache entries must not be too long-lived because B is allowed to switch hardware (in case B's ethernet adapter fries and is replaced, the new adapter will have a distinct MAC address, but may assume the same IP address).

Other users of ARP are switches. Switch do not emit packets, but they observe a lot. The point of a switch, as opposed to a simpler hub, is to optimize things by sending packets only on relevant cables, instead of broadcasting all packets over the complete subnet. A switch "knows" that a given machine (i.e. a MAC address) lies at the other end of a specific link by observing traffic (i.e. the switch has noticed that all packets with that MAC address as source come from a given link). The switch maintains thus a mapping MAC->link in an internal table, which is confusingly (and inappropriately) also called an "ARP cache".

Spoofing is the term some people came up with to designate what is otherwise known as a forgery, when in the context of network security (for some reason, perfectly usable words from previous centuries never seem to be good enough for the technology-addict). ARP spoofing is about sending packets which are forged at the ARP level, i.e. packets which will deceive other systems as to the mappings involving ARP (i.e. the ARP caches that machines and switches maintain). The attacker may gain some advantages so doing; for instance, he may convince a switch to send him some packets which would otherwise have been sent to another machine on another link. This kind of attack is also know as "ARP cache poisoning" because it ultimately fills some ARP caches with wrong entries.

An IP conflict is when two machines, with distinct MAC addresses, want to assume the same IP. When an ARP request is sent ("what is the MAC address of B"), both machines will respond, with conflicting information. The requester (A) receives both answers and can warn about the problem: two concurrent mappings with one IP and two MAC addresses. ARP spoofing tries to do something different: two IP addresses (or two links) which map to one MAC address. The successful ARP attack is not really distinguishable from a machine which changed its IP address, something which, on a general basis, is normal (when machines get IP addresses dynamically with DHCP, their IP address may change from time to time), and thus triggers no special warning.


Prevent reflecting page modified by browser extension

You can securely prevent the host web page from accessing data displayed by the extension by having the extension embed its content inside of a pop-up or extension drop-down (this is the solution used by Google's E2Email extension) or inside of an iframe embedded into the page. The iframe must have its src attribute set to a value besides "about:blank". (If it's set to "about:blank", then the host web page can access its contents because of the same origin policy.) The iframe's src may point to a URL contained on a domain trusted by the user, or it may point to an html file contained inside of the extension. The page inside the iframe may have javascript that communicates directly with the browser extension, leaving the host web page entirely out of the loop.


How could malware survive hard disk drive format without residing in the firmware?

Malware could survive without being in the firmware by hooking OS disk access calls and preventing anything from wiping it within the compromised OS.

If you were to live boot to a known clean OS or wipe the hard drive by removing it from the existing system (and you knew the malware was not residing in firmware), you could probably successfully wipe it, but there are caveats:

Do you know the hard drive itself isn't compromised?

The hard drive could theoretically be engineered with another chip that stores a copy of the malware and rewrites it after a successful wipe.  Yet another concern would be malware hiding in a different piece of hardware within the system (either via firmware infection, or hardware implant), thus effectively evading any attempts to clear it by wiping or replacing a hard drive.

The above mentioned process of using a live CD is also potentially fraught with potential peril.  Do you trust the BIOS?  What about the boot-up chain? Modern OSes often use a boot system called UEFI which is at least partially controlled by data that resides on the drive.  Though there are controls in place to try to prevent unauthorized tampering with the boot process, it may be possible for malware to inject itself into that boot chain. Even more low-tech, is malware running on a USB device or in a place to emulate a USB device, if the boot priority allows booting from USB devices before the hard drive.  Once again, the malware could load, and inject itself into any later boot processes, even transparently handing off booting to the "normal" OS after hooking it. If you've ever broken a Linux grub install, you may have experience booting to the grub shell via a live CD or USB, then manually typing code to hand-off execution to the Linux installation on the hard drive, which is similar to the process malware might employ.


Preventing a socially-engineered transaction

For what I understood, keep the process off the PC means that the computing part of it must be done in a specific device, not in the browser that is running in the PC, since it's "easy" to use some keylog or affect the computer behavior.

And another channel means that you shouldn't trust just the browser communication, since the described attack simply puts an iframe over the real page and tricks user to insert attackers information in the device, instead of the real one. So, since what the user see in the page (in the moment that the required information to finish the transaction is inserted) is a fake one, banks / industry / security / users shouldn't use the internet - browser channel as a trusted one.


Can I intercept and impersonate a server over an HTTP wireless connection?

You can set up your own compromised AP that poses as the original AP, often called Evil Twin. If you can make the victim connect to yours instead of the real one, maybe by  DoS'ing the legitimate access point (AP), then you will have control over any traffic the victim produces. You can see this in action in this video by hak5.


How safe is it to provide my administrator account password for a 3rd party software: EasyUS Todo Backup?

On the one hand, it's crazy dangerous. There's nothing more dangerous you could do on a computer than give an untrusted program administrative access to your computer. There are no limits to what the program could do; install rootkits, delete your files, add your computer to a botnet. Anything.

On the other hand, that's exactly what you do every time you run a program as administrator. So, if the program is going to do something nefarious, it doesn't need to save your password. It just needs you (the administrator) to run the program with elevated privileges. Which you probably already did before you got to this point.

As for what the additional danger is in allowing the program to save your password: Windows internally stores your password as a one-way hash. Nothing, not even Windows, can retrieve your password until you type it in yourself. But by providing the password to this program, now you're additionally storing it either plain-text or using reversible encryption. So you've decreased your level of safety by one notch. Not a ton, but it is indisputably lower now. And if they do this bit poorly, then all the worse for you.

Next, Windows actually encrypts certain key bits of your security profile using your login password. These bits are not accessible to anyone or anything until you've provided your password to log in. This is wonderful and super and all that, but it also means that nothing can impersonate you (not even this backup program) without your password. And in particular, scheduled tasks can't run as you without your password. This is just the way Windows was designed; it has nothing to do with this backup program.

And finally, since this issue with scheduling tasks to run as a user is a known problem in Windows, there's actually a core system function for storing your login credentials specifically for use running scheduled tasks. This means that the backup program doesn't have to store your password, it just has to tell Windows to do so. So it's unlikely that this backup program is directly doing anything with your password, they're probably just handing it off to Windows to use with its built-in task scheduler.

So in that case, the safety of your password would be more of a function of the safety of the Windows task scheduler, not this backup program.


How safe is XOR with multiple preprinted stainless steel key tags purchased from different channel?

Have you considered generating your own high-entropy key input BitBabbler and marking the stainless steel yourself mechanically, or with an electro-chemical process:

https://toolsspecialist.com/how-to-etch-metal-with-vinegar/ a straight-forward process with vinegar, salt, and 9-volts
an arguably better result in brass TechShopJim instructable
... spare a thought for ventilation, and disposal of larger amounts of etching fluids

Edit: then I got to thinking, how hard should it be?

that drill is the smallest I own, 1mm (~0.04") .. I'll be impressed if it lets me knock out hundreds of holes, but I'm going into mild steel, so, anyway!
the thing holding it is called a pin vise
you would actually need "fair" dice (don't use the ones you stole from the casino)
... and say I had two, I'd roll 50 times to get to 256 bit, ie. log₂(6^2)x50, but personally, I'd stop sooner - needing enough energy to boil an ocean is sufficient enough of a barrier for me!


What does "connection" mean in context of request smuggling

This is about a TCP connection (both with and without TLS). With HTTP keep-alive multiple HTTP requests can be send one after each other inside the same TCP connection and it is up to the HTTP stack to properly distinguish where a request starts and where it ends.

Due to the complexity and in some cases ambiguity of the HTTP standard it is possible to create sequences of HTTP requests where different HTTP stacks (i.e. in front-end and back-end servers) have different ideas where a request starts end ends. These interpretation differences allow HTTP request smuggling.


When cellphone providers give "unlimited social networking", how do they identify the traffic?

Strictly speaking, the phones are not completely restricted because of IP over Facebook. Whatever the medium, there's always someone to think about transporting raw IP packets in it, and then go ahead and actually implement it.

For the actual restriction, this can be done with IP filtering, or by enforcing an unescapable Web proxy which filters on the URL (preferably a transparent proxy rather than something in the phone software, so that jailbroken phones may not evade the restriction).


Does https prevent man in the middle attacks by proxy server?

How does HTTPS work?

HTTPS is based on public/private-key cryptography. This basically means that there is a key pair: The public key is used for encryption and the secret private key is required for decryption.

A certificate is basically a public key with a label identifying the owner.

So when your browser connects to an HTTPS server, the server will answer with its certificate. The browser checks if the certificate is valid:

the owner information need to match the server name that the user requested.
the certificate needs to be signed by a trusted certification authority.

If one of these conditions is not met, the user is informed about the problem.

After the verification, the browser extracts the public key and uses it to encrypt some information before sending it to the server. The server can decrypt it because the server has the matching private key.

How does HTTPS prevent man in the middle attacks?

  In this case, will G be able to get the certificate which A previously got from W?

Yes, the certificate is the public key with the label. The webserver will send it to anyone who connects to it.

  If G can get the certificate, does that mean that G will be able to decrypt the data?

No. The certificate contains the public key of the webserver. The malicious proxy is not in the possession of the matching private key. So if the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver.

The proxy server may try to forge the certificate and provide his own public key instead. This will, however, destroy the signature of the certification authorities. The browser will warn about the invalid certificate.

Is there a way a proxy server can read HTTPS?

If the administrator of your computer cooperates, it is possible for a proxy server to sniff https connections. This is used in some companies in order to scan for viruses and to enforce guidelines of acceptable use.

A local certification authority is setup and the administrator tells your browser that this CA is trustworthy. The proxy server uses this CA to sign his forged certificates.

Oh and of course, user tend to click security warnings away.


SSHguard: Does one to change any configuration for basic usage of the program?

I've manually verified this trying to login to my remote machine and it seems that SSHguard works OOB (Out Of Box), without me changing anything in the configuration:

Indeed, after 6 tries, I got a Putty fatal error, with this message:

  Server sent disconnect message type 2 (protocol error): "Too many
  authentication failures"

Update

I likely was wrong and it comes from Putty. Will further test later.


It means just what it says: the Android permission system does not try to identify transitive requests to use privilege.  For instance, if app A asks app B to do something on its behalf, and in response app B asks the underlying OS to do something, then the OS permission checks only take into account that B is requesting, not that the request originated with A and is being performed on A's behalf.

To understand in more detail, I suggest that you read the following papers:

Android Permissions Demystified. Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner.  CCS 2011.

Quire: Lightweight Provenance for Smartphone Operating Systems.  Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, and Dan S. Wallach.  Usenix Security 2011.

Permission Re-Delegation: Attacks and Defenses.  Adrienne Porter Felt, Helen Wang, Alex Moshchuk, Steve Hanna, and Erika Chin.  Usenix Security 2011.

Wikipedia on the confused deputy problem.

P.S. In the future, when quoting from someone, you might want to provide the source of the quotation.


Is it possible to hack a device via the USB port on an airplane?

Yes. This could be dangerous. I'll try to explain a scenario where this may harm your phone:

Since you are using an iPhone and Apple's software is kept closed-source, we cannot know for sure whether it matters if you allow/disallow media access. I think it makes an attack somewhat more difficult, but not impossible. I will base my answer on Android phones, so that you can get a feel for the risk involved. iPhones can be as easily exploited but lets consider the following scenario:

An attacker plugs in a Rubber Ducky or a Teensy to the airplane's entertainment system. This allows him/her to perform an HID attack, compromising the machine that handles the entertainment system. The attacker is then able to run any process on the entertainment system.
Now you plug in your device. Assuming the same machine manages both yours and the attacker's USB ports, the process he/she is running can now infect your phone. The possibilities for an attacker are endless, and this scenario even helps him/her to employ some social engineering tactics (pretending to be the entertainment system to gain your trust, etc.).

A way of thwarting the threat is to use power only cables that you can make or buy for this use case.


Disable internet access of development PC for security

First of all, I'm in the camp that thinks this is a terrible idea. Security is about trade-offs, usually trading potential safety against convenience. But in a business environment it's all about costs. The cost of a potentially malicious outside influence in your source code (which is dubious at best) would have to outweigh the increase in development costs, which will be dramatic.

The cost of security failure isn't an all-or-nothing game; you can mitigate the cost of security failure by using proper vetting, backup, code review, and SCM techniques and tools. Plus, these techniques help with other issues as well, not just security problems.

The only excuse for such a policy would have to be a gross understatement of the costs it would impose and a lack of understanding regarding the alternatives. And a company with that sort of management disability is not a good long-term employment prospect.

Now, that said, I can think of one environment in which such a policy is perfectly reasonable. Specifically, many security-related companies (and government security contractors in particular) have a red-green division on all resources. The "red" side is susceptible to outside influence, while the "green" side is absolutely isolated and self-contained in every way. No cross connect, no shared systems, no shared code, no shared information.

In such an environment, "green" development would have to happen on a machine that is disconnected from the Internet. However, also in such environments, each employee/developer is expected to have two workstations, a red one and a green one, so the empoloyee would not be utterly cut off from the Internet.


A connect() scan generally refers to a network scan that performs a full TCP three-way handshake (SYN, SYN/ACK, ACK) in order to determine whether a port is open or not.  Once those three packets have been transmitted by the respective hosts there is a connection open and ready to pass traffic.  The scanner will then either close the connection with a RST or FIN, or they could conceivably just stop using it and eventually the server will time it out and recover the resources.

There are many alternatives, the most common being a SYN scan - the scanner sends a SYN and waits for a SYN/ACK.  If it sees it, it concludes the port is open, even though it hasn't fully opened a connection.  The scanner does not send an ACK to complete the connection, and the server's TCP stack will close out the nascent connection in response to a RST or after (far shorter) timeouts (than are used for open connections).

connect() scans are generally easier to detect, because applications often log fully opened and closed connections, especially connections that close at the TCP instead of at the application layer (e.g., they'll complain that "IP a.b.c.d DIDN'T SAY GOODBYE").  This makes a connect() scan easier to detect.  Also, because OS resources are dedicated for fully opened connections, it is possible to tax resources on a host by nailing up a bunch of connections and then not using them - e.g., the "timeout" method is particularly rude.

The reason one might use a connect() scan (-sT in nmap) is that it's more reliable.  Nothing says "a host will talk on this port" like getting the host fully ready and willing to talk on that port.  Some other scan modes may have false positives.  There have been times I re-scanned individual ports that appeared open to SYN scans and was unable to verify the port was open with connect() mode scans.

(N.B. ALL scan modes can have false positives.  As my therapist likes to say, "Don't believe everything you think.")


How many combinations does a specific password policy allow?

Your companion is right that the least restrictive policy has a higher potential entropy, as it can encode a larger amount of information. This being said, the entropy of a set of data depends on the probability distribution of each datum appearing in the dataset. Therefore, the quality of a password policy should not be measured in terms of how much information can be encoded, but in terms of how much it prevents different users from using similar passwords.

Simply throwing in mandatory numbers does very little for that purpose, and a site that randomly assigns 7-character long passwords composed of numbers, symbols and letters would probably achieve a higher overall entropy. It's impossible to give an authoritative answer as to whether there is a significant difference of quality between the two proposed policies because:

they both require higher amounts of user memory than most passwords observed in the wild require, meaning neither is likely to have significantly higher amounts of weak password reuse
none of these models is common enough for any public/leaked password dataset to be available for reasoning about probability distributions
there is no generative model of human password choices that could explain how actual humans would make passwords on these sites¹

  ¹ some might claim they have such a model - given the superficiality
  of state of the art research on human password choices, this is very
  unlikely. The latest research only addresses behaviours with regard to
  a unique credential, with populations that are unrealistically
  motivated in authenticating to studied services (because of how
  password behaviour experiments are constructed). Current research is
  also strongly culturally biased towards US/UK individuals as
  demonstrated by Li et al.
  2014.
  Until these limitations are addressed and much more data is
  collected

If you want to understand how to estimate the strength of an individual password the current method to apply would be to implement Bonneau's password strength metrics.


Is my online bank password security policy good enough?

This is wrong on so many levels I don't even know where to start...

Four digits? Seriously? Even if you implement all the brute force detection in the world, someone could easily break into an account on the first try just by being lucky!
You can't hash four digit numbers in a meaningful way. No matter how high cost factors you set for bcrypt, it's not going to help much. That means that all the PINs must be stored in a reversible manner. If that database leaks, there is nothing protecting your account...
Having people enter the PIN to their credit card on a computer is a horrible idea to begin with, no matter what you use it for. Your PIN should be entered to credit card readers, nothing else. Teaching customers to give it away on websites isn't a good idea.
As you say, a credit card PIN is harder to change than a password.
An 8 digit PIN is better than a 4 digit one, but still not nearly good enough. Why not allow people to use real passwords? Or 2FA?

No, there are no excuses for this. There are no clever protections that can make this fine. Consider changing to another bank.


How does signing work with Elliptic Curve Crypto?

Elliptic-curve (EC) cryptography is significantly different than traditional RSA-style cryptography.

Bottom-line Up Front (BLUF): Your server can only handle RSA key exchanges given the information you provided.

As a primer, both of these are asymmetric cryptographic protocols. They are used to securely transmit a SYMMETRIC key that both parties use to encrypt the actual data/message. The reason behind this is that asymmetric cryptographic protocols are extremely computationally intensive as compared to symmetric cryptographic protocols (in the general case). So encrypting a large dataset or a streaming message would be resource intensive. Instead, the symmetric key is used.

So back to your question. Your digital signature has been created and signed stating that your public key is a 2048-bit RSA key. That necessarily means that your private key is also an RSA key - You cannot use EC protocols with that digital signature or the keys that you possess. So the answer to your first question is: Yes, you can only do 2048-bit RSA key exchanges on your web server.

To create/generate EC keys you would have to either be issued one (or more) from an upstream provider or generate them yourself via a 3rd party tool like openssl.

As an additional aside, readers may be wondering why you would use EC over RSA. Well that's because of performance. In theory (at least to what's been proven to date in the security community), EC keys take up much less space and run more quickly on a particular system (hardware implementations may vary that contradict that statement, but in solely software implementations on the same system EC should be faster than the equivalent-strength RSA).

For instance, according to the openssl page on EC (http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography), encrypting a 256-bit symmetric key in RSA would require a15360-bit RSA key but only a 512-bit EC key.

So you see, if you're running an HTTPS server with lots of clients, you would want EC keys because you can secure the symmetric key much more quickly and reduce your overall processing by a lot (including the amount of data sent over the wire in the key exchanges).

On to your second question. If you were to have EC keys, they would likely be in a different certificate because they would be issued/generated at a different time. The trust would be from whatever source your current trust is - whether that's an internal root certificate authority or an external one like verisign or godaddy.

In theory, if your certificate were granted the proper permissions, it COULD be used to sign down-stream certificates (meaning, your certificate is an intermediate certificate authority that can then sign requests from others within your organization). If that were the case (not likely given your certificate is used on a web server), you could create EC keys and an EC certificate signing request and issue a certificate that is authorized by your 2048-bit RSA signature to permit the use for your, for example, 384-bit EC key.

I hope this helps some. I'd read the openssl link I posted for a bit more on this.


How can Network Disconnect be implemented for RDP on a Windows system (2003/XP or later)?

I'm unsure whether this is the policy you're looking for, but perhaps it just slipped your attention. On the server side (this is Windows 2003) you have this:

It allows you to define the settings for the RDP sessions over network.

Otherwise it's possible this is what you are looking for. I left a comment on your question, perhaps you can clarify there if this is not what you're looking for.


What does proxyexec + cagefs.server mean in the e-mail X-Source-Args?

This header
X-Source-Args: /usr/sbin/proxyexec -q -d -s /var/run/proxyexec/cagefs.sock/socket /bin/cagefs.server

is standard header in email sent from shared hosting. When I search the keyword /var/run/proxyexec/cagefs.sock/socket via SE search , it pop up in several questions on SO and SF, indicating this header was normal.

I don't familiar with CageFS. But after lurking at some Google Result, CageFS appears to be some kind of container to separating user in multi user environment. It using proxyexec to proxying command invoked from a cage to command outside its cage. Snippet from this page and this page

CageFS is a virtualized file system and a set of tools to contain each user in its own 'cage'. Each customer will have its own fully functional CageFS, with all the system files, tools, etc...
Some software has to run outside of CageFS to be able to complete its job. This includes such programs as passwd, sendmail, etc. CloudLInux uses proxyexec technology to accomplish such goal. You can define any program to run outside CageFS, by specifying it in /etc/cagefs/proxy.commands


Block SMTP Connection That Doesn't Have Credentials

The search string you are looking for is "SMTP server require authentication" (or just "<server product name> authentication"). To be clear, what you're establishing isn't really a "Telnet Connection", it's an SMTP connection that you're typing in by hand using telnet. If you tried to send anything that wasn't valid SMTP traffic, the server would ignore it or disconnect. You could also use clients other than telnet - anything that supports arbitrary TCP connections would work - and the server has no way to know what program is being run as the client anyhow.

Mind you, even after you set your SMTP server to require authentication, you'll still be able to telnet to it. All that telnet is doing is establishing a TCP connection. There's nowhere in a TCP handshake to supply credentials; that comes after the connection is established (see https://en.wikipedia.org/wiki/SMTP_Authentication for more info).

You should also look into enabling TLS (the same Transport Layer Security protocol used in HTTPS) on your server. Even with authentication, sending mail via an insecure connection allows an attacker to potentially read or even modify the mail. Authenticating over an insecure connection potentially allows an attacker to steal your credentials, or at least replay them to authenticate as you at a later time, unless you use a protocol very specifically designed to be secure against that. Therefore, switching to TLS should be done before authentication.


Are there any known viruses/malware that can infect Ubuntu that come from the USB?

Yes.

Search for "USB Rubber Ducky" or BadUSB.

The USB device introduces itself to the computer as a keyboard and can then installs malware.


how can you view an HTTP request in transit?

Packet Sniffers

Packet sniffers allow you to see everything that is travelling on the network. Wireshark is the most popular and free and is easy to download and install.

With a packet sniffer, you can read in plaintext anything that is not encrypted.

These require that you have access to the network where the communication is coming from (either server or host). You cannot read packets on a network that you do not have access to. That is why you have heard that they read what is coming from your own computer.

But, it is possible to gain access to other networks. Wifi (public or hacked private) is a popular and easy means of gaining access to other's network traffic. Some attackers go to great lengths to physically install sniffers in corporate networks so that they can access this type of data.

HTTPS

HTTPS encrypts information between a browser and the server so that sniffers cannot read the actual content of the communication. For a site that has a mix of HTTP and HTTPS content, parts of the communication will be readable, and some will not.

Testing

This is easy to test. Download and install Wireshark and start a capture. Then launch a web browser and navigate to a website that is not HTTPS. Stop the Wireshark capture, then look through the data. You will find the actual text of the website in the capture.

Try again on an HTTPS website (google, for instance) and you will see that you cannot read the text from the website.

Now try the whole process on a mixed website, and you will see what is encrypted and what is not. It is possible that ads and other 3rd party content has not been encrypted, for instance.

Impacts

Packet sniffers are the technical tools, but pre-packaged hacking tools use packet sniffers built into themselves to read this information and format it for malicious uses. Firesheep is the currently famous tool that can hijack someone's connection to Facebook and Twitter.


Can a virus persist across Windows version upgrades?

Short answer: Yes.
Why?

If the malware/virus is delivered via an application/file and the app/file is opened after you re-installed Windows, then the virus/malware will be reactivated.

When you upgrade, you don't do a complete re-install of Windows, you just update it (for example from Vista to 7). If this happen it's very likely that the virus will run just as well on the new version (don't underestimate the compatibility of malware and viruses).

If you are completely removing everything that's on the hard drive there's a good chance that your PC will be clear of viruses. If you however, have your Windows on C: drive and the virus/malware on another drive, it's very possible that it will come back if you trigger some part of it.
There are a number of other options, but these are the more commons I can think of. It would also help if you could clarify explain what you understand by "upgrading to a newer Windows".


Does it makes sense to change the LUKS password in every 90 days?

Password rotation really depends on use and exposure. If the machine is always on and the password is only ever used during a monthly reboot, then rotating that password after every 3rd use doesn't make a whole heap of sense.

Instead of thinking in terms of time, think of password rotation in terms of risk. How often do you use the password, on how many machines do you type your password, in what sort of environment do you type it (e.g. in an airport, coffee house, or perhaps only standing alone in a server room), how many people know the password, etc.

If more than one person has access to the password, then you should rotate it regularly as a matter of course. Rotation decreases the exposure if the password is ever inadvertently disclosed; and the more people who see it, the more likely one will disclose it (either intentionally or not). Changing the password immediately revokes access from anyone who should not have access (assuming they haven't installed some sort of back door).

But most importantly, always, always, always change a password when someone has it who shouldn't (or who no longer needs it).

Your risk will never be zero, and there is no problem that changing your password is guaranteed to solve. But many times I've seen instances where the same password has been in use controlling a resource for years, no matter who comes and goes. I've seen businesses sunk because a password was given to a contractor 3 years earlier, who saved that password on a personal computer which since was compromised by attackers.

You don't need rigid, blind, senseless password rotation policies to be safe. But you need to be aware of the risk that a given password represents.


Backup is about avoiding loss of data; it is a trade-off between frequency of backups (more backups mean more work and more storage) and tolerance on loss of the most recent data. When you backup your data daily, you implicitly tolerate losing one day's worth of work. Correspondingly, there is no need to backup again data which has not changed -- as long as the previous backup is still good.

When doing regular backups, we actually combine two operations:

The new backup includes a copy of new data (data which was added or modified since the last backup).
The new backup is "fresh", hence supposedly robust. Digital media, and all media in general, tend to wear off over time.

Magnetic tapes are often said to be good for ten years or so. Modern paper lasts for a century. Old paper (when they were making it with cotton instead of wood) lasts longer, maybe a millenium (we don't really know yet). Engraved slabs of hard stone, or non-oxidable metal like gold, are best.

There two operations are distinct, and need not be necessarily combined. You want to make new copies regularly, to make sure that the stored backup is still readable; but you do not want to make too many copies of your encryption keys because encryption keys are, by definition, extremely sensitive, and multiple copies are, also by definition, at odds with confidentiality.

Since we are talking about encryption, we can use it to make the problem of backups more manageable. Typically, do it like this:

Store your encryption keys and other critical secrets in a container, say a Zip archive (the Zip file format is reasonably well documented, widely supported, and unlikely to be lost -- for long term archival, file format perennity is a serious concern).
Encrypt that file with a symmetric key (the "master key"), there again using a well-documented, open format which, come what may, could be reimplemented from scratch. OpenPGP would be convenient. The master key can be a big fat password if you prefer it that way. Make it so that it has enough entropy to withstand brute force attacks (80 bits are good, 128 bits are supreme).
Backup the encrypted file in as many places as possible. It is encrypted, so it needs not be especially protected. Keep it on some USB keys, write it in every server you have access to, put it on a Web page and let other people copy it and keep it forever.
Store the master key in two or three safe places. The master key is short, making the problem easier to deal with (that's what encryption does: it does not solve confidentiality issues, but it reduces them). For instance, write it down on a piece of paper, and keep that paper in a bank safe. Make sure that the copies are geographically separated, because floods and earthquakes do happen (usual rule of thumb is to enforce at least 300 km between copies).

For extra points, make the master key an asymmetric encryption key (say, RSA with a large enough key size to make you feel safe -- 2048 bits would be enough for me). This allows you to produce new encrypted archives when you have some new encryption keys to save, using only the public key (the public key being public, you can put it everywhere, including your Facebook account).

(I know of a deployed PKI where the root key backup uses the paper-in-a-bank-safe method. Writing is good. We can read written text from more than four thousand years ago. Can you read an 8" floppy from 1973 ?)


How to attack a specific computer behind a NAT using remote buffer overflow

You can't directly access the victim from outside since it is not directly reachable due to the NAT router. You also cannot trick the router into giving you some special access to the internal device. This means that you first need to find a way into the internal network first. How to do this depends on the specific environment, i.e. you might be able to trick the user into opening a malicious attachment, you might be able to attack some internal IoT device which is accessible from outside due to port forwardings etc.


Best practice / Risk Assessment payment websites

While there will be a lot of opinions around this, from a numbers viewpoint, I believe that having a common payment site independent from your other web sites is more economical and secure.

Reduced attack surface.  The single site should have a very simple API for your other sites to consume:  "Customer X wants to pay amount Y for order Z", that sort of thing.  This limits the possible ways for an intruder to violate the system.  As you need to examine every single input for a flaw, there are simply fewer inputs to examine.
Reduced audit scope.  When you start dealing with payments, you must deal with PCI compliance.  Payment systems are really onerous to certify.  You don't want to have to pay the auditors extra to crawl over all your app servers just because they may have some payment data in them.
A breach can easily be more disruptive than you imagine.  If you're thinking that you're going to expose either X accounts hosting on one server each, or 2X accounts hosting on a common server, either breach has the potential to be so detrimental to your common business that both entities may go out of business entirely.  Let's see if I can draw this:

    Number of     |
accounts breached | Progressively larger impact to business
                  |
    10^1          | Small fines, increased auditing
    10^2          | Larger fines, greatly increased auditing expense
    10^3          | Internet/Yelp impact to brand reputation, lawsuits
    10^4          | Local newsworthy impact to brand
    10^5          | Class action lawsuits, regional impact to brand
    10^6+         | National/international impact to brand

At every point on the scale your business' very survival is at increased risk.  Would risking 2X accounts because you include two web sites change the potential impact?  Not so much.

I think you're better off pooling your resources and securing a single payment site.  And the more you look at this problem for smaller retailers, the more I recommend contracting with a payment gateway, and offloading that risk from your core business of selling widgets or gizmos.  If a payment provider is breached, that generally won't reflect as badly on the web sites that used them.  If it helps, think of the extra cost as an investment in reputation insurance.

Even if you choose to go with your "version 2", I would still recommend each web site maintain its own payment gateway as architecturally independent from the rest of the web site as possible.  That means separate payment servers from the web servers, separate databases for payment data, etc., for the same reasons:  to reduce the attack surfaces and decrease audit scope.


Website certificates in different browsers

Chrome is showing you the SHA-1 hash of the certificate.
Edge is showing you the SHA-256 hash of the certificate.
FYI, Firefox shows both.  Copied below is a snip of the fingerprints of the certificate for *.stackexchange.com as displayed by Firefox:

Finally, hashing does not involve exponents.  You might be thinking of assymmetic RSA or DH encryption, which involve exponents.


There's a lot of ways you can attack a WiFi without knowing any passwords:

Physical layer attacks: Simply jam the frequency spectrum with your own signal. That signal might just be noise, but it might also be a WiFi of your own under heavy load, with the nodes in that WiFi being configured not to play nice with others. (depending on the WiFi chipset, that can be extremely easy) Spectrum can only be used once!
Tool: noise source (e.g. Gunn Diode, SDR device), or normal AP
Electromagnetic sledgehammer: EMI gun. Take microwave oven oscillator, attach directive antenna, pray you don't cook someone's (your) brain, and point in the rough direction of the access point. Poof! Microwave ovens operate in the 2.4 GHz band, and thus, antennas of Access Points are picking up exactly that energy.
Tool: Microwave oven, some sheet metal, lack of regard for other people's property and own health, or extended RF knowledge
MAC and Network layer attacks: Especially for networks using WEP (noone should be using this anymore, but sadly...) it's easy to forge what is called deauthentication packets – and thus, to throw out stations from your WiFi.
Tool: Aircrack-NG's aireplay
Targetted jamming: As opposed to simply occupying the channel with noise or your own WiFi, you can also build a device that listens for typical WiFi packet's beginnings (preambles), and then, just shortly, interferes. Or just sends fake preambles periodically, or especially when it's silent. That way, you can corrupt selected packets, or fake channel occupancy.
Tool: Commodity off-the shelf SDR
authentication attacks: at some point, even "proper" clients for your WiFi need to register with the WiFi. That mechanism can of course be forced to its knees by simply sending hundreds of authentication requests every second, from randomly generated MAC addresses, or even from MAC addresses of clients you know (by observation) exist. There's no solution to the problem for the AP – either it succumbs to the overload of auth packets, or it starts blocking out legitimate users.
Tool: your network card, 10 lines of bash scripting
Man-in-the-Middling / access point spoofing: With anything short of WPA(2)-Enterprise, nothing proves that the access point calling itself "Toduas AP" is actually your Access Point. Simply operating a slightly higher-powered access point with the same ID string and, if necessary at all, a faked AP MAC address (trivial, since just a setting), will "pull" clients away from your access point. Of course, if the spoofing Access Point doesn't know the password, users might quickly notice (or they don't); however, noticing things don't work is nice, but doesn't help them.
Tool: a random normal access point

You have to realize that it's a privilege, not a right, to have your WiFi use a channel. WiFi happens in the so-called ISM bands (Industrial, Scientific, Medical usage), where operators of transmitters don't have to have an explicit license. That means it's OK for everyone to use that spectrum, as long as they don't intentionally harm other devices and are not easily damaged by interference.

So, it's absolutely legal for someone to operate a high-definition digital camera stream that occupies the whole WiFi channel. That will effectively shut down your WiFi.

If you need something that no-one can mess with, wireless is, by definition, not the way to go.


Gravatar - Is it a security risk for medical forums?

HIPAA specifically states that the users email address is protected PII.  The md5 hash of the user's password is trivial to reverse, and a data breach of these hashes would result in protected email addresses being divulged - and that would result in legal recourse.  The blackhat community is quick to crack hashes, and email addresses can be more predictable than a password.

If an attacker can show that your systems violated HIPAA, then legal action will be taken. Gravatar was never intended to preserve user's privacy, and leaking a gravatar ID of a medical patient is a violation of HIPAA.


I'm wondering how I hide my identity online well

There are two general levels of anonymity:

Good enough for hiding from other routine users of the internet.
Good enough for hiding from government law enforcement and surveillance agencies.

As you can imagine, the second level is much much harder to achieve; and usually unnecessary for law-abiding citizens in a democratic country without a security hobby.

Tor is a logical network and protocol that takes advantage of proxy indirection and encryption to produce some degree of anonymity; sufficient for level 1.

Normal VPNs are only as good as their resistance to external pressure to give up their connections logs or customer details. So again, only really sufficient for level 1.

Tor and VPNs serve a different though overlapping audience. Typically Tor is limited to browsing the web; whilst VPNs can be used to redirect any protocol. Either way you must ensure that all traffic passes through the indirection. For if some does and some doesn't, your anonymised identity is linkable to your real (ISP-mediated) identity.

Anonymity needs to be built from the ground up if you really care about it1.

Here are some steps you may need to consider, but frankly this starts getting outside the scope of Information Security stack exchange:

Create a billing instrument detached from your normal banking details and identity. This might be a pre-paid debit card; a bitcoin wallet or some shady e-Gold site.
Purchase VPN hosting from a vendor that doesn't mind the billing instrument you created in step 1.  Preferably in a country that either hates your country or flouts international criticism as a tax haven, gambling den or the like.
Perform steps 1 & 2 again through the VPN you have just established to purchase VPN hosting in yet another jurisdiction. Repeat steps 1, 2 and 3 until you have chained as many VPNs as you can stomach for brittleness and latency.
Only create (and only use) various anonymous online accounts (email, social networking, voip, etc) through the VPNs
Follow all usual advice for working through a VPN. Unless you want to fly too close to the sun like Ross Ulbricht of Silk Road.

Where possible try to have the last VPN as a vendor or at least an IP that is not currently known to be VPN; as many major sites will reject connections from VPNs2.

1. You probably don't. Once you realise the effort involved.
2. Tech-savvy trolls also like being anonymous.


Building's server room is unlocked: What danger is my building in?

I can just walk in, plug something similar to this into your
network and read the unencrypted network traffic of the entire
building.
I can snip a few cables and cause a denial-of-service for multiple businesses. This will be pretty hard to diagnose if the building does not have a network admin on hand to deal with such issues.
I can steal all the networking equipment.

There is a whole bunch of things I can think of but it would be pointless to list them all. Locking the server room isn't that difficult..


How can I prevent my son accessing my PC?

Go into the BIOS (usually F2 or Del at boot) and set a boot password. This will be required every time it boots up. Every BIOS is different, so I can't give you step by step instructions, but it shouldn't be too hard to find. This will prevent the computer from booting into any operating system at all, until the password is entered. Keep in mind that you'll still have to put your login password in too, after it boots.

From a non-technical angle, as a 14 year old I would've gone nuts without access to a computer. I don't know what your situation is, and far be it for me to give you parenting advice, but consider giving him access!

Assuming Vista or Windows 7, the alternative would be to give him his own login account, with limited privileges. This prevents him from installing anything, and he can't get at any of your files within your user profile (e.g. My Documents, Pictures, etc). You can do the same on Windows XP, but the limited user design isn't as robust. This would allow him to browse the net and whatever else, without him interfering with any of your documents.


Custom post data JSON payload format in sqlmap?

sqlmap automatically detects the json payload and tries to inject so instead of the above mentioned payload like:-

--data="{'user_id':'6','user_with:5*'}" --prefix=" OR user_to = 5)" --suffix="#" -vvv`

use the following payload:-

--data="{\"user_id\":\"6\",\"user_with:5\"}" --prefix=" OR user_to = 5)" --suffix="#" -vvv`

you need not use ' instead of " to use json parameter with sqlmap just escape is enough.