PCI DSS - one server one primary function (different database engines)

The guidance in DSS 3.2 at least is "If server functions that need different security levels are located on the same server, the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. Additionally, the server functions with a lower security level may introduce security weaknesses to other functions on the same server. By considering the security needs of different server functions as part of the system configuration standards and related processes, organizations can ensure that functions requiring different security levels don’t co-exist on the same server."

I'd examine the data going into each.  If it is comparable, you may be ok.  If, however, the WordPress (mysql) data is low security and the SQL Server data is not, you'd be hard-pressed to argue you're within this guidance, in my opinion (not a QSA)

I think I'd put it on a separate server just on general principles.  If they are on the same server, do your best to separate them - run them as different users, for instance, do your best to limit what the mysql database could do to the system or the SQL Server database.


Is a user being able to view their own UID a security risk?

In your specific case it appears not. However in the general sense it depends on how your UIDs are used. If your UIDs are used anywhere in your system as trusted information, and your user can deduce other UIDs from their own, you have a problem. For example, the British company Moonpig made the news a few years ago when it was determined that their user IDs were consecutive, and that a user's ID was sufficient information to request a user's private information including names, birthdays, addresses, last four of credit cards and credit card expiration dates.

If your UIDs are sufficiently random, then leaking them does not decrease security because they provide no additional information about other accounts to an attacker. They would still need to manually enumerate the possible UID space to find valid ones. However, UID enumeration is not especially difficult and so sensitive transactions should always be protected by at least one other private piece of information. In your case that second piece of information is the token which signs the request.


What tools does the Google safe browsing service rely on?

Google  provides two experimental APIs for the Safe Browsing service

(1) Safe Browsing API v3

https://developers.google.com/safe-browsing/developers_guide_v3

(2) Safe Browsing Lookup API

https://developers.google.com/safe-browsing/lookup_guide

Both these above mentioned tools can be downloaded and used anytime .

https://developers.google.com/safe-browsing/

For anyone who wants to know more about how Google's detection system works , a detailed tech report can be found here

https://static.googleusercontent.com/media/research.google.com/en//archive/provos-2008a.pdf

There is also this page where a user can easily query to check the  site

http://grapethinking.com/google-safe-browsing-diagnostic

Google Chrome includes an optional feature called "Safe Browsing" to help protect users against phishing and malware attacks

https://www.google.com/intl/en/chrome/browser/privacy/whitepaper.html


Proof of quantum safety of the Merkle signature scheme

The Merkle signature scheme is based on a hash tree over one-time signatures, e.g. using Lamport's scheme.

Roughly speaking, both Lamport's scheme and the hash tree are secure as long as the hash function is resistant to preimages and second-preimages. There can be details because when using hash trees, preimage attacks are often multi-target, i.e. there are several values for which the attacker would like a preimage, and a preimage for any one of them would yield a success. Yet, preimage resistance still leads the scheme overall robustness.

Against quantum computing, a "perfect" hash function of output size n bits still offers resistance 2n/2. E.g. with SHA-256 (a 256-bit output), the best quantum computer would still need 2128 operations (i.e. way too many to be feasible, with a huge margin) to break preimage resistance.

(This also means that against classical computers, a 256-bit hash function is total overkill when used in Merkle scheme. But, against classical computers, we can also use RSA or ECDSA, which are way more efficient than Merkle's scheme.)


Which information does a whois lookup reveal about the registrant of the domain?

The domain name that is used for the email address of a scammer may be only loosely related to the scammer himself. E.g. if a scammer uses an Hotmail address, would you conclude that Microsoft (the owner of Hotmail) is an accomplice ?

Probabilities are quite high that the names and addresses indicated in the whois database are fake, or point to an innocent bystander (or possibly the owner of a domain whose mail server got hacked). I suggest refraining from "having fun" as the potential for collateral damage is quite high.

It is usually considered more reasonable to complain with the registrar -- who, in that case, actually manages the incoming emails (try: host -t mx networks2013.com).


How can I avoid sending passwords in plain text when logging into a website?

https is designed to prevent this kind of attack: The communication between you and the server is encrypted. The server will provide a certificate to ensure that it is the correct one and not a man in the middle.. If the certificate is signed by an certification authority trusted by your browser, the connection will be accepted automatically. Otherwise you will get a warning about an untrusted certificate. If you are in doubt, don't click it away.

There is really no excuse not to use https for login, as simple trusted certificates are really cheap or free of charge. https should be used for everything, but some huge sites argue that it uses too much processing power.


Is it unsafe to have some users with passwords and some without?

I don't see any problem with this, as long as there is no way for the user to generate a null password digest when attempting to log in.
Otherwise, magic links are no less secure than the access offered by the password reset feature on most sites already. You could even argue that having no passwords is more secure, since there is no longer a secret that can become compromised (assuming the email account is better protected).


Hashcat saves its progress in a .pot file. The --show command will let you see the cracked hashes that have been saved in the .pot file.

The FAQ will help with more details.


Is API hooking done by a process in a shared page, visible to all other processes?

No, all API hooking (IAT, EAT, Detouring and so on) only affects process you are modifying as the PE loader grabs a local copy of Kernel32 instead of using shared code.

You would need to inject all processes with your hook to effect all processes you'll require SeDebugPrivilege to open certain system processes.

If you want to go any deep you could hook SSDT in kernel or could modify .text directly but comes a problem with x64 PatchGuard.

What makes you want to hook CreateFileW anyways? Maybe there is a better solution for your requirements?

The reason why you see same address across processes you can set a preferred base address for your modules. If the address is not in-use you'll get that memory space, if not it will be relocated. Since Kernel32 (depending on PE) is loaded very early stages unlikely the other non-system modules. So, Kernel32 will generally always get it's preferred base address. You can however relocate it so don't rely on the address been static.


Verification methods of IDP in SAML2 IDP initiated login

The IDP is typically verified by a a cryptographic signature on the messages it sends to the SP. These are produced using the IPD private key. If the private key is lost anyone could predent to be the IDP.


You should first investigate the IP and block further. If you do a reverse lookup, just typing nslookup 205.202.182.4 into a command line, you'll see:

Name:    mil_shs_4.mil.esu3.k12.ne.us
Address:  205.202.182.4

Looking the subnet up in ARIN it's owned by the university of Nebraska, but the address looks like it belongs to an elementary school. So, nothing to do with the UK MoD.

So does this help you? Maybe, if you have nothing to do with a school at Murdock, Nebraska then one of their servers may be owned, and is being used as a C&C server for malware on your computer. If your system is connecting to this often then it's quite possible you've been hacked. Whether that is why your email accounts were locked is a different story, but it's reasonably likely.


SQL Injection How to inject Clean/Rest URLS

There is no magic test for testing for sql injection. Some applications may be vulnerable when using a certain approach and others when using another.

There is a chance that http://example.com/kb/8'/41 would not work because apostrophes are blocked by an IPS, but http://example.com/kb/7%2B/41 would display the same result as http://example.com/kb/8/41 and this would give you the information that there is a problem there.

Just testing with quotes is a little better than not testing at all, but cannot be labeled as a security evaluation. Such a process involves a complex assesment of all the posible entry points in your application(parameters, cookies, headers, etc) and several other more complex tests.

If you have the possibility, the best solution is to use a white box approach and also review the code. This way you could clearly see if a certain parameter is properly sanitized or not.


can i execute javascript in href when i have text before my input?

Yes
If the data you inject is arbitrary and not filtered at all, you could inject "><a href="#
This will end up with the following DOM elements:
Back


How much faster would computers be if not for security?

In a modern computer, separation of user process is enforced with the MMU. The MMU decides for each page (a block of RAM, usually 4 or 8 kB, depending on architecture) the relevant access rights, but also where the page actually is in physical RAM. Though the MMU is critical for the security framework, it also has a lot of other usages which grant extra functionalities which increase computing power, rather than decrease it:

support for virtual memory;
on-demand loading of mapped files (in particular executables);
copy-on-write forking.

When you have a MMU which can do the above, expanding it into a tool for security is basically "free": you have the MMU for functionality and performance, and you get security with it as well. In that sense, "without security", computers would not be faster.

There are corner cases, though. For instance, I know a researcher who has long specialized in discrete logarithm cracking. The best known algorithms for such tasks imply a task called sieving in which a computer will use a big array of bits (several gigabytes) and make seemingly random accesses in it. The MMU uses in-memory tables to store the metadata for each page; though the MMU has a dedicated cache (the TLB) to keep the most accessed page entries, random accesses in gigabytes of data imply that most accesses will cumulate cache misses: for the data itself, but also for the MMU tables. Bottom-line is the following: by booting his PC on a custom OS with no MMU usage, he could run his code about three times faster than with a "normal" operating system. Of course, without the MMU, no process separation either -- which was not an issue in his case, in particular since his custom OS was not multitasking anyway.

MMU-less architectures are common in small embedded systems. Not having a MMU does not make such systems faster; it makes them cheaper, because a MMU-less CPU can be smaller by a few thousand gates (it won't matter much on a PC with its billions of gates, though).


Any scenario for using both, OpenID Connect and OAuth 2.0?

Short answer is that it is undefined. If you want a library that supports both, ensure it explicitly states it supports both OAuth 2 and OIDC.

If you were to draw a Venn diagram, OAuth 2 and OIDC intersect each other but OAuth 2 also defines some flows that OIDC does not extend, and OIDC adds a flow that is not in OAuth 2.

OAuth 2 flows:

Authorization Code Grant
Implicit Grant
Resource Owner Password Credentials Grant
Client Credentials Grant

OIDC flows:

Authorization Code Grant
Implicit Grant
Hybrid

The OIDC specification explicitly extends OAuth 2's authorization code and implicit flows, but says nothing about the others. Therefore a given OIDC implementation may fully or partially or not support the remaining OAuth 2 flows. By partially I mean, it only returns the access token as per OAuth 2, but not ID token.

So why doesn't OIDC explicitly cover all OAuth 2 flows? Here's what I think:

Resource Owner Password Credentials Grant. This flow defeats the security features introduced by OAuth 2's authorization code grant. From a security perspective, stay away from this flow.
Client Credentials Grant. One example of this scenario is service to service communication, which could be solved with PKI - does not need ID token introduced by OIDC.


Does the iOS 10 keyboard click sound divulge too much?

While similar to old fashioned shoulder surfing, this attack has some severe limitations:

You need physical proximity - you need to hear the tapping sounds. That means it can not be automated.
While you do decrease the entropy of the password you do not get the full password. For this to be useful you would need some more information - e.g. a leaked hash (that is now faster to crack since you can narrow down the dictionary) or an other password that this is believed to be a variant off (like password1 instead of just password).

Because of these two limitations I can only see two reasonable scenarios:

For extremely high value targets, sending out someone listening for tap sounds might be worth the effort. But nobody reading this is that interesting...
It could potentially be used by a significant other or someone else close who already knows some of the passwords the victim use, and does not need excuses to be in listening range.

In conclusion I am with Apple on this one. The increased usability probably outweight the tiny loss of security. If it bothers you, you can always turn of the tap sound completely. But that is not a security advice I would bother giving to an ordinary user.

And do note that even the old tapping sound would let a listener deduce the length of the password.

(On second thought, they could have deactivated the different sounds for password fields, and keep them for everything else. That would have been better. But I would not loose any sleep over it.)


Email phishing scam asking customers for card details

1) Contact gmail, and ask them to shut down the gmail account that your customers would send their details to if they fall for the scam.

2) Notify all your customers that this is a scam, and they shouldn't reply to phishing emails like the one above.

3) Spend a bit of time and energy on finding out how/why this happene, and if possible who did it. E.g. a) SQLi on a customer database accessible through your website? b) Insider job? c) ....?


Why do viruses that wipe boot sectors exist?

Some people think that breaking stuff is funny (or, in other words, they do it "for teh lulz"). It's possible there's some other explanations, of course - maybe they have an ethical objection to software piracy and think anybody who attempts it deserves to have their system wrecked, maybe the program attempted (or would have attempted, if given more time?) to exfiltrate your data (for identity theft or similar) rather than just delete it and nuking the boot sector was just an unrelated "make the nastiest malware possible" target, maybe the malware was going to replace your boot sector with one that ave very low-level persistent access to your OS and it was either incompatible with your machine or didn't have time to finish that task... Lots of possibilities.

There are absolutely no lack of malicious programs that combine wanton destruction with attempts to either gain money or send some sort of message (political, social, or simply an "I'm better than you" brag). Obviously for some common types of malware, like botnets including cryptominers, you want the target machine to remain operational; making it unbootable is contrary to that goal. On the other hand, if the goal was data/identity theft, preventing you from getting back online for a while may give the attacker more time to run amok with everything from your Amazon.com account to your social security number (or equivalent). I recommend changing your passwords and watching your credit score (or freezing it) for a while.

As a side note, antivirus is not a safeguard against this kind of thing. Antivirus is a last-ditch attempt to deflect the bullet you've already shot at your own foot, and it's not very reliable about it. If you get to the point where you think "if only I'd had a real-time AV running..." you've already screwed up, massively. Don't expect AV to save you. If the malware is old enough, and insufficiently obfuscated, and not bypassing the scans in some way, it will probably work, but it's like setting up a camera that does facial recognition of everybody approaching the house and checks against a police database. There's so many ways to avoid it...

Also, all versions of Windows released in the last ~10 years (so, the only ones still supported and receiving security patches) have built-in AV (with real-time scanning). If you don't want to use those, there are a number of free third-party options too...


Could browsers improve security of stored passwords by using setuid?

This idea is in no way specific to web browsers. You could make the same argument that every application the user runs deserves to have its own segregated user ID under which to run.

Yes, some measure of security would arguably be gained by doing this because (for example) the malicious music player running in the same desktop session couldn't access the web browser's stored passwords. But I think you'd quickly find that the scheme as presented is impractical. The user wouldn't be able to access that file they downloaded with the web browser from their email software in order to attach it to an email, or for that matter from the file manager in order to delete it.

That's besides the fact that each system user now requires N users in /etc/passwd where N is the number of different applications they run. Not only does the system not provide any way of managing those accounts and switching between them, but it's just plain messy.

Your idea is a fairly significant departure from the UNIX security model but it has merit, and with the right kind of help from the operating system it can be done cleanly. Android works more or less exactly like this..


As Wilson Wong says, all browser requests should be routed via the proxy depending on how the browser is configured / whether there is any transparent proxying implemented on the default route.

It is possible to determine the IP address by other means


Can Geolocation of an IP be guessed based on some pattern matching?

No, there is not. Blocks are moved, sold and sometimes mobile. Most base data comes from WHOIS databases and RIR databases, which are public. Refined data based on user data is added by some parties to make it more accurate, for example, gps, cell and wifi networks often are fixed locations and are sometimes submitted to profiling and advertising services when you use apps on mobile devices or shop online. This is also why the data can sometimes be very inaccurate; a fixed internet connection might have an IP from a block that is listed with the address of a regional ISP office instead of the service area where that block is used. This data usually gets updated when an ISP sells or moves or devides a block and updates the WHOIS data.


How to find out the Chaff packets of WEP?

You are mistaken chaff packets are sent by tools like aircrack-ng to force WEP to transmit more IV collisions and thus break the key faster.

IDS's like Snort has rule-sets to detect chaff packets.  But your looking for the opposite,  your looking for aircrack-ng.  You can use the ivstool to convert pcap files.  Although you will probably be more successful starting the attack from scratch because you can inject chaff packets which greatly speeds up the process.


Why in LD_PRELOAD exploit we call unsetenv(LD_PRELOAD)?

Environment variables such as LD_PRELOAD are inherited by child processes. The linked example overrides the _init symbol to invoke a shell using system("/bin/bash"). If the environment variable would not have been cleared, then it would effectively be stuck in an "infinite loop" when invoking system.

If you watch your process list (using ps aux for example), you will see a bunch of shell processes. The system library function creates a new process and executes /bin/sh -c "....". Every time, _init is executed.


How can I determine if a CA Cert can be used for DPI-SSL

DPI-SSL works by doing a man in the middle attack: it frames the right server by dynamically generating a fake certificate for that server. This works only if the corresponding CA (the one which issues the fake certificate on-the-fly) is "trusted" by the client. By definition, this CA "looks like" any other CA It is different from the "normal" CA only in that the private key is owned by some system which does the DPI, but this is not written on the certificate itself.

What you can do is compare the certificates that your machine trusts with that from the "root CA" store of a generic desktop system; compare the "thumbprints" (these are the hash values computed over the root certificates themselves). Presumably, the default root CA are not involved in DPI; any extra certificate is then a potential suspect.


Does injecting querystring values directly into HTML pose a security risk?

Plaintext injection is an issue. Say you have a page template that looks like this:

Hi <name>,

Blah blah blah.

And you can inject  from the URL.

An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%0D%0AHi%020Foo (which could also be minified).

This will make your page look like:

  Hi Foo, you have the wrong version Flash plugin, our company policy requires that you use version vul.ne.rabl.e.

  Hi Foo,

  Blah blah blah.

The message looks like it comes from your site, and since your users trusts your site, they will likely believe the instructions that "you" have given.


Strange Pharma Spam Site resulting from DAT file created by SQL Injection?

There are just so many things that could have happened. I'll try and list all ideas I have of what could possible have happened.

You could try the following:

Check the .htaccess file if it contains anything
Check the routes file in codeigniter which handles redirection, it is located at /application/config/routes.php and check if there are any re-directions in there.
search through all php files using the command line and look for "base64_decode("
Delete the .dat file perhaps?

You could also try and search for files with large hashstrings that are usually used to obfuscate code, enter the following code in shell:

find ./ -name "*.php" -type f -print0 | xargs -0 grep '[a-zA-Z0-9]\{400\}'


Should password reset disable biometric sign in until the user signs in with username and password again?

Based on your description, biometric and username/password appear to be independent authentication factors (option A). That is, if either one of them can be used to sign in and one factor is enough, then you should keep them independent for the recovery/reset process. Resetting a factor (password or biometric) should not impact the other factor.

User perspective: I forgot my password but I still have my biometric so I am going to use it to sign in and use the app. Once I am signed in, I can hopefully change my password with fewer identity-proofing steps versus a reset.

Attacker perspective: it depends on the threat model. Given physical access to the device, recovering a biometric or using a synthesized biometric to authenticate is possible but is it worth it? The answer to this question would have to come from a risk assessment of your app and associated assets, including the identity of the user.

Operational perspective: are your users going to be contacting you/Operations/Helpdesk if they aren't able to sign in because you shut off their biometric when they forgot their password and attempt to reset it? That would be expensive for Operations (each "call" costs money) + encourage more social engineering attempts.

Brand / reputation: If you shut off their biometric and self-service password reset has challenges, that sounds worse than option A. Could they be leaving angry reviews in an app store or complaining to your management / client in a corporate environment? That would be expensive to your personal brand or your company or your client.

You didn't say how the password reset works but it's worth mentioning that using a biometric to reset the password is definitely a good idea. NIST
800-63b, section 6.1.2.3 (Replacement of Lost Authentication Factor):

  Replacement of a lost (i.e., forgotten) memorized secret is
  problematic because it is very common. Additional “backup” memorized
  secrets do not mitigate this because they are just as likely to also
  have been forgotten. If a biometric is bound to the account, the
  biometric and associated physical authenticator SHOULD be used to
  establish a new memorized secret.


It's not normal behavior for it to just log you in by username.

My best guess is that you have the password saved either in the RDP program or your gnome keyring or something like that.

An easy way to test would be to change the password on the windows machine and see if it starts prompting you for a password again.


Stealing client certificate using Cross Frame Scripting

The private key of the client certificate does not leave the client during the TLS connection same as the private key of the server does not leave the server (see How does SSL/TLS work for more details). Thus it is impossible for the attacker in your scenario to get the private key.

As for the certificate itself (i.e. the public part). If the attacker manages to setup a server this way that it requests a certificate from the client (maybe need to configure the accepted CA) then the client will authenticate itself with this certificate (maybe asking the client first) and thus the attacker can get the certificate itself, with all the public information it contains. The same information can be accessed by any attacker passively sniffing the connection with the original server since the client certificate (i.e. the public part) is transferred in clear.


Are there any systems to mitigate the risk of losing a Signing Key?

Both PGP and the global SSL PKI solve this problem in roughly the same way. You create a super "trusted" key with a long expiration which you guard with religious fervor; key stays encrypted, tucked away in a holy temple, only ever glimpsed by duly anointed CSOs, that sort of thing. It's the one you trust. You do not use it.

Then with that key, you sign your "every day" key. It has a relatively short expiration, but you follow best security practices with it nonetheless. Still, it goes where it is needed to go.

When you ever suspect that the "every day" key may have been compromised, you revoke it and sign a new one with the holy temple key.

Revocation is as simple as keeping a list of revoked keys (probably their hashes) in a globally visible location. That list should be signed. When someone checks whether to trust a key, they check the key's signature path up to a trusted root. They also check the revocation list.

Performance of key revocation checking is an issue, but if your key infrastructure is small, you can easily have only one global revocation list which you push to everyone on a regular basis.


You should watch Moxie Marlinspike's talk Defeating SSL using SSLStrip.  In short SSLStrip is a type of MITM attack that forces a victim's browser into communicating with an adversary in plain-text over HTTP, and the adversary proxies the modified content from an HTTPS server.  To do this,  SSLStrip is "stripping"  https:// URLs and turning them into http:// URLs.

HSTS is a proposed solution to this problem.


Does sending two different hashes of the same password reduce security?

As the llama says, there is little point in pre-hashing the password on the client side: SSL protects you. Of course this assumes that you use SSL for all communications; if you do not, then you already have much bigger problems that you should tackle first.

If an attacker sees "SHA-512(password + long_string)" then the attacker can run an offline dictionary attacks on that password, i.e. trying potential password values until a match is found. Of course, this assumes that the attacker knows "long_string" but since both client and server know it, and it has not been entered by the human user, then one must assume that the "long_string" is either provided by the server prior to user authentication, or is hardcoded in the client code. Either way, it is unreasonable to assume that the attacker does not have it. The dictionary attack will run at a rhythm of several millions of tries per second, because, let's face it, a basic PC is really good at computing SHA-512.

To some extent, if "long_string" is really long (we are talking megabytes here), then the cost of hashing may become non-negligible and thus slow down the attacker. Such slowness is half (but only half) of what makes a good password hashing function. Note that cryptographic algorithms are subtle: "SHA-512(long_string + password)" would be much weaker, in that respect, than "SHA-512(password + long_string)" (if you do not see why, then don't touch that keyboard again). The second half of good password hashing is about deterring parallel attacks, which, in this case, would mean that each user has his own "long_string" value, distinct from those of the other users. The "long-string" then acts as a salt.

Your alternative, with "SHA-512(username + password)", fails at the slowness parts, and imperfectly ensures the non-parallel part (because user names are not unique worldwide, and are also reused when the user changes his password). Depending on how "long_string" is chosen in the original system, your proposal may weaken or strengthen the security.

The answer to the exact question is that if the attacker see both values then he can choose which one he will attack, and this can only help him. However, a more thorough answer is that:

You should send passwords only through a properly secured tunnel (SSL), at which point there is no good reason to hash the password on the client side; thanks to SSL, the client knows that it is sending the password to the right server, and only to that server. Simply send the password "as is".
If you plan to use the hashing as a storage mechanism on the server (i.e. the server does the hashing, not the client, and the result is stored in the server's database) then your new system may be slightly better than the previous, or slightly worse, but both are weak anyway. Go read that answer; it would be most unwise to design cryptographic systems with password until you understand it thoroughly (you do not need to agree -- Science without debate is no longer Science -- but at least you should understand the concepts).


The answer depends upon the threat model, and what threats you are trying to prevent.

A standard strong method is to use public-key based authentication, such as the following examples:

The client connects by SSH.  The client authenticates using its personal DSA key (not protected by any passphrase).  Or,
The client connects over SSL.  The client authenticates itself using a suitable client certificate.  The client checks the server's certificate to make sure it is talking to the server it expected to talk to.

This approach is pretty good for most settings.  It is secure against network-level attacks.  Of course, the client's private key lives in the clear on the client machine.  (It pretty much has to.)  As a consequence, any attacker who breaks into the client machine can steal the client's private key.

If you need to detect against the threat of a compromise of the client machine, you could store the private key in a HSM or smartcard connected to the client machine and have it authenticate in that way.  This provides modest security benefits: an attacker who compromises the client machine can no longer steal the client's private key, but the attacker can still make arbitrary connections to the server as the client and send arbitrary data, for as long as the attacker maintains its control over the client.  Whether this is a security improvement or not (compared to just storing the private key in the clear on the client) depends heavily upon the application.  Also, whether this is worth the extra cost and hassle of the HSM or smartcard is heavily dependent upon the application as well.

There are other approaches as well with some slight advantages and disadvantages compared to the above, but nothing that is overwhelmingly superior.


Is it possible to know imei number of other mobile using any sort of wireless technology?

Businesses that are worried about mobiles being used in unauthorised places uses technology that might be useful to you.

I wrote an answer on the Academia StackExchange with some products but I think only AirPatrol (though I note on the site AirPatrol now says they don't collect IMEIs, check with your sales rep) and Libelium will be relevant. Some of these you can buy multiple sensors to work out which "zone" the mobile device is being used in.

These will typically list the IMEIs of broadcasting devices and as they do not interfere with them or broadcast on licensed spectrum themselves I believe are legal (but IANAL). Still I'd be surprised if they were illegal to operate given they sell them!


How can TrueCrypt encrypt a System Drive on a live OS?

All applications (even the OS itself) talks through modules (called drivers) to speak to any piece of hardware, In windows this is called the Hardware Abstraction Layer (or HAL). So any request would be

Software making the request -> Hard Drive API in OS -> HAL for Hard Drive type -> Controller board on Hard Drive -> Bits on physical media.

What TrueCrypt does is it adds a new HAL driver so now the request goes

Software making the request ->  Hard Drive API in OS -> TrueCrypt Encryption driver -> HAL for Hard Drive type -> Controller board on Hard Drive -> Bits on physical media.

So to anything making a request to the hard drive nothing has changed, it sees the same API for talking to the drive, but underneath that layer you added your encryption shim.

The bootloader for TrueCrypt loads the driver when windows or linux first boots and then the OS takes over from there passing the information through the encryption driver.

P.S.

For drives that support hardware based encryption, it uses a sightly different model.

Software making the request -> Hard Drive API in OS -> HAL for Hard Drive Type -> Controller board on Hard drive -> Encryption firmware -> Bits on physical media.


How do I use never remember history in Firefox effectively?

Remembering history is convenient, but history can also be detected in various ways by remote sites, allowing them to determine if you’ve been to www.creepy.com or www.HIVinfo.org .

Turning off remember history eliminates that, but all kinds of links and images are written to temporary disk cache that although deleted later is still recoverable. Strong passwords are irrelevant unless your drive is encrypted.

Private browsing mode keeps everything in memory and eliminates disk cache.

Anonymity is a whole different question.


Guessing speed in offline password cracking

It depends on several factors.  Primarily, how are the passwords stored?

The current best practices are to use a key stretching algorithm. The NIST specifically states using key derivation algorithms that are like PBKDF2 and Balloon (13th paragraph, 5.1.1.2, not counting the bulleted list as a paragraph). The community typically lists PBKDF2, bcrypt, scrypt, and Argon2, with PHP providing bcrypt and Argon2 for its password_hash() function.

The link for Argon2 is to its white paper. Between this and the NIST standards, these are hopefully citable documents, and the Argon2 white paper includes additional citations.

The reasoning behind making their use a best practice, is these methods have configurable difficulties, and an administrator setting up the authenticator for their system should tune their chosen method to make brute-force guessing prohibitively expensive.

If the cost is tuned to require enough work for a processor core to be tied up for a full second, this has little impact on, for example, a web server that occasionally handles authentication. A user can be reasonably expected to wait for a second, and other users will be minimally impacted, as many web servers have multiple cores.

On the other hand, a naive attacker will only be able to guess one password each second, per core, and some key stretching algorithms specifically target features that make (expensive) memory more valuable (Argon2, scrypt), or make parallel processing, such as with multiple GPU cores, much slower (Argon2, bcrypt).  While a dedicated attacker will generally have more resources to devote specifically to brute force verifying passwords, they would still only be guesses tens of passwords per second, rather than the millions or billions of guesses possible with modern ASICs attacking hash algorithms.

If the passwords are stored as just salted hashes, though, there exists hardware that is especially suited for a very similar task, and it would take very little to design an ASIC that performs comparably: Bitcoin miners. While a hash guesser would probably be far more expensive on a per-unit basis, due to the economies of scale that Bitcoin miners enjoy, a single $2,400 unit can perform 14 trillion bitcoin hash guesses per second.

General purpose GPU-based attacks against hashes and common password encryption/obfuscation systems that don't use properly configured key stretching algorithms can typically make millions to several billions of guesses per second, depending on the algorithm, as shown in the benchmarks that Luc linked in a comment.


How to determine the good number of PBKDF2 iterations according to technology evolution?

There is no "sufficient" count, because user-chosen passwords can always be utterly weak, regardless of how well you coach them. You want the count to be the highest value that you can tolerate.

Remember that increasing the iteration count mechanically increases the operational cost. So you will have to set the count to a value which is low enough for your machine to still be able to process passwords in a timely manner. This is an analysis that you must make yourself, because it depends on your hardware and the expected peak load, and user tolerance to delays. Higher iteration counts tend to increase vulnerability to denial-of-service attacks.

You do not increase the iteration count on a regular basis to match "average technology". You increase the iteration count when you can afford it, which depends not on the general availability of faster servers, but on the servers that you actually bought and are using. Thus, you plan for an iteration count increase whenever you buy new hardware.


Do integrity and authentication always come together?

You are not missing anything.  There is no meaningful distinction in cryptography between ‘integrity’ and ‘authentication’ of data on a channel between two parties.  Any attempts at distinction in the context of an adversary wallow in confusion of epistemology without a difference.  (If you really like the cute acronym CIA for spook stuff, maybe use the A for ‘availability’ instead!)

The words are not entirely synonymous, of course—for example, a dishonest politician does not lack ‘authentication’, and logging into your bank's web site is not doing ‘integrity’—but it sounds like you're asking how they apply a protocol in which there are three things:

A sender; call her Alice.
A channel or medium for exchanging messages, such as the internet, or a disk for storing and retrieving files.
A receiver; call him Bob.

Alice's goal is to transmit a message to Bob using the channel.  Presumably, the channel is subject to malicious tampering by an adversary; otherwise there's no security question here.  Presumably, Alice and Bob know something about one another a priori; otherwise when Bob receives a message there is necessarily no way he can distinguish a message Alice sent from a message the adversary sent!

Under what circumstances, then, does the protocol have authentication or integrity?  Either way, what it means is that—whatever steps Alice takes to send a message, and however Bob verifies the authenticity of a message—the probability that an adversary succeeds in fooling Bob into accepting a forgery is negligible.

In cryptography, we formalize the notion of ‘authentication’ or ‘integrity’ with the EUF-CMA game—existential unforgeability under chosen-message attack.  In the EUF-CMA game, Mallory, our heroic adversary, can ask Alice to send any message of Mallory's choice, in order to study how Alice is authenticating messages.  Mallory wins the game if they can fool Bob into accepting any message Alice didn't send.  Mallory would win the game even if the message is totally meaningless to Bob.  The protocol is said to provide EUF-CMA security if the probability that Mallory wins this game is negligible no matter how clever they are.

The EUF-CMA criterion applies to both symmetric-key authenticators, also known as message authentication codes, and public-key signatures; the main difference between authenticators and signatures is whether the power to send a message is the same as the power to verify a message, or whether the powers are asymmetric so that when Alice signs a message, anyone—Bob or any third party—can verify it too.

Outside cryptography, one might reasonably consider a sort of unintelligent adversary—a channel with random noise—and one might use an error-detecting or error-correcting code to provide integrity, meaning that the probability of undetected corruption is substantially smaller with the code, whereas the term authentication doesn't really come up in coding theory at all, so there's no contrast to make between the terms in that context.  One might even use a ‘cryptographic hash function’ like SHA-256, truncated if you have limited bandwidth, but one would be better off with a CRC.


how can an external service see what web browsers are connected / have been connected to my server?

They might be accessing data which was collected from any tracking services you are using (google analytics or an advertising service, for example). Either publicly available information or information they bought.

Alternatively, it is possible that they simply try to access your website with a User-Agent header of an outdated browser to see if they get blocked. If they don't get blocked, they will deduce that since your website is public-facing and since there is still a significant number of internet users who use outdated browsers and since you don't stop them from visiting your website, there must be some of them who indeed browse your website with their malware magnets.

  I don't see how I can be responsible for what browser version a client uses?

Outdated web browsers might lack security features which newer browsers have, like protection from cross-origin request forgery, heuristic XSS detection or protection from browser-hijacking malware. If you do things you shouldn't be doing (like integrating arbitrary HTML content from servers not under your control) and assume that the modern web browsers will protect your visitors from anything that could go wrong, then you are putting your visitors in unnecessary danger.

Further, visitors with unsafe software configurations might be infected with malware. That malware might perform actions on your website the user isn't aware of. Online banking trojans, for example. If you are running an online banking website, then a user infected with malware who tries to pay their plumber might send their life savings to hackers in Nigeria instead. That might technically not be your fault, but the user might still try to hold you responsible. A good lawyer might protect you from having to pay for the damages (if you are lucky), but not from the PR fallout.

But what can you do about that?

Well, you could try to detect outdated web browsers by browser fingerprinting and reject them. But it usually goes against your business objectives to reject otherwise desirable customers. The better approach would be to fix those security problems on your website to make sure that even outdated browsers can use it safely. Because, as you reasoned correctly, a public website has no control over the software configuration of its visitors.

OK, but why doesn't the tool report these vulnerabilities instead of telling me to be careful about the browsers people use?

Because the perceived value of such tools is by what they report, not by what they don't report. That's why such tools usually err on the side of caution and tend to over-report irrelevant problems. If the tool just tells you "everything is OK, keep doing what you are already doing", you wouldn't perceive it as very valuable. So they make sure to include a couple tests which result in a couple positives on almost all websites they check, even if the actionable advise which can be taken from these results is minimal.


What is the state of the art precaution to try out dubious software most likely safely today?

It depends how thoroughly you'd like to try them out. I'm going to assume that you're not looking to understand everything about how the application works, but are more interested in taking it for a spin without cryptolockering yourself.

My suggestion would be to use a non-networked VM. VirtualBox or Hyper-V are both free, and you can download trial versions of Windows here.

If you wanted to get a bit more thorough, you could look at outbound DNS queries from your VM for shady domains.


WCF - Is this a good security Architecture?

If you know what you're doing, using WCF isn't difficult. If you know what you're doing, using WCF with an STS isn't terribly difficult. If you don't know what you're doing it's all terribly difficult. Who am I kidding, it's WCF, so it's all difficult. :)

Generally speaking your architecture falls into the federated trust category, as you're using the STS to provide authentication. I'm a little confused as to why you say the token is effectively just a GUID. Normally with WCF it's a SAML (wrapped in a WS-Trust container) token, which contains attributes/claims about the given identity. A lot of times the user's roles are contained in the token already. It's up to the STS to provide the roles, and your services just check to see if the incoming identity has the requisite roles (in a simple scenario, anyway).

From a security perspective it all gets a bit messy for a few reasons:

WCF is a PITA
WCF security relies heavily on certs, which introduce their own issues
STS are difficult to build securely so the recommendation is to use pre-build STS
Using pre-built STS rarely do what you want them to do out of the box

If you can work through these issues you can have a reasonably secure implementation of the services, however that's relative to what you're wanting to protect against. What are you wanting to protect against and what aren't you wanting/willing to protect against?

One of the weakest points of a federated system is the crypto. How do you protect the keys such that the STS can use them, but people can't steal them? You said you wanted to use client certs for mutual auth... how are the clients protecting those keys? How are you issuing those keys? You said client certs for SSL mutual auth... does that include certificate-based auth for the STS auth of the users, or are you going to use username/passwords? Are you going to encrypt the token between the STS->client->service, or will it be plaintext? Normally you'd encrypt the token as it contains sensitive information. How do you protect the encryption keys for the services?

A federated trust is a good architecture, but it really depends on the use case. It's usually when you're wanting to decouple the authentication/authorization of users from the services themselves, and centralize them into a single source. Since you've got 4 services, it sounds like it might be a good thing. However there is a huge added overhead with the STS (this now makes it 5 services), as well it's usually hosted in it's own site.

For more information take a look at the Thinktecture.IdentityServer project: http://thinktecture.github.io/Thinktecture.IdentityServer.v2/. It's an open source STS built by people that have worked closely with Microsoft's WCF and WIF team.


Can a bug in an application that has no internet connection be used from outside

Directly? No. By your scenario's definition, the "bug" is local to the computer and not a matter of a bug in its networking or communications (because it doesn't have that function).

But if the computer is accessible by other means, then once access is gained, the bug can be exploited. That's why it is still very important to update applications even if they do not have network access.

It is a common scenario that an attacker gains partial network access to a computer through some bug in some other application or a misconfiguration, or by tricking the user to run malware. And while that access is limited, it grants access to another vulnerable local application that the attacker leverages to get deeper access, and depending on the bug, and in a worst-case scenario, full control over the computer.


Academic/Campus WiFi Security - Setup: Open

At the front end, it may not seem very secure. All that is used for verification is the MAC, and that is easily spoofed. An unregistered device on the campus should be able to sniff the network traffic as well. But you need to be on location (or close by).
CERN has explicitly chosen to offer just a bare level of security on the network. Or, to put it in CERN's own words:

At CERN, the individual users are in first instance responsible for securing their computers, networks, data, systems & services.

(CERN Computer Security Announcements)
and

As the “CERN” Wi-Fi network security mode is “open”, no specific settings are required (no WPA, no 802.1x options, etc…), but please note that this also means that the traffic you send over the Wi-Fi network is not encrypted. You should ensure that any sensitive data is encrypted at the application level (SSH, HTTPS, SSL, VPN, etc.).

(CERN WIFI Service FAQ)
On the other hand, most traffic is encrypted anyway (SSH, HTTPS etc.)
In addition, CERN does quite a bit of security monitoring.
So, is it safe? For CERN, safe enough. Would this set-up work in other areas, like financial institutions? Probably not.


Why aircrack asks for info about target that isn't really needed?

Tried to pull out a few questions from this:

Why isn't the ESSID enough?

I'd like to point out that in many large, distributed Wi-Fi setups (think corporate or campus networks), there will be several, possibly many access points (APs) broadcasting the same ESSID in a given physical area. Each AP will have its own BSSID, since each piece of network hardware has its own MAC address. Being able to filter by BSSID allows you to focus on a single AP for attacking. Most attacks will typically target a single access point (e.g. using aireplay-ng, you generally must target a specific BSSID).

Why must I specify the channel?

airodump-ng is fairly low-level and barebones, and makes little-to-no assumptions about what you are trying to do with it, so it makes sense that the channel must be specified manually. Note that aireplay-ng is capable of auto-determining the channel given a specific BSSID when launching some attacks, but this tool has a different purpose.

Setting the channel is also useful if you want to capture all of the traffic on a given channel.

Why can't I specify a dictionary file for airodump-ng?

The main job of airodump-ng is to capture Wi-Fi packets. It makes no assumptions about what you want to do with said captures; whether you just want to log them or are going to try and recover a network's pre-shared key (PSK). The functionality for attacking captured WPA handshakes resides in the separate aircrack-ng tool.

How does deauth help with cracking the password?

It doesn't help with cracking the PSK. We use crafted deauthentication frames to kick devices off of the network so that they try to re-associate, thus performing the 4-way WPA handshake again. The 4-way handshake contains the information that we need in order to crack the PSK offline. Crafting deauthentication packets isn't strictly necessary to obtain the 4-way handshake; devices may (re)connect and perform the handshake on their own. In some scenarios, it may not be desirable to send deauthentication frames since it is a noisy operation and can be detected by wireless intrusion detection systems.


Is it possible to fake 'received' field in the e-mail?

It is possible to add arbitrary fields to the mail and this includes Received headers. But, any proper mail transport server will add a new Received header on top of the mail which means that, depending on the exact delivery infrastructure, the attacker can at most fully fake all but the topmost Received header. In your specific example, the top Received header seems to be some internal server and the next Received header is the one from your mail server at the perimeter which accepts mails from outside. All other Received headers might be faked.

And even the Received header added by the server at the perimeter might contain fake information. It is common that it includes the hostname claimed by the SMTP client within the EHLO or HELO command. Thus, in your specific example mx.beniculturali.it might be faked by the attacker while ([194.242.241.200]) is added by the receiving mail server to show from which source IP the mail was received and cannot be faked.


Is it possible to be infected with malware/virus via a proxy?

A proxy forwards all traffic and therefore has the possibility to also modify the traffic and thus also to modify the traffic in a malicious way, including making the client download malware or exploiting bugs in the client processing the traffic. This is definitely true for plain HTTP but is also true for HTTPS if the client does not properly check the certificate. The latter is often true for web scraping programs (like your project) which often explicitly ignore certificate errors in order to get to the content.

If this is a trusted proxy you control yourself this is likely not an issue. If you instead use an untrusted third-party proxy (which seems to be the case here) then the chance is much higher that the proxy will be malicious. If you treat all data you get as strictly untrusted and potentially malicious and thus properly sanitize these before doing any actions on these this might not be a problem though.


For testing, a simple google search was done in the web browser (firefox).

Search engines today are usually accessed by HTTPS (and this is definitely true with Google). in HTTPS all the HTTP is encrypted which includes the full HTTP request (i.e. the part containing the string "HTTP") and also what is searched for.

Given that Snort only sees the encrypted traffic it will not see the phrases of your signatures in the traffic. These only exist in the decrypted traffic but Snort has no access to this.


What are some good resources for learning how to hack my website?

When it comes to websites, OWASP is a big part of that knowledge. Be familiar with their Top 10 and try them out on your site. There's a lot of other informative information there as well.

Beyond that, any resources related to pentesting are good starting points. Books about Penetration Testing is a good starting point there as well.

There are also a lot of related tools: What tools are available to assess the security of a web application?, and sometimes know those will point you down the right path.

If you're trying to learn a broad scope overview of something, I suggest also check out the tags: https://security.stackexchange.com/questions/tagged/attack-prevention will show you a wealth of good resources to think about when designing you web applications / sites.


Pre-paired hardware security tokens - Why don't they exist?

Having duplicate keys would make manufacturing a bunch trickier, because you have to create exactly two duplicates and then sell them together.  If you accidentally sell a pair of keys that doesn't match, then you've caused a security nightmare, since neither of them can be securely used (since someone else can have the same key).
Also, most security tokens contain a counter of uses and reusing the counter repeats the secret.  For example, a YubiKey's one-time password has a counter as part of the message.  Thus, a second key would be detected as a replay attack and rejected by many sites.
What you want to do is possible using DiceKeys, which is a way to generate a secure 196-bit secret that can then be loaded onto one or more special SoloKeys.  Having a programmable key is easier than providing multiple keys, since the user can program as many keys as they like.
However, as mentioned, in order to support this use case, the special SoloKeys always use a fixed counter of zero, which works for most FIDO2 and WebAuthn applications but wouldn't be usable for OTP use cases.


Your protocol is not safe by any means!

Example for MitM:

A sends random nonce G1 to B
C intercepts and sends nonce G1c to B
B sends back hash_k(G1c) and random nonce G2
C intercepts and sends hash_k(G1) and nonce G2c to A
A verifies hash_k(G1) (is OK), then sends back hash_k(G1 | G2c)
C intercepts and sends back hash_k(G1c | G2)
B verifies and a connection is made

So C can now intercept all traffic...

Also eavesdropping is possible with your protocol...


Ignoring broadcasts to 10.0.0.255 using iptables

A bit dated, but I felt compelled to help expand the discussion/dialog by introducing the idea of blocking broadcast traffic by demonstrating the capabilities of IPTables to filter layer 2 information as well. Specifically, there's  the -m pkttype --pkt-type broadcast command line option.

Here is an example iptables ruleset that demonstrates this option as well as its resultant output:

IPTables: -m pkttype --pkt-type broadcast

iptables -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A INPUT -j ACCEPT

iptables -A FORWARD -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A FORWARD -j ACCEPT

iptables -A OUTPUT -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A OUTPUT -j ACCEPT

RESULTS

[nick@sys]$ iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

While a tangent, there is another interesting option to provide layer-2 filtering based on (source) MAC addresses, which isn't too useful in this case. However, it is interesting if nothing more than to know of its existence. This is the IPTables -m mac --mac-source  command line option. Practically-speaking this option is declared to make sense on INPUT and FORWARD chains (and not the OUTPUT chain). The concept would likely be of more interest for an ACCEPT, versus a DROP or REJECT, action. In the following brief example I ACCEPT broadcasts from the default gateway, but block all others. In this example I pretend the MAC address of the default gateway is: 00:F0:10:03:15:42.

IPTables: -m mac --mac-source

iptables -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m mac --mac-source 00:F0:10:03:15:42 -d 10.0.0.255/32 -j ACCEPT
iptables -A INPUT -m mac ! --mac-source 00:F0:10:03:15:42 -d 10.0.0.255/32 -j DROP
iptables -A INPUT -j ACCEPT

iptables -A FORWARD -d 10.0.0.255/32 -j DROP
iptables -A FORWARD -j ACCEPT

iptables -A OUTPUT -d 10.0.0.255/32 -j DROP
iptables -A OUTPUT -j ACCEPT

RESULTS

[nick@sys]$ iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             10.0.0.255          MAC 00:F0:10:03:15:42
DROP       all  --  anywhere             10.0.0.255          MAC ! 00:F0:10:03:15:42
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255
ACCEPT     all  --  anywhere             anywhere

In this second example I fully realize that the NOT (i.e., '!') notation for the second INPUT rule isn't necessary; however, it is also a neat feature that can be of some use in this question if selective rejection (or acceptance) is desired.


Do WPA-Enterprise implementations have built-in anti-IP-spoofing?

I don't think there is any inherit protection against IP address spoofing in a WPA-Enterprise environment and from a security preservative,  this doesn't really matter because there are other implicit mitigations against ip address spoofing.  Snort and other NDIS solutions have rule-sets to detect IP spoofing,  and ARP table poisoning.  These technologies are usually deployed in an enterprise environment.

Being able to spoof the ip address of another member on the network isn't very helpful if you can't see the response. WPA-Enterprise uses a unique key for each member on the network so you cannot see the response (and you could see this repose if the wifi was unencrypted).

MAC address spoofing and ARP table poising are much MUCH  bigger threat than ip address spoofing.  You can always forge a packet with an arbitrary source address,  if you are unable to receive traffic on this IP address then you cannot complete the TCP three way handshake,  and thus unable to establish a TCP connection.  UDP and ICMP are fair game,  but even then there is a very limited impact.


Generally, PGP key servers resolve conflicts by not resolving them. Key servers store public keys. If they get several public keys which somehow "collide" for some notion of collision (say, both keys relate to the same email address), then they just keep all of them. And that's by design. In particular, fake keys cannot be deleted. The whole concept of the PGP Web of Trust is that trust comes from the signatures, not from the key servers, who are just storage areas (or, more often, garbage dump areas).

See for instance the MIT PGP key server FAQ:

  1. Can you delete my key from the key server?

  No, we cannot remove your key from the key server. When you submit a key to our key server the key is also forwarded to other key servers around the world, and they in turn forward the key to still other servers. Deleting the key from our server would not cause it to be deleted from any of the other servers in the world and so this is not an effective way to ensure the discontinued use of your key.

  2. So, you can't delete my key, is there anything I can do?

  If you still have the private key, you can use your PGP software to generate a revocation certificate, and upload that to the keyserver. The exact procedure for generating a revocation certificate varies depending on what PGP software you are using, please consult the documentation for more information. This will not delete your key from the key server, but it will tell people who download it that the key has been revoked, and should not be used.

  3. But the reason I want to delete my key from the keyserver is that I lost the private key (so I can't generate a revocation certificate), can you please delete my key for me?

  No.

I quite like the definitiveness of the answer to the third question.


understanding client certificate - pfx on the general

So let's tackle easy first:

Q1/Q2 you can see your certificates in the certificate manager a.k.a. certmgr.msc

Q3 your scenario is probably wrong. If you are provided with a client certificate, it is probably already signed by some certificate authority (maybe an internal CA used by the service you're trying to access maybe).

Therefore, the CSR workflow don't have to happen here, since you do not need to generate a certificate from a freshly generated key pair.

If you are referring to the process of creating the certificate prior to you getting one shipped, then you are correct. Public key goes into a CSR with your info. Some CA signs it. You need the root CA of the chain.

The last part is the authentication. I'm currently looking for the right protocol, if there is one. But what should be done is:

check the signature of the certificate against the CA public key
check the validity of the certificate
check for revocation
check the subject of the certificate (from who it comes from)
assess proof of possession (through a challenge)

The client certificate might not have to be send, if there is a public keystore for the webservice.

Resources :

oracle - Sun Directory Server Enterprise protocol
The bear stance on client cert validation


How do the processes for digital certificates, signatures and ssl work?

There are a few confusions in your post. First of all, HMAC is not a hash function. More about HMAC later on.

Hash Functions

A hash function is a completely public algorithm (no key in that) which mashes bit together in a way which is truly infeasible to untangle: anybody can run the hash function on any data, but finding the data back from the hash output appears to be much beyond our wit. The hash output has a fixed size, typically 256 bits (with SHA-256) or 512 bits (with SHA-512). The SHA-* function which outputs 160 bits is called SHA-1, not SHA-160, because cryptographers left to their own devices can remain reasonable for only that long, and certainly not beyond the fifth pint.

Signature Algorithms

A signature algorithm uses a pair of keys, which are mathematically linked together, the private key and the public key (recomputing the private key from the public key is theoretically feasible but too hard to do in practice, even with Really Big Computers, which is why the public key and be made public while the private key remains private). Using the mathematical structure of the keys, the signature algorithm allows:

to generate a signature on some input data, using the private key (the signature is a mathematical object which is reasonably compact, e.g. a few hundred bytes for a typical RSA signature);
to verify a signature on some input data, using the public key. Verification takes as parameters the signature, the input data, and the public key, and returns either "perfect, man !" or "dude, these don't match".

For a secure signature algorithm, it is supposedly unfeasible to produce a signature value and input data such that the verification algorithm with a given public key says "good", unless you know the corresponding private key, in which case it is easy and efficient. Note the fine print: without the private key, you cannot conjure some data and a signature value which work with the public key, even if you can choose the data and the signature as you wish.

"Supposedly unfeasible" means that all the smart cryptographers in the world worked on it for several years and yet did not find a way to do it, even after the fifth pint.

Most (actually, all) signature algorithms begin by processing the input data with a hash function, and then work on the hash value alone. This is because the signature algorithm needs mathematical objects in some given sets which are limited in size, so they need to work on values which are "not too big", such as the output of a hash function. Due to the nature of the hash function, things work out just well (signing the hash output is as good as signing the hash input).

Key Exchange and Asymmetric Encryption

A key exchange protocol is a protocol in which both parties throw mathematical objects at each other, each object being possibly linked with some secret values that they keep for them, in a way much similar to public/private key pairs. At the end of the key exchange, both parties can compute a common "value" (yet another mathematical object) which totally evades the grasp of whoever observed the bits which were exchanged on the wire. One common type of key exchange algorithm is asymmetric encryption. Asymmetric encryption uses a public/private key pair (not necessarily the same kind than for a signature algorithm):

With the public key you can encrypt a piece of data. That data is usually constrained in size (e.g. no more than 117 bytes for RSA with a 1024-bit public key). Encryption result is, guess what, a mathematical object which can be encoded into a sequence of bytes.
With the private key, you can decrypt, i.e. do the reverse operation and recover the initial input data. It is assumed that without the private key, tough luck.

Then the key exchange protocol runs thus: one party chooses a random value (a sequence of random bytes), encrypts that with the peer's public key, and sends him that. The peer uses his private key to decrypt, and recovers the random value, which is the shared secret.

An historical explanation of signatures is: "encryption with the private key, decryption with the public key". Forget that explanation. It is wrong. It may be true only for a specific algorithm (RSA), and, then again, only for a bastardized-down version of RSA which actually fails to have any decent security. So no, digital signatures are not asymmetric encryption "in reverse".

Symmetric Cryptography

Once two parties have a shared secret value, they can use symmetric cryptography to exchange further data in a confidential way. It is called symmetric because both parties have the same key, i.e. the same knowledge, i.e. the same power. No more private/public dichotomy. Two primitives are used:

Symmetric encryption: how to mangle data and unmangle it later on.
Message Authentication Codes: a "keyed checksum": only people knowing the secret key can compute the MAC on some data (it is like a signature algorithm in which the private and the public key are identical -- so the "public" key had better be not public !).

HMAC is a kind of MAC which is built over hash functions in a smart way, because there are many non-smart ways to do it, and which fail due to subtle details on what a hash function provides and does NOT provide.

Certificates

A certificate is a container for a public key. With the tools explained above, one can begin to envision that the server will have a public key, which the client will use to make a key exchange with the server. But how does the client make sure that he is using the right server's public key, and not that of a devious attacker, a villain who cunningly impersonates the server ? That's where certificates come into play. A certificate is signed by someone who is specialized in verifying physical identities; it is called a Certificate Authority. The CA meets the server "in real life" (e.g. in a bar), verifies the server identity, gets the server public key from the server himself, and signs the whole lot (server identity and public key). This results in a nifty bundle which is called a certificate. The certificate represents the guarantee by the CA that the name and public key match each other (hopefully, the CA is not too gullible, so the guarantee is reliable -- preferably, the CA does not sign certificates after its fifth pint).

The client, upon seeing the certificate, can verify the signature on the certificate relatively to the CA public key, and thus gain confidence in that the server public key really belongs to the intended server.

But, you would tell me, what have we gained ? We must still know a public key, namely the CA public key. How do we verify that one ? Well, we can use another CA. This just moves the issue around, but it can end up with the problem of knowing a priori a unique or a handful of public keys from über-CAs which are not signed by anybody else. Thoughtfully, Microsoft embedded about a hundred of such "root public keys" (also called "trust anchors") deep within Internet Explorer itself. This is where trust originates (precisely, you forfeited the basis of your trust to the Redmond firm -- now you understand how Bill Gates became the richest guy in the world ?).

SSL

Now let's put it all together, in the SSL protocol, which is now known as TLS ("SSL" was the protocol name when it was a property of Netscape Corporation).

The client wishes to talk to the server. It sends a message ("ClientHello") which contains a bunch of administrative data, such as the list of encryption algorithms that the client supports.

The server responds ("ServerHello") by telling which algorithms will be used; then the server sends his certificate ("Certificate"), possibly with a few CA certificates in case the client may need them (not root certificates, but intermediate, underling-CA certificates).

The client verifies the server certificate and extracts the server public key from it. The client generates a random value ("pre-master secret"), encrypts it with the server public key, and sends that to the server ("ClientKeyExchange").

The server decrypts the message, obtains the pre-master, and derive from it secret keys for symmetric encryption and MAC. The client performs the same computation.

Client sends a verification message ("Finished") which is encrypted and MACed with the derived keys. The server verifies that the Finished message is proper, and sends its own "Finished" message in response. At that point, both client and server have all the symmetric keys they need, and know that the "handshake" has succeeded. Application data (e.g. an HTTP request) is then exchanged, using the symmetric encryption and MAC.

There is no public key or certificate involved in the process beyond the handshake. Just symmetric encryption (e.g. 3DES, AES or RC4) and MAC (normally HMAC with SHA-1 or SHA-256).


Non-Sensitive/Non-Critical Database and Web server protections?

The non-critical database server doesn't necessarily need to be behind a second firewall, but it is recommended it reside in a separate DMZ, or a separate VLAN within the same DMZ (with ACL's in place) at a bare minimum.

If I'm understanding your explanation correctly, it sounds like the non-critical database server in the DMZ is connected via ODBC to the critical database servers on the LAN?

Which side is permitted to initiate communication through the firewall?

If the non-critical database server is allowed to initiate communication to the critical database servers on the LAN (to pull data), this is very bad.

If the critical database servers on the LAN are initiating communication to the non-critical database server (to push data) this is more preferred.

Without knowing the intimate details, I'm questioning why this non-critical database server needs to interface with critical database servers if it does not store any sensitive data?

Things to keep in mind:

If this non sensitive web application is vulnerable to SQL injection, the non-critical database will be compromised.

If the web server is compromised by vulnerability XYZ, it can be used as an attack point for the non-critical database server.


No, the best way is trying to try each hash function, encode as hex and find the result hash within that string.

From Wikipedia about additional properties for cryptographic hash functions: "Therefore, a cryptographic hash function should behave as much as possible like a random function while still being deterministic and efficiently computable."

That line also means that any good cryptographic hash function can easily be truncated to a smaller size without loosing additional security. The amount of security is still the number of output bits divided by two.

All of this is presuming that this is a cryptographic hash. If it is a normal hash, then it may be possible to find a match without brute forcing (but I would not bet on it). If it is a MAC instead of a hash then you would need access to the key.

I presume that you've already tried finding the documentation of course.


Personal or computer information stored in a freshly compiled executable

From an inspection of an executable compiled with Visual Studio 2010, it doesn't appear that the compiler, by default, includes any identifiable information about the user who ran the compilation or the host it was run on.

It may be possible to determine exactly which version of the compiler was used by looking at the executable. The GNU compiler puts the compiler's exact version-string in its output.

For "managed" executables, Visual Studio does allow various metadata like author and copyright to be specified; but it would require some sort of customization or build-script to put build-user or build-host information in the executable.

It's certainly possible to use a build-script and the source-code itself to make sure that such identifying information is in the program.  For example, if you compile the following program with gcc -Wall -D USER=$USER -o build/q203507.exe src/q203507.c, it will include the building user's user ID as a string in the executable:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#ifndef USER
#error please define USER in compile command
#endif

#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)

const char * sourceFilename = __FILE__ ;
const char * compilingUser  = TOSTRING(USER) ;

int main(int argc, char **argv)
{
  if (fopen(sourceFilename, "r")) {
    printf("%s\n", "You still have the source-code for this program.");
  }
  if (0 == strcmp(getenv("USER"), compilingUser)) {
    printf("%s\n", "You compiled this program.");
  }
  return 0;
}


To the best of my knowledge there's no actual way to block receiving a spoofed SMS message on any cell phone. I used to play around with it a long time ago and we never found a way to do it.

Intercepting text messages is considerably more difficult, if you're dealing with an attacker who's capable of this, then you'll probably need to hire a professional counter surveillance expert (or ask us experts specific questions if you're capable of doing it yourself). The obvious suggestion is to use encryption between contacts if its important but this is tricky to do.

In addition to implementing the router config settings you've suggested, make sure it doesn't have WPS PIN setup/mode enabled. Make sure you apply something like WPA2-PSK in terms of security on the network as well, the other methods you've mentioned only act as hindrance to an attacker and are relatively easily bypassed.


How to exploit the "PHP_MAGIC_QUOTES ON" vulnerability in order to cause max damage?

In PHP you cannot stack querys with a semicolon. However you can nest a query into another with parentheses (commonly called subqueries), e.g.:

SELECT * FROM vulnerable_table WHERE id = (SELECT number from other_table)

Using this technique (disregarding whether you output your SQL result or not) a keen attacker may extract all data from your database.

Example (with output on the web page)

SELECT * FROM vulnerable_table WHERE id = (SELECT group_concat(table_name) from information_schema.tables WHERE version = 10)

This query will result in a list (as a string) of all user-defined tables in your database.
Further queries will reveal the columns and let the adversary gain full knowledge of your table structure (for example: "tbl_accounts, tbl_passwords, tbl_guestbook").

If you don't give any output on your web page an attacker might still inject a conditional (think: case-when) statement with his SQL subquery, which will result in an SQL error in one case and no error in the other case. Deriving from "no output at all" and your normal webpage you can gather 1 Bit of information and perform a binary search through your database.

Generating strings in an SQL query like the one you suggested to upload a PHP-Backdoor (depending on whether the current MySQL user has the FILE privilege, which he shouldnt ;)) is also not that hard to come by: Using the ascii(), and ord() functions you can just create your strings with integer inputs. Also a value like 0x414141 will automatically converted to 'AAA' in MySQL.

Regarding very advanced attack and filter evasion techniques I also recommend you to read Reiners' blog on SQL security: http://websec.wordpress.com/

For completeness's sake: To fix this vulnerability, you can just perform a typecast and transform $_GET['id'] to an integer.


Standard practice for managing expired and revoked certificates used for signatures?

Neither of mentioned options are correct. Why? Because public part of the signing certificate is attached to each particular signature. If anyone (say, client) needs to validate the signature, client reads signature data and extracts signature value and signing certificate. Client uses public key to validate the signature.

The only requirement here is that signing certificate must be trusted, that is, its chain ends in one of the root certificates trusted by client. Some applications require explicit trust to signing certificate, so client compares whether the attached (to signature) certificate is explicitly trusted by client.

Also, SSL certificate is not suited for data signing (does not include Code Signing or Document Signing value in the EKU extension), because it is intended for server authentication. During TLS communication only handshake data is signed to prove the private key possession.

I believe, this blog post (mine) will be helpful: https://www.sysadmins.lv/blog-en/digital-signatures.aspx


You're trying a technical solution for a people problem. This won't work.

Storing passwords on internal wiki pages is not a good idea. You never know when they may accidentally be disclosed (e.g. screen sharing during a meeting with externals). However, automated tools are not that good at detecting what may be a password and what may be some other technical data (host names, etc.).

Any solution you come up with will either have a sizable chunk of false positives (meaning, it will recognize things as "potential passwords" that are in fact not passwords) or it will have just as many false negatives (meaning, it will classify something as "not a password" when it in fact is a password).

A much better solution would be to explain to people why storing passwords in the internal wiki is a bad idea and, most importantly, how they can do better. Should you still find passwords in a wiki after that, have an informal talk with that person. Don't be like "You did a bad thing and I am scolding you", but more like "I know you did this because you're trying to do your job, but if you do it that way, it not only is safer, but also makes your job easier".

As for how to actually store and distribute passwords, you can consider password managers. There are several products out there that offer password management for teams, so you may need to do some digging and some case studies on what works best for you. For example, you could buy a smaller license for just one or two of your teams of product A, and the same for product B and C - then two months later, you compare which teams made good experiences, and which teams made bad experiences.

Not only does this give your teams the feeling that they're involved in the decision making, but it also sneakily trains a part of your userbase on how to use a tool, which they can then help other users with.


Does creating a hash on a malicious file lead to opening a malicious file?

Unless the target of the malicious file is the hash program itself, it is safe, because the file is only use through it. And hashing program are normally simple enough to not suffer from such vulnerabilities. So IMHO it is safe if you use a command line hashing program.


Implementing mutual authentication between two components on the same server

Please keep in mind that without hardware security (TEE, Some crypto key ladder, etc...) a real strong security mechanism can't be implemented as long as potential attacker has physical access to the server.

Now, to implement the "good" security mechanism for your need, you have to list every possible attacks you must be resilient to:

Below is an example of a security mechanism that is supposed to protect against replay attack.

Initial setup:

AppA and AppB both have a pair of public/private key for asymetric crypto.
AppA and AppB both knows other app public key.

Security mechanism:

AppA generate a payload that is composed of:

A magic constant: let's say "PLOP".
A random token: nonceA.
A timestamp: timestampA.

AppA cipher this payload with AppB public key.
Using chosen communication mechanism, AppA push encrypted payload to AppB.
AppB unciphered payload and checks if:

magic constant is at very beginning of the clear payload.
timestamp is almost equal to now().

If previous checks were ok, than AppB knows that AppA is legitimate, it should now proves it is too, so...
AppB generate a payload composed of:

Same magic constant PLOP
Previous random token nonceA
A newly generated random token nonceB
A timestamp timestampB

AppB ciphers payload with AppA public key and push result to AppA.
AppA just do the same operations done by AppB:

Check magic constant is present.
Check if provided NonceA is the same.
Check timestamps consistency.

Then AppA must return to AppB a payload with NonceB, timestampB and ciphered with AppB public key.
At this point, both apps ensured that other one is legitimate.

This is one of possible mechanism to fullfil your requirements, there's probably some way to improve this scheme using cryptographic signing, etc...
Nevertheless, keep in mind that:

With a total control over the physical machine, there's no way to 100% fullfill your requirements with no secure chipset because:

Crypto keys can be extracted from binaries or memory.
Certificate Authority can be modified and then, SSL protections are not sure anymore...

To protect against replay attack, use timestamp and nonce.


Does a buffer overflow vulnerability always mean a code execution vulnerability?

No, a buffer overflow might:

Be against a buffer on the heap not the stack. This might still lead to code execution but will be much more complicated to exploit.
Be limited in size, so not able to overwrite return pointers. (e.g. be able to only write 1 byte beyond the buffer)
Be restricted in which bytes can be written, preventing suitable pointers to be written.
Overwrite stack cookies, which are detected before the return address is used. Unless the cookie is leaked, the exploit would crash the process the vast majority of the time, rather than leading to code execution.
Be on a stack growing upwards, so not be able to overwrite return addresses. An exploit might still be able to overwrite other local variables, or the buffer might be passed to another function, but wouldn't lead to code execution as reliably as downwards stacks.

Some of these might still lead to code execution, but other instances might be impossible to exploit.

However once you've found where a buffer overflow is happening it's usually much easier to fix it, than to prove it can't be exploited.


Your approach is fine for finding vulnerable systems, but it's likely not vulnerable.

The file you uploaded isn't guaranteed to be in any publicly accessible directory. It may be stored outside of the document root of the web server, then read via a PHP script that streams the content back to you.

In such a case, there's no way to make the web server run the script as a PHP script, because the PHP module won't execute anything outside of its base directory (document root).


Your best bet would be to look at specific vulnerabilities found in the WP Vuln DB

This site has exact application versions of when it was vulnerable, when it was patched and links to references.

You can get older releases of Wordpress off their site here

Also, if you don't have any experience with it, I recommend checking out WPScan which comes stock in Kali and Parrot OS

Anytime I see a wordpress site I run wpscan. It's magical. I also run it against my own blog usually once a month when I poke around my network.


Is sha256 a good function to derive 256 bit keys from a secret of sufficient length and entropy?

Assuming the input key is sufficiently entropic by itself, and both the input key and the identifier have a fixed length, you can safely use SHA-256 to derive extra keys. A fixed length is required to avoid length extension attacks which affect all non-truncated Merkle–Damgård hashes, including SHA-256. A safer way to do this, however, is to use HMAC for key derivation, which makes this scheme more flexible so length extension attacks are not a worry. When using HMAC, the input key is used as the HMAC key, and the identifier is the message to be hashed. You can also use a standard KDF such as HKDF.


Reading php comments using php page that open text files, CTF

If you encounter a local file inclusion (LFI) vulnerability there is a special technique that enables you to read files from the target system by making use of a PHP wrapper. This will not work in every case but you might want to give it a try.

You can read more about the PHP wrapper on the official php.net site:
http://php.net/manual/en/wrappers.php.php

This technique basically lets you use PHPs input and output streams as well as apply different filters to them.  (http://php.net/manual/en/filters.php)

To read a resource you can use a payload in the form of:

php://filter/resource=/some/dir/secretfile.php

php://filter/resource=anothersecretfile.php

To apply a filter replace filtername with the name of the filter:

php://filter/filtername/resource=anothersecretfile.php

In some cases there will be errors depending on the specific implementation and surroundings of the LFI.
A good way do handle these can be to convert the output in a way that will not be interpreted by the target server.

On filter you might want to look at is the

convert.base64-encode

filter that converts the stream data to base64.


How to uniquely identify users with the same external IP address?
  Is there any way to uniquely identify such users?

Yes, there are lots of ways:

Cookies
Evercookies (JavaScript code that uses lots of different techniques to store identifying information, among them flash cookies, the various HTML5 storage options, the browsers visited links history, etc)
Device fingerprinting: use the HTTP header (mainly User Agent, but the other headers and their order can help as well)
Device fingerprinting with JavaScript: with JavaScript, you can get a lot of information, such as screen resolution, timezone, plugins, system fonts, etc.
Behavior: how fast do the users fill in forms, where on a button do they click, etc.

But most of these are not useful in defending against brute-force attacks, since the program doing them will probably not accept cookies or run JavaScript.

In your case, you might try:

HTTP header: these might actually already be enough to differentiate between users using the same IP address (of course, an attacker can just randomly switch them, but I would assume most currently don't).
Light throttling: you don't have to block IP addresses, you could just slow down the login process for them. That way, brute forcing becomes a lot less feasible, but real users using the same IP address can still login.
CAPTCHAs: these will annoy legitimate users, but hopefully not too many users actually use an IP address from which brute-force attacks originate (of course, there are tools to automatically solve CAPTCHAs, but it's still harder than no CAPTCHA).
You could require a user to accept cookies, and to send various identifying information before being allowed to login (such as the screen resolution, timezone, etc.). Of course, an attacker can do this as well, but I don't think any currently existing bruteforce tools can do this, so they would have to write a custom script. But this might also annoy legitimate users.


Is it possible to assign MAC-address-specific passphrases for a WiFi network?

The ability to revoke client access on a device-by-device basis is a feature of Enterprise WPA, which uses a RADIUS server for authentication purposes. Authentication is achieved using variants of the EAP protocol.

In this set up you issue certificates for each client, which can be revoked by your CA in the event the client's private key is compromised.


What's the deal with X25519 Support in Chrome/Firefox?

... Section 9.1 says that "implementations SHOULD support X25519"

While you seem to quote from the RFC the phrase in question is actually significantly different from what you quote:

9.1.  Mandatory-to-Implement Cipher Suites
... SHOULD support key exchange with X25519 [RFC7748].

But what you tried is using a certificate with an Ed25519 based public key for authentication which is completely different from using X25519 for key exchange. X25519 key exchange seems to be actually implemented in the browsers, but Ed25519 certificates not.

... neither browser offers Ed25519 as a signature in their ClientHello

There are no Ed25519 signatures involved in X25519. X25519 is a key exchange - which is supported by browsers. Ed25519 is instead a signature algorithm - which is not supported. X25519 and Ed25519 are thus different things which both use Curve25519.


How do I pass a list of cookies to Wfuzz?

I'm not 100% sure what you mean by "list" in this case, but I'm assuming you mean you want to pass them as a single argument instead of having to specify multiple -b arguments.

Of course, cookies are just sent in an HTTP header, and -b is provided for convenience as to not require you to craft the header manually.

However, check out the wfuzz man page:

  -H headers

Use headers (ex:"Host:www.mysite.com,Cookie:id=1312321&user=FUZZ"). Repeat option for various headers.

So, you should be able to pass a cookie header with a list of cookies.


User Authentication for a public website in 2015

Authentication by forms is still the norm. However, you may want to consider allowing your users to take advantage of a single sign solution.

For instance:

OpenId
Try rolling your own SAML (a single sign on protocol) based solution.

Keep in mind that this just let's your user share their sign in with another service. At some point they will have to sign in with a form somehow.

Or in some cases, it may be appropriate to auth cryptographically via private keys and the like. For instance, Github offers an option to authenticate via a private key. If this appropriate for your set up, you will most likely already know.

I also urge you to consider the option of allowing two factor authentication. Again, this does not obviate the need for a form authentication, but will make your form log-in's much safer.


URL Shortening - How to verify if it is a non-malicious URL?

The simple answer is that you can't be 100% sure.

Here are 5 browser extensions that automatically expand short URLs for you to check visually if the destination website is familiar. But even familiar sites can contain malware or other attacks like Cross Site Scripting.

Google Chrome and Mozilla Firefox automatically perform checks against the Google Safe Browsing service but this service is not and cannot be up-to-date on all the threats all the time.

Most mainstream antivirus products have some active protection mechanism for web based threats but they are limited. For example, AV doesn't protect against Clickjacking.

Virus Total will scan your URL with many commercial products and services.


I think your issue is about the concept behind malware. A malware is a software that does more than you expect it to do. Or a software that does what you don't want it to do.

If I make a piece of software that deletes everything on my computer, it's not a malware, it's legit, I want that to happen.

If I give it to a friend and tell him : Hey check out this funny little game, he'll come to me (punch me in the face) and ask : why did you send me a malware ?!

So it all depends on the context. You made a piece of software that does legit stuff. What you are trying to achieve will make it or not a malware.

As for your Edit :
I'm not an expert about AV but from what i know, they look for patterns. Writing you own malware/virus with only legit code would make it almost indetectable, because you are not using any pattern the AV knows. The point here is you don't use any breach, there is no security exploits. You are not excessing your rights, nor exiting any application scope. You've just created a tool to connect to another computer and to execute command.

i would take the exemple of the recent Meltdown and Spectre exploit. They are very dangerous not because at this time, no AV knows how to detect it, but because Av would likely never know how to detect it, because it is 100% legit code. Because it is 100% legit, there is infinit ways to write an exploit. And so, no patterns would come up.