OpenSSL generate different types of self signed certificate Does anyone know how to use OpenSSL to generate certificates for the following public key types:

DSA - For DHE_DSS key exchange.
Diffie-Hellman - For DH_DSS and DH_RSA key exchange.
ECDH - For ECDH_ECDSA and ECDH_RSA key exchange.
ECDSA - For ECDHE_ECDSA key exchange.

Most that I can find online teaches you how to generate a RSA type certificate though.

(EC)DSA
For a DSA key pair, use this:
openssl dsaparam -out dsakey.pem -genkey 1024

where "1024" is the size in bits. The first DSA standard mandated that the size had to be a multiple of 64, in the 512..1024 range. Then another version deprecated sizes below 1024, so a valid DSA key size had length 1024 bits and nothing else. Current version specifies that a valid DSA key has length 1024, 2048 or 3072 bits. OpenSSL accepts other lengths. If you want to maximize interoperability, use 1024 bits.
For an ECDSA key pair, use this:
openssl ecparam -genkey -out eckey.pem -name prime256v1

To see what curve names are supported by OpenSSL, use: openssl ecparam -list_curves
(For optimal interoperability, stick to NIST curve P-256, that OpenSSL knows under the name "prime256v1".)
Once you have a DSA or ECDSA key pair, you can generate a self-signed certificate containing the public key, and signed with the private key:
openssl req -x509 -new -key dsakey.pem -out cert.pem

(Replace "dsakey.pem" with "eckey.pem" to use the EC key generated above.)

(EC)DH
For Diffie-Hellman (with or without elliptic curves), things are more complex, because DH is not a signature algorithm:

You will not be able to produce a self-signed certificate with a DH key.
You cannot either make a PKCS#10 request for a certificate with a DH key, because a PKCS#10 request is supposed to be self-signed (this self-signature is used as a proof of possession).

While OpenSSL, the library, has the support needed for issuing a certificate which contains a DH public key; this page may contain pointers. The challenge is to convince OpenSSL, the command-line tool, to do it. In the jungle of the OpenSSL documentation, I have not found a complete way to do it. Key pairs are easy enough to generate, though.
To generate a DH key pair, with the OpenSSL command-line tool, you have to do it in two steps:
openssl dhparam -out dhparam.pem 1024
openssl genpkey -paramfile dhparam.pem -out dhkey.pem

For an ECDH key pair, use this:
openssl ecparam -out ecparam.pem -name prime256v1
openssl genpkey -paramfile ecparam.pem -out ecdhkey.pem

However, it so happens that the format for certificates containing ECDH public keys is completely identical to the format for certificates containing ECDSA public keys; indeed, the format contains "an EC public key" without indication of the intended algorithm (ECDH or ECDSA). Therefore, any private key and certificates for ECDSA (private key for generating ECDSA signatures, certificate self-signed or signed by any other CA) will be fit for ECDH-* cipher suites.
The one case that I don't know how to produce with the OpenSSL command-line tool is a static Diffie-Hellman (non-EC) certificate. Note, though, that OpenSSL does not support SSL/TLS with static DH cipher suites either, so even if you could produce the certificate, it would not work with OpenSSL.
(And, in fact, nobody uses static DH in practice.)


How does obtaining a SSL certificate work? I have been carrying out some work on SSL certificates and found that there are some places that charge you for an SSL certificate, but, how do they obtain the rights to do so? And, how, are they allowed to be on a list of "trusted" sites that the browser can identify as genuine?

The big browser companies (Google, Mozilla, Microsoft, Apple and Opera, mainly) include whatever root certificates from certification authorities they want to -- there are no government regulations or laws governing it. However there is a voluntary body called the CA/Browser Forum that lays down standards, and since all of the browser companies listed above are members then in practice a certification authority has to meet those standards to get their certificate included.


Rootkits on Mac OS X Is there known existence of rootkits for Mac OS X, and can you please provide examples?
What software would you recommend to detect rootkits on OS/X?
From a software developer's perspective, can you provide pointers on how to manually detect rootkits on OS/X? E.g., Is there any particular place in the kernel that I can look for? Are there any known functions or libraries within Cocoa that I can use for the purpose of scanning or validating the kernel? How would you go about writing a shell script, or native C/Obj-C code to scan for rootkits?

There was WeaponX in 2004, there is even a guide here on how to develop one yourself. Since OSX is a combination of Mach and BSD, there have been rootkits specially developed to target the Mach or Unix side or both.

I use Rkhunter on my Unix machines, there is a version for OSX as well, so I suggest you take a look at that.

The problem with a rootkit is there are many places it can go hide itself, plus they are often made to be very hard to detect.  They can provide false process information.

I've never written one myself, but rkhunter is open-source so I suggest you start there.

Also if I'm not mistaking(but not sure), it makes MD5 hashes of your binaries and kernel modules and then checks this every so often. It notifies you what has changed. Might be that you did an update. If not then you might want to go look why that binary got changed.


SSL certificate signature creation I have some queries regarding SSL certifcate chain. I have tried searching documents online, but none has mentioned clearly.
When a chain of trust is established, below would be how it works.
Domain certificate when issued by an intermediate CA, it will put in a signature value in the certificate that is created by hash of the data and further encrypted by Private key of the issuer which can be decrypted by Public Key.
The same goes with Intermediate CA. the Root CA will create a has of data, sign it with it private key and put in that signature in intermediate so it can trust it.
I want to understand what data is used to create a Hash which is then encrypted by the Private Key of the issuer. Is it certificate contents like CN, Serial no etc?
The reason I am asking this is if there is a Man in the middle, he can check that certificate and decrypt the signature using the public key and check the hash value.
How does the machine confirm that this is the correct hash it has received in the signature after decrypting it?
I mean with what value it will compare at its side? For example in the case of IPSEC, the hash of hostname or PSK is sent to the peer and the other side has also the PSK and it will create the hash and match the hash value.
In the case of signature, how does the source machine compares that the hash is correct, does it have some command value?
Please correct me if I am going in the wrong direction.
Thank you!

...  which is then encrypted by the Private Key of the issuer. ... the signature after decrypting it?

It is signed with the issuers private key, not encrypted. Note that with RSA this might look the same, but with ECDSA it works differently.

I want to understand what data is used to create a Hash which is then encrypted by the Private Key of the issuer. Is it certificate contents like CN, Serial no etc?

Everything from the certificate (tbsCertificate) is covered by the signature and thus included in hash, excluding only the signature itself. To cite from RFC 5280
4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.

...

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

I mean with what value it will compare at its side?

Anybody having the certificate  can simply extract tbsCertificate and recompute the hash for verification.


Is a firewall enough of a security measure for an Ubuntu server that hosts a website? I recently got a VPS with Ubuntu on it, and I'd like to start creating a very basic website. However, I don't know what steps I should take to secure this server.

I'm new with Ubuntu, new with security and new with creating websites (the website will probably be just HTML, CSS, Django/Python and some database).

My biggest concern is that some hacker could try to use it as a zombie and I won't know. Or that robots could try to log in and sneak at whatever data I'll store on that machine and I won't know. Or who knows what else.

I found the firewall information page on the Ubuntu website, but will that be enough ?

P.S.: If it's impossible to give an answer, I'd also appreciate a book/website recommendation for Ubuntu and security complete beginners

Is a firewall enough of a security measure for an Ubuntu server that hosts a website?

Given the technologies you want to use you want to create a dynamic database-backed website without having any experience with this. This kind of setup is typical for easy too exploit sites: database-backed often allows SQL injection, insecure uploads might allow code execution etc. The normal packet filter firewall on Linux will not protect against any of these application-level attacks, i.e. a firewall is not enough of a security measure.

With the level of experience you currently have I strongly recommend to not create some dynamic application which is accessible (and potentially exploitable) by anybody. If this is just for your own or some selected users you might try to password protect the site using the established mechanism the web server has (i.e. htpasswd or similar) to at least limit the attack surface by limiting who can access your website.

  I'd also appreciate a book/website recommendation for Ubuntu and security complete beginners

To learn more about web security you might start with the Top 10 Web Application Security Risks. In general, this is unfortunately a fairly complex topic so don't expect to be quickly sufficiently familiar with it.


Virus from a printer kiosk? I encountered a puzzling situation the other day when I plugged in a USB flash drive. Windows defender displayed an alert saying that a threat had been quarantined, specifically the Jenxcus VBS virus. This is especially alarming given the preceding events. This flash drive is one I have had for a while but was empty. I then put some PDFs onto it, and succeeded in running down to my local Staples and printing at one of their printing kiosks, which you use by plugging in a USB drive. As far as I can remember, since then and until now, the drive has not been plugged into another machine. Now, all of a sudden, it has been infected by a virus. So, my question is, could the flash drive possibly have been infected by being plugged into the Staples printer?

My reasoning so far is that the drive couldn't have been infected before going to print, because this virus seems to overwrite every file on the infected drive with a shortcut pointing to the VBS malware. I was able to print my files just fine, which I wouldn't have been able to do if that were the case, presumably. Also, the only compromised files the Defender report listed were those on the flash drive themselves. I have since run a virus scan (Malwarebytes) which detected nothing. I also checked the registry values which the Microsoft page claims are changed by this virus, and they don't seem to have been manipulated at all. I have since disposed of the drive. So again, should I be worried at all that I have a virus somewhere? Or is possible that the virus came from the printer? I've always thought that was pretty impossible, but I'm puzzled.

Yes.

The printer kiosk has an Operating System that could itself be infected and infecting other devices that are connected to it. On the one hand, such system will be used by a large number of users, so the chance that a previously infected usb drive was connected there is quite high. One would assume that the design of such system should have taken into account that possibility and that the system had been hardened to avoid possible infections... but at the same time, security is not a tangible property that adds value to the kiosk (even though tangent insecurity degrades it!), and was thus likely neglected, or not properly addressed.


What can a hacker do with an IP address? I have an internet connection with a static IP address. Almost all staff in my office know this IP address.  Should I take any extra care to protect myself from hackers?

It depends. Think of your IP address as the same kinda thing as a real address. If a criminal knows the address of a bank, what can they do? It completely depends on what security is in place.

If you've got a firewall running (e.g. Windows Firewall) or are behind a NAT router, you're probably safe. Both of these will prevent arbitrary incoming traffic from hitting your computer. This stops most remote exploits.

My suggestions:

Enable Windows firewall, or whatever firewall is available on your OS of choice.
Keep up to date with patches for your OS. These are critical!
Keep up to date with patches for your browser and any plugins (e.g. Flash)
Keep up to date with patches for your applications (e.g. Office, Adobe PDF, etc.)
If you're running any internet-facing services (e.g. httpd) on your machine, keep those up to date and configure their security appropriately.
Install a basic AV package if you're really worried. Microsoft Security Essentials (MSE) is a great choice for Windows, because it's free, unintrusive and not much of a performance hog.


Limiting a standard user on Windows I'm setting up a limited user account.  I would like it as limited as possible, while retaining the capabilities of: running a handful of programs, and saving files into one folder.

Can I use ACL rules to deny access to all hard drives, and then make an ACL rule on just the needed programs and folders?  Is there a better approach?

I have Windows 10 Pro installed on an SSD, and I have an HDD for files.

Side note: How could the limited standard user have the capabilities of updating Windows Defender and Malwarebytes?

Edit: The goal of this is Windows 10 hardening.

Thank you very much.

First of all, be aware that what you're attempting is extremely difficult to get right. For example, a lot of tools in Windows are in the System32 (and SysWOW64, where applicable) directory, so you might be tempted to deny Execute permission on that directory (except on perhaps a few critical EXEs), but that will prevent loading DLLs that are required for nearly every single Windows program. Some shared / widely-needed stuff is in Program Files as well, so the same risk applies there.

Also note that Windows doesn't make it easy to do stuff like this. By default, any user can bypass directory traversal restrictions (as on *nix, the Execute bit on a directory ACL controls the ability to access the directory's contents, but unlike *nix, this restriction is ignored by default). Also, while Windows ACLs are inherited by default, some items do not use inherited permissions. For example, the C:\ProgramData directory does not inherit permissions from C:\, and by default allows any member of Users (which by default includes Authenticated Users) to create subdirectories and have full control over those subdirectories. This makes it very difficult to create a user account that can only write to one location.

With that said, yes, this is possible. Windows ACLs are validated against a process token in the following order: User Deny, User Allow, Group Deny, Group Allow. Thus, if a user is a member of both an allowed group (such as Authenticated Users, i.e. anybody who logged in using credentials) and a blocked group (such as the built-in Guests, or a custom group you create and perhaps add to Guests), then the user will be blocked. However, if you also explicitly grant the user access in that ACL, that overrides the group protections. This means you can block a group from doing something globally, then grant its members access to specific resources.

An alternative approach to ACLs would be to use AppLocker ("Application Control Policies"), which lets you do things like disable all programs except for a whitelist specified by publisher signature, file hash, or so on. A full explanation of using AppLocker is outside the scope of this answer, but you can find information online, or start playing with it yourself by using Locals Security Policy editor (secpol.msc). Note that messing up badly enough can make the machine unusable. Note that AppLocker is generally only usable on Enterprise-or-better editions.

There's no equivalent (to AppLocker) way to restrict file access, but you can do this using Windows' Mandatory Integrity Control. If you restrict a user to only running a certain set of applications (or only running applications from a certain directory), you can specify that the EXEs (or directory) have a Low integrity level. Any process launched from those EXEs will thus also only be Low integrity, which will prevent it from writing to any file or directory with an integrity higher than Low (by default, everything is Medium integrity). You'll need to be careful this doesn't cause problems - for example, programs that generate log files will need to be able to write to their log directory - but it can be done.


How to explain Heartbleed without technical terms? Most of my friends who are not experienced in computers want to know what Heartbleed is and how it works. How would one explain Heartbleed to someone without a technical background?

How about this one from XKCD?

The most "non-technical" explanation I found.


What is the best way of finding subdomains of a domain? I need to find most subdomains of a domain. I know there are many options.

I've tried many available in Kali Linux:

dnsmap
dnsenum
dnsrecon
dnswalk
fierce
urlcrazy

Most of them only find 2 or 3 working subdomains, while using this online tool, it finds many more.

Since pentest-tools require to buy credits in order to work, I'm trying to find a tool that would retrieve similar results like it. I haven't been successful so far.

How can I get the best results from those tools?

The tool you linked explained their techniques:

 DNS zone transfer
 DNS enumeration based on a specially chosen wordlist
 Public search engine queries
 Word mutation techniques

The Kali tools you mentioned can do some of those things, but perhaps not all. You might need to combine them or configure them differently.

Without knowing the specifics of what one tool found that another did not, it will be difficult to devise a more technical answer.


Is there a way of achieving perfect forward security with one directional messages? Using for example ECDH and ephemeral keys, it is possible for two parties to establish a shared key with perfect forward security, i.e. even if the long term keys are lost, it will not be possible to recreate the key generated by the process.

Is there a way of achieving the same result but with one directional messages, for example when sending an email, when only a long term key of the recipient is known?

Not with only a long-term key pair to start with

If all the recipient needs to know to read the message is his long-term private key and the ciphertext, then that is also all any attacker will need to read the message in the future.  In order for the message to remain secure in the case his long-term private key is compromised, there will need to be some additional information known only to the recipient involved in the encryption (such as the short-term private key normally used in perfect forward secrecy).

However, there might still be a way to achieve perfect forward secrecy without requiring two-way communication at the time the message is sent.  One could imagine someone publishing a calendar of public keys for which he holds the private key, rather than a single public key - and then deleting all copies of each private key as its date passes.  This would effectively make all of the private keys into short-term keys, which would no longer be open to compromise once their date had passed.


Is it possible for corporation to intercept and decrypt SSL/TLS traffic? I found there are some companies claim that they offer service that can eliminate SSL/TLS blind spot, such as Blue Coat and Gigamon. Are they talking about some way of decipher the https content (breaking the encrypting algorithms) or just man-in-the-middle attack ? If it is a MITM proxy, can I simply detect it by checking the CA of the certificate installed on my browser?

My question is about whether there is way to monitor https traffic without MITM attack and whether it is possible for MITM proxy to dupe users by showing certificates with real CAs (DigiCert, Comodo) so I cannot just tell the difference by looking at the CA.

Installing a root certificate on users browsers, and conducting a MiTM attack on employees is unfortunately a standard practice at many companies.

There's a few ways you can detect this.

One way is looking for a root CA cert installed on your computer and see if you don't recognize one of the CAs.  This of course requires an in-depth knowledge of what real root CAs are, and what fake MitM proxy providers are.
Another is simply looking at the certificate an https websites
generates and examine who it's signed by.  The cert of all https sites will
be signed by the company providing the MiTM attack proxy.
A third way is to install Firefox, preferably a version that doesn't
install and runs as a standalone.  Firefox doesn't use the system
provided certs, but uses its own certs.  You can get this from
http://portableapps.com/  If you then get a security warning about a
self signed certificate, you're being MiTMed by your company.


Is it html escape enough for mitigating all xss, if html is going to be generated only in client side? If all html in a site is generated in client side (attributes, urls, styles everything will be concatenated in javascript and set as innerHTML), is it doing only html escape enough for mitigating all xss attacks mentioned here?https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Not necessarily, and it wouldn't be recommended. Admittedly it is likely to prevent DOM-based XSS in the majority of cases (in an HTML output context anyway), but not all as detailed on OWASP...

Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HTML encoding may not work to mitigate against XSS.
--- SNIP ---
If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element.

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#Encoding_Misconceptions
This page also includes examples.
Furthermore, HTML encoding only applies when the output context is HTML.
Generally, I would still say that the best practice of validating and sanitising all user controllable input on a case-by-case basis is still the best solution. Generally, data would need to be both JavaScript and HTML encoded in this case. See the recommendation on the same OWASP page above.


Can nmap (or another tool) detect hardware/system information such as amount of RAM, number of processors, etc.? I am able to use nmap to determine open ports, basic OS information, etc. but is there anything that allows me to find out further detail of the machine's configuration?

This is called TCP/IP fingerprinting and can also be accomplished with tools such as p0f. With this technique, you can detect things like approximate uptime, topographical distance, or even estimate the level of traffic the site is serving by analyzing IP sequence IDs, but you cannot detect the amount of RAM or number of processes as those do not affect the networking stack in any observable way.
See the nmap documentation and usage information for more information on OS fingerprinting.


Has there ever been a country that implemented whitelist-based internet censorship? We hear time and time again of countries censoring internet traffic by blocking IP Ranges.

Without getting into the politics of it, let's take for example China's Great Firewall. Even though it is not the most oppressive of firewalls, it still seems to be a constant cat-and-mouse game of VPN server's IP addresses getting blocked and VPN hosting companies moving to different IPs. When technologies altogether such as OpenVPN get blocked, modifications are made to the protocol to allow the traffic to pass undetected.

With so much effort going into maintaining these firewalls, it might almost be worthwhile to create a list of every legitimate service IP that is used. Has a government ever experimented with whitelist-based censorship?

North Korea comes to mind. Most North Korean users only have access to Kwangmyong national network controlled by the government. This can be viewed as an extreme case of a whitelist-based approach to censorship.


How to explain the upcoming Root Certificate Expiration period without technical terms? A lot of users on older devices or IoT devices that don't or can't get updates will encounter problems in the coming year or two because a lot of the original long-lasting CA root certificates will expire.

Because this is a very technical problem that most people will be totally unaware of and probably won't understand if someone will explain it to them using technical terms, there is a need for an explanation (or maybe multiple) that can be understood by non-technical users so that if they're one of those users on an older device, at the very least they know what's going on.

.... there is a need for an explanation (or maybe multiple) that can be understood by non-technical users so that if they're one of those users on an older device, at the very least they know what's going on.

The technical reason is irrelevant for these users. All they want to know is the effect (for example device no longer works, exact behavior depends on the exact device) and who to blame for.

The blamable problem here is not the Root Certificate Expiration since this was a foreseeable problem which could have been addressed by the vendor: if the device is able to get to the internet it should be able to get updates with the new root CA too. Instead the vendor of the device is to blame in that he either did not foresee the problem and introduced the necessary steps to deal with it or that he explicitly decided to ignore the problem.

The sufficient explanation is therefore: the device does not (fully) work any more because the vendor made a mistake and is unable or unwilling to fix the mistake.


REST specific security weaknesses I need to start working with RESTfull Web Services. SOAP based web services have already so many standards to secure communication, establish trust etc. I am not aware of any for REST.

What I would apreciate is answers to the following questions:

My mobile app would be using X 509 certificates when sending REST requests. Is there a protocol, a best practice ... to secure them at the message level, like what WS Security allows?
Should I use a specific HTTP Verb when sending the request? or all of them have no security implications?
If you have links on REST security topics, please share them as well :)

Having worked with RESTful Web Services doing code-review and code-assisted app penentration-tests on RESTful apps that were over 3 MLOC, I can tell you that the problems outlined by John Wilander in REST and Stateless Session IDs is the dominant, growing problem. If you do not have this problem (which is a very big problem) in your RESTful Web Services, I would be shocked. It basically makes REST a security nightmare. If you follow John's advice and implement sessions with SSL/TLS, you have solved your first and primary problem. I picture this as a very large application development project.

Additionally, many components of such an architecture may be at risk. Chris Gates has done a lot of research on the public facing OAS, such as his recent column on Oracle Web Hacking, which includes a link to running code for Metasploit modules on his git repo. Sensepost released a tool (go-derper) and work against memcached at the last BlackHat-US/Defcon.

Finally, RESTful services most certainly have issues with SQL injection, DRO, CSRF, and XSS just like normal -- and the occurrence of stored versions of those injections would dominate direct/reflected attacks.

The problem with REST vs. SOAP is that SOAP usually produces a WSDL. REST could have a WSDL (with WSDL 2.0) or a similarly described WADL. However, this is unlikely, and without a list of entry points, it is difficult to test RESTful services. One would need either the source code, the documentation, or an existing test harness. SOAPSonar is a commercial option, while WS-Attacker remains one of the best current open-source options for testing.

I could see how some Firefox / Chrome plugins and/or web proxies (e.g. Fiddler, Burp, Web2Proxy) could also be useful, but this would require some significant investment in time to manually build test fixtures. If an existing test harness (e.g. soapUI, HttpUnit) is available to the tester(s), then these tools can be run through a web proxy, preferably one that supports XML/JSON like Web2Proxy, Web2Fuzz, AppCodeScan, and wsScanner (which are discussed in Shreeraj Shah's book, Web 2.0 Security - Defending Ajax, RIA, and SOA).

XML itself can be tested using tools such as Untidy, by the same author as W3AF, which has its own proxy called spiderMan (probably great for testing REST if implemented correctly). I'm not sure if Acunetix WVS (the most recent release, which was last week) supports proxying in the way that Netsparker Pro does (or Burp Pro Scanner), but if it does then Acunetix may be the best tool to test for the stored injections, as I hear it has great support for these types of checks. If anyone has a license for the full version of Acunetix WVS, please let us know. The AcuSensor technology would also be very useful here, as would HP Fortify PTA -- especially since the entry points are unknown.

In other words, testing RESTful services with black-box methods and technologies is bound to fail. The problem with identification of entry points, even with source code, is that many RESTful services are often configured and developed with code indirection technologies, such as several well-known Web 2.0 and Web Services patterns -- as well as Dependency Injection, IoC, AoP, et al. Worse, there are often several levels of this indirection, with no Views folder or other simplification. This makes it additionally difficult to utilize automated security-focused static analysis tools (e.g. LAPSE+, CAT.NET, Yasca, Graudit, FindBugs, CodePro AnalytiX, FxCop, Fortify SCA, Checkmarx CxSuite, Appscan Source Edition, Armorize CodeSecure, Coverity, Klocwork, GrammaTech, and many others). Cigital has a solution called ESP which is considered best-practice for large-installation, SOA-based Enterprise app portfolios (note that ESP is usually backed by several app pen-testers year round who know how to manually review source code as well as identify complicated runtime analytics of application layer vulnerabilities -- so it's not meant to be used solely as a factory).

In summary, it will almost certainly need to be manually reviewed with all major and minor build components available to the reviewers.


OpenSSL - Internally using the wrong certificates, externally is fine I am seeing an odd issue with two of our externally facing systems where access over the web on HTTPS works, and uses the correct COMODO certificates, but internally it is using self-signed certificates.

The command being used to test this is:

openssl s_client -showcerts -connect wiki.domain.com:443

Externally, this returns:

Server certificate
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.domain.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

Internally (from the local subnet) I see:

Server certificate
subject=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
issuer=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address

Any idea why this would be happening please? I can't figure out what's going on here.

Please ask if you need further details, am happy to provide. Thank you.

Most likely you have a proxy that uses a self signed certificate in order to inspect SSL traffic, some Secure Web Gateway solutions such as McAfee, Cisco, or Websense use a self signed certificate that users install in their computers in order to inspect encrypted traffic for malware prevention, so what you are seeing is the self signed certificate used for the proxy, you should contact the network engineers in your company in order to be sure.


Access-Control-Allow-Origin header spoofing? Is it possible for a attacker to spoof the Access-Control-Allow-Origin header?

Or, is it secure enough to protect resource access via the Access-Control-Allow-Origin header?

I'm trying to make an API key useless on certain domains, like the linked in JS API.

If an attacker can control the access-control-allow-origin header then they can carry out much worse attacks than just modify this header element.  For example an attacker could carry out a Man in the Middle attack,  but authentication tokens,  like cookies are a more desirable target.

An attacker could introduce their own access-control-allow-orign header using HTTP Response Splitting, but at this point they can control the entire header and the body. An "allow-orign" doesn't help with the entire Same-Origin Policy is undermined by an XSS vulnerability.


RSA: same symbols in plaintext give same symbols ciphertext? I just started studying Information Security, but I just ran this program:

http://www.sanfoundry.com/cpp-program-implement-rsa-algorithm/

and faced this strange thing. For small keys (don't try to run it for huge primes, it doesn't give good output), like 211 and 223, inputting a string like 1122 gives output of type aabb, because first two symbols are the same and last two symbols as well. Is it how RSA works? I was pretty sure it mixes the bits up.

Single, unpadded input chars
That implementation you linked operates on individual characters. So patterns are repeated.

Also these characters are not padded in any way. Padding would prevent such easily spotted patterns.

Not the real thing
So this is somewhat RSA like. But it is not actual RSA. (Because PKCS#1 mandates padding.) Wikipedia calls this "Plain RSA". Another name heard here is "Textbook RSA".

Further reading

See section "Trading secrets" here: The First Few Milliseconds of an HTTPS Connection
See section "Padding" here: Wikipedia: RSA


Can ransomware encrypt files in a drive locked by BitLocker? I have a general understanding of how ransomware works. I want to know if ransomware will target a locked Bitlocker drive, however. I very rarely unlock that drive, and it will only be unlocked for backup. So, will ransomware encrypt this drive?

If the ransomware has full access of your operating system, nothing can stop it from encrypting your data, including BitLocker-encrypted volumes. The ransomware can simply encrypt the already-encrypted data once again, with its own key this time.
In principle, BitLocker cannot protect you from ransomware - on the contrary, it could be abused by ransomware to lock your data from yourself. It's just the matter of the way how the criminals would implement their ransomware kits. If BitLocker appeared to block some ransomware, it's just because these ransomware don't take into consideration the layer on which BitLocker works. In reality, such type of ransomware exist, for example: Petya (although it doesn't seem to be able to operate on BitLocker-enabled volumes, AFAICT).
In other words, what BitLocker did to "protect your data from being locked by ransomware" is roughly equivalent to operations like "diskpart offline volume".
Some ransomware may not simply maliciously encrypt the victim's data, they may steal (copy) those data before encrypting. After that, the criminal would be able to estimate the "value" of those stolen data. Therefore, BitLocker seems to be beneficial in such situations, in the sense that it would be a little harder for the criminal to steal the (plaintext) data.


How can an Subject only read and write to its owned objects? It appears that in RBAC, a Subject creates a Session with an Active Role(s), these Roles are then used to determine what permissions and actions can be taken. This appears to be fine for most of our organization until you reach Subjects with the Customer Role. Customers should only be able to read things they own, as opposed to other roles which would have read/write (or whatever actions) on things of the same type.

I'm not sure how best to implement this using RBAC. Should the session also contain the Subject? A few references suggest no.

Note: it is possible I am being too purist, but I'm checking to see what I'm missing. I have considered the PostgreSQL route where a User is a Role, and then the active role in the session is the User. What are my options for restricting a role to only view things not by type but by ownership?

I think this can be implemented using Capabilities. Every subject has a set of pairs (o,r) where o is the object and r are the rights. For example if Customer1 can read file1, and read-write on file2, you can have a Capability list like that:

Customer1={(file1,{read}),(file2,{read,write})}

If many Customers have the same rights you may use groups to limit the storage that is used to save this information.

But then you have to be sure that the subjects can not modify the Capability list.


What is the difference when scanning external IP's from my LAN vs cloud/external scanner? Im concerned if I am scanning effectively.

When I scan our external IP's with the scanner on my laptop the packets are leaving my network through my firewall and routing across the internet to hit my public IP's.  If this can be done why would I need to pay extra for a "cloud\external scanner" if I can just do it from my laptop.  Am I not seeing the external IP's the same as if I were an outsider?

It depends most on how your network is configured, or if the target employs geoblocking or not.

If your firewall allows the sending of arbitrary packets, even malformed ones, and the target does not care if you are in Ireland or Argentina, a cloud-based scanner works the same as using your own IP.

On the other hand, if your firewall "sanitizes" packets, discarding malformed ones, or your target drops packets depending on your location, it can be worth pay for a cloud scanner. How a target handles malformed packets are a good indicator of OS used, application running and so on. If your firewall "fixes" the packets, that can mask your results.

Another consideration is technical support. Commercial cloud scanners will usually offer help if you run into problems, and help interpret results. If you are skilled enough to do a scan without assistance, that may be unnecessary.


Some issues with iptables and nmap When I scan my pc with nmap I see only one open port. I didn't define any rule in iptables so if I'm not mistaken, all connections should be denied by default.

However I can use HTTP or SSH, so that means those ports are opened, but then... why nmap doesn't detect them as open ports?

Are you denying outbound or only inbound?  My memory of linux IP tables is a bit rusty, but it sounds like your inbound is deny all while your outbound is permissive.  Basically, the most common mode is that any external system requesting in (which is what nmap checks) will be denied, but if an internal connection makes a request out, it is permitted.  It is also worth noting that ports are asymmetric.  Just because you connect to a web server on port 80 does not mean that the connection back to your computer is on port 80.  It is fairly typical for random high number ports to be used for establishing connections.  The port numbers like 80 are used to give a common point to connect to.


Why can't I open the Chrome settings page from JavaScript? Please consider this simple method which opens a new tab in JavaScript:

<!DOCTYPE html>

Click the button to open a new browser window.

<button onclick="myFunction()">Try it</button>

This method works fine with URLs like https://www.google.com, but why can't I open the Chrome settings page?

Thats because the good folks at Google has decided that letting any webpage pop up the settings page would be dangerous. So they disabled it for the users security.

So what could a bad guy do with this? It could mainly be used to trick visitors of a site to change settings in a way that would benefit the attacker, e.g. reactivate insecure plugins or somehow lowering security levels. The non expert might not even understand that they are changing the browsers settings when they are on a page that popped up from some random website.

As a comparison, doing window.open("about:preferences"); from Firefox will just give you an error.

And really, what's the legitimate use case for doing this? I see no reasons for browsers to allow it.


Simple Authentication Method to Secure REST API I've been desperately trying to find a simple method of securing my API but still haven't found one that works. Unlike a lot RESTful APIs my API doesn't need user logins, tokens that expire, or other complex (though very secure) authentication methods, which makes most of the tutorials out there unusable.

The only requirement I have is that a POST request to log a record to my database on one route should be protected while a GET request to access records on that same route should be unprotected. The clients that are logging records are trusted and I would provide their credentials privately.

I've tried using this basic authentication method here:

var basicAuth = require('basic-auth');

var auth = function (req, res, next) {
  function unauthorized(res) {
    res.set('WWW-Authenticate', 'Basic realm=Authorization Required');
    return res.send(401);
  };

  var user = basicAuth(req);

  if (!user || !user.name || !user.pass) {
    return unauthorized(res);
  };

  if (user.name === 'foo' && user.pass === 'bar') {
    return next();
  } else {
    return unauthorized(res);
  };
};

But the POST requests still worked when I used the wrong username and password.

I really don't know what to look for anymore, as I thought basic authentication like that would work.

EDIT: Managed to get this working after changing a couple of things after app.post, which I had overlooked.

If you are not logging the RESTful GET that queries the data in your database and that data is intended to be public, then you can expose an HTTP GET and use the security built into the web server to keep harm from occurring during that operation.

For the RESTful POST, use TLS, the contemporary of SSL, but don't implement it yourself.  You can set up an HTTPS POST on any modern web server with ease.  Help desk support for installing the server-side certificate is usually supported by the CA.  Because people all over the world implement HTTPS POSTs every day, the support for that operation makes it easier to set up and maintain than doing something simple that's actually secure.

What you coded is not secure, which you may not think is important.

To exercise due diligence in answering your question, be warned that giving people credentials over the phone or on a piece of paper is not secure without employing a secure protocol such as HTTPS.  Relying on testing the value of a credential on the server leaves a gaping security hole that can lead to consequences you may have overlooked.

Attackers can easily identify the password on route and then wreck havoc on your client/customer/visitor's account and data.  Even if the data is not business critical, unprotected writes might end badly.  Someone could, for any number of reasons, place child porn or some military secret in your database, which you intend to leave open to the public.  You wouldn't be able to prove that you or one of the trusted users didn't put it there.


Common format to send encrypted data + IV? I have an app that receive data from third parties using various protocols: MQTT, HTTP, AMQP, ...
Some clients cannot use TLS (iot devices without TLS support), so we need to find some compact and easy way to receive encrypted data.

My idea is to use a symmetric algorithm (AES256 or similar), but how can I formalize how data are trasmitted?

Along with encrypted data we need also to pass an InitializationVector. There is a common "container" format that explain how you should package encryptedData+IV?

Of course we can just create our own format, maybe using ASN.1 or some other serialization format, but if something exists it will easier to explain to all developers.

UPDATE
Can Cryptographic Message Syntax (CMS PKCS 7) be a valid solution? Or is too complex to implement on small iot devices?

UPDATE 2
As pointed out by @AndrolGenhald I don't need to pass the salt if I store the key inside the device. I have removed the salt requirement.

UPDATE 3
We know that using TLS is the best solution, and in fact for most devices we can use it. Unfortunately some third parties developers tell me that they don't have TLS on a device type. I don't know exactly the detail (I probably should investigate better...). They ask us to provide a way to send encrypted data without TLS.

To answer the question of how to package the ciphertext and IV, concatenation should suffice: IV || ciphertext || tag. This format is convenient because it allows streaming of encryption. You generate and send the IV, stream the encryption, then calculate and send the authentication tag (decryption output can't be streamed however as the tag must be checked first).

The downside of course is that it makes it more difficult to change the algorithm or to support multiple algorithms. You could include an unencrypted algorithm identifier, but you would have to be very careful, as an attacker could change it to whatever they like, opening the door to downgrade attacks.

But you're wanting to do this with a pre-shared key as an alternative to TLS, so there's a lot more to it than that. TLS doesn't just provide confidentiality, it also handles key management and authenticity (among other things). The problem with a pre-shared key is that you have to be very aware of the constraints. RFC 4107 is worth a read.

Nonce/IV Reuse

ChaCha20-Poly1305 and AES-GCM both use a 96-bit nonce, meaning there is a 50% chance of repeat after 248 messages when using random nonces, so the key should be changed well before that (NIST says before 232 messages for GCM). It's also possible to use a counter instead of a random IV for certain algorithms, but there are difficulties with that as well. Due to this risk, the RFCs for ChaCha20-Poly1305 and AES-GCM as used in CMS both require that an automated key management system be used.

The simplest key management system is symmetric key-encryption keys. A content-key is randomly generated for each message and used to encrypt it, and a pre-shared key is used to encrypt the content-key to send along with the message.

Salt

Your question mentions a salt, which implies that you're using a password. This is a bad idea. To derive a key from a password requires a slow KDF like Argon2, bcrypt, or PBKDF2, and a constrained device is likely not fast enough to run such a KDF with a high enough cost to be secure. It would be much better to generate the pre-shared key with at least 128 bits of entropy. Confusingly you also want to transmit the salt, which implies that the password is changing, but this contradicts your comment that you put a "key" on the device.

Authenticity

TLS provides authenticity, which is important because commonly used encryption modes like CBC and CTR are malleable. It would be best to use an AEAD mode like ChaCha20-Poly1305 or AES-GCM, or, failing that, to use an HMAC with Encrypt-Then-MAC.

Constrained Devices

On constrained devices that aren't capable of generating cryptographically secure randomness (and thus can't generate a random nonce/IV or a per-message key), a pre-shared key with a stored nonce counter might be the best you can do. You just have to be very careful to make sure that nonce reuse is prevented even when the device is power cycled, and make it as easy as possible to change the key if/when that becomes necessary.


What vulnerability do inline javascript and event handlers expose? I'm trying to understand why certain CSPs block inline javascript. Is the concern that a user will be able to insert javascript that will then be served to other users? If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site? How is this a CSP problem?

If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site?

It is actually very common that users have the ability to serve their own content. Just have a look at all the social networks and public blog sites where users can provide their own content within a site they don't own.

  How is this a CSP problem?

Usually the content added by users gets sanitized, i.e. script and other things are removed. But, this sanitizing might have bugs. CSP offers an additional line of defense: if CSP disallows inline script no inline script will be executed even though some inline script might have bypassed the sanitizing.


Is telnet secure through SSH tunneling Firstly sorry, maybe dumb question, but I have one service running on my server which can be operated only by telnet (port 23), but I know that telnet is insecure, so I blocked port 23 in iptables except loopback interface (to be not accessible from internet, but only from localhost).

So my idea is that I connect to the server using SSH and then in SSH session I will connect to telnet localhost 23, so I wonder if it is safe or if it can be sniffed.

Yes. Controlling a Telnet client through an SSH tunnel is, in practice, as safe from eavesdropping as using any other program (e.g. a Bash shell) through the tunnel.

Telnet is called an insecure protocol because Telnet traffic is plain text which can be read and modified by anyone on the route between client and server (a man-in-the-middle attack). But if you're exchanging packets with localhost, there is no actual network traffic leaving the machine that could be sniffed or intercepted. Both Telnet client and server are on the same host, and the fact that you're using SSH to connect to that host doesn't put that local connection at risk.


Can personal VPN help protecting my behavior on the company laptop? Update:

I don't care if the company knows I'm using a private VPN (this is allowed and confirmed with the IT department). My only concern is if the company knows I visited nba.com (for example).
On iOS, I think the only demon/background monitoring is the "device management"? So they can only inject the TLS certificates
I'm not sure for the macOS if they pre-installed software to record the keystroke or the web requests before sending out via OpenVPN.
I am free to uninstall and install any browser so the Chrome/Firefox is not modified or customized by the company.
DNS might be another issue but I'm planning to set up a personal DNS server to handle that.
From the company policy, we are allowed to watch games and even play PUBG/LOL/CSGO using the company laptop. So there is no policy concern.

Question:

I'm using the company laptop (MacBook Pro with macOS 10.13) and iPhone (iOS11). I am aware everything could be censored when I'm on the company WiFi. Due to the device management (at least on iOS) and HTTPS certificate pre-installation, I think the company can also know every web request even I'm using the laptop at home.

So I'm using the personal VPN software (openVPN) whenever I'm not working. (For sure I'm using the company VPN when working and accessing the codebase, which is not in the scope of this question) My assumption is my personal browsing behavior over personal VPN should be protected and not visible to the employer.

Do I need any other steps to hide my behavior?

Yes. You should use the device you own to privately do anything.

Apple Configurator 2, which is used to configure corporate owned Apple devices, is able to

  ensure that the users’ web traffic stays within the organization’s guidelines.

It further notes that

  These include the
  ability to enable a web filter via a global proxy to ensure that the users’ web
  traffic stays within the organization’s guidelines.

If a global proxy is set, OpenVPN will have no chance but to communicate through the proxy, telling (warning) the IT that you are trying to a)connect to a foreign network which can lead to a data breach b)mitigate their control by using OpenVPN.

They could not be able to read the contents, but company policies may get you fired for getting your device unprotected by connecting to a foreign network.

Update:

  I don't care if the company knows I'm using a private VPN (this is allowed and confirmed with the IT department). My only concern is if the company knows I visited nba.com (for example).

They can't. But they can forbid deleting browsing history in a device, and require to hand them over.

  On iOS, I think the only demon/background monitoring is the "device management"? So they can only inject the TLS certificates
  I'm not sure for the macOS if they pre-installed software to record the keystroke or the web requests before sending out via OpenVPN.

You can see what the MDM monitors in the MDM profile section in Settings.

  I am free to uninstall and install any browser so the Chrome/Firefox is not modified or customized by the company.
  DNS might be another issue but I'm planning to set up a personal DNS server to handle that.

That's good. Although I am concerned about data breaches.

  From the company policy, we are allowed to watch games and even play PUBG/LOL/CSGO using the company laptop. So there is no policy concern.

You need to check a)what liabilities you might take if a data breach happens because of you b)is there an official confirmation that allows personal VPNs


Is TLS secure when full eavesdropping on the network occurs? Possible Duplicate:
  How is it possible that people observing an HTTPS connection being established wouldn’t know how to decrypt it?

Alice connects to Bob's site via a TLS secured connection (for instance, HTTPS is being transmitted).  Eve has full eavesdropping ability for all packets being transmitted on the network.

Would it be possible for Eve to decrypt the TLS secured connection?  If she is not able to do so, why?

Thanks!

Consider you want to send a letter to your friend. The content is secret. So you used a box having a special feature. Both of you will have a pair of keys to lock and unlock the box they are Public Key and Private Key. The scenario is the box can be locked using first key that is public key. But for opening that box you need to use second key that is private key.

Now, if you want to send a message to your friend you can ask his public key. He will give his public key. His private key is not shared with any one. When you receives the public key, you will put your message in that box and lock using your friend's public key. If you tried to open using the box using same public key it won't work because of the security feature of that box. You will send the box to your friend. If somebody tried to eavesdrop the box, they can't. It is not possible because the private key is not known for anybody except your friend. And don't think to break the private key using all key combinations. The algorithm used to lock and unlock the message is very strong and it will take million years to unlock if somebody tried to check using all the keys. The eavesdropper can get two information, who is  sender and who is receiver. All other information is hidden in that box. This is the simple scenario of  How TLS works. If your friend want to reply to you, he will request for your public key, lock the message using the key, send it to you. When you receives the message you will unlock it using your private key.

When you are using a website using https, your information including url, query string, contents, username, password are encrypted using the receivers public key. And the website replies from the website is encrypted with your public key. Your public and private keys are managed by your browser. So the content you are sending to the website is only decrypted by the web server and the reply of that request is only decrypted by your browser. No one else in the world can view or edit that contents. For more information you can Google Public Key Cryptography.


Making Users Prove They Have Reviewed The Information Security Policy Documents I am looking for a way to hold the departments accountable and ensure they atleast review the policies that we have.  I was thinking about using adobe sign but don't want to go cloud.  An application like those that make you scroll to the end then click agree would be nice if it kept track of the people who signed.  I'm looking for any recommendations, we have hundreds of users and docs.

Getting a web-page up with authentication and detection of "scroll to the bottom" should be fairly simple. See also https://stackoverflow.com/questions/3898130/check-if-a-user-has-scrolled-to-the-bottom
The problem is, that this does not guarantee that they even read the policy. See for example https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2757465, where quite a number where prepared to give up their firstborn child.
From time to time, we run small obligatory courses which highlight certain aspects of the policies. Sure, some seem to click through those courses relatively quickly, but they see the subject anyway. Being a big company, we also have the resources to embed small videos in these courses. But creating these courses is, of course, a lot of work.
You might create some quiz-type questions that must be answered. They might look-up the answer in the policy, which forces them to review at least that part. But unless you are enforcing a full exam on the policies which is required for the departments, you will find that there is always a possibility that the policy is 'just accepted'.
It must also be clear that violations of the policy might lead to consequences. And that the fact that you didn't know it was in the policies is never accepted as an excuse. "Nul n' est censé ignorer la loi", as the French say.
By the way, I hope that the "hundreds" was for the users, not for the docs. If you have hundreds of docs that the users must read, you need to prioritize, and have a critical look at your policies. No user will read hundreds of policy docs, and even if they do, they won't remember them.


HTTP/HTTPS/GET/POST : in which cases can a malicious router between client and server find a secret information? Let's say I connect a safe server example.com.

In which case(s) can a malicious router in the middle of the route (or my ISP) see secret?

1) HTTP + GET, secret in URL query parameter : http://example.com/mypage?user=abc&secret=238
2) HTTPS + GET, secret in URL query parameter : http://example.com/mypage?user=abc&secret=238
3) HTTP + POST, secret in request body: user=abc&secret=238
4) HTTPS + POST, secret in request body: user=abc&secret=238

?

I think it's true for 1), 3), but I'm unsure about 2).

I'm unsure because I've read that it's not best practice to pass such information via GET (even if HTTPS), but on the other hand, for many APIs, we have to pass auth tokens or api_key via GET requests: https://apiexample.com/endpoint3?api_key=SQKDJHQJSD&action=do123.

As long as the traffic is not protected (i.e. only plain HTTP is used and not HTTPS) a device in the path of the connection (like a malicious router) could in theory read and also modify the data without notice. This includes URL, URL parameter, POST body etc. Of course, the actual capabilities of the devices vary.

If the traffic is protected with HTTPS the body of the request and also the request header including path and URL parameters are protected against sniffing. Domain is part of the TLS handshake but is at least protected against modification too.


Nessus No host data is available for this scan error I encountered an error in a Nessus result.

  Error:
       No host data is available for this scan.

I want to scan IP 192.16x.x.x with Nessus. I scan this IP with nmap and only 2 TCP ports are open. Essentially, the results say the host is up. I checked my firewall rules. Nothing seems wrong with them.

I also checked the Nessus logs, but I don't see any meaningful errors in Nessus's logs.

How can I solve this problem ?

What I'd recommend here is that you configure a custom Nessus profile for this scan.  Set the ports to be scanned to the two you know are open from the nmap scan and remove the "ping the host" checkbox from the scan profile, so that Nessus doesn't think the hosts are down.


How hard would it be to crack bcrypt hashes if the salt is unknown? (This is not a duplicated of the linked question IMHO as this is more about the differences between a salt and password: both variables used to generate a hash)

Let's say an attacker has offline access to a database in which passwords are hashed with bcrypt (no pepper added). The hashes look like:

$2y$10$H0mRpD2XJZDguAzxTehwzunRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

In which the salt is: H0mRpD2XJZDguAzxTehwzu and the hash is nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G.

The attacker will be unable to run a rainbow table to match hashes, but she could compute common passwords using the salt included, so executing:

bcrypt("abcd1234", 10, "H0mRpD2XJZDguAzxTehwzu")

will produce:

nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

And there you have! She could go through all the database testing "abcd1234" and be able to identify which users are using that weak password in a matter of seconds/minutes.

So what if only the hash nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G is stored at the database (no salt)?

If the attacker has a strong feeling that the user "abcdefg" might be using the password "abcd1234", how could she test her theory offline? She would need to guess the salt. How could she do it? Is there any easier method than trying each combination? Maybe in that specific case there won't be enough motivation to try it. But what if she suspects the system is using the same salt for all passwords (as some hashes are the same)? How hard it would be for her to crack it?

UPDATE

Peleus's answer is close to what I was expecting. I will try to extend it (correct me if I'm wrong):

Entropy:

In Bcrypt a salt is usually of 16 random bytes (128 bits). If we compare that to a password of the same length, then a salt will have a grater entropy than a password, as passwords are usually limited to what the user can type with a keyboard.

Those 16 bytes are encoded into HEX (using Base64) and become 22 of length. If we compare them with a 22-chars password, then the password will contain a greater entropy (as it can include symbols and the full alphabet).

Length:

Bcrypt salts are limited to 16 bytes while passwords may be limited to 72 bytes, depending on implementation.

Collision:

2 different salts will generate 2 different hashes, and so the passwords. However at some point 2 different salts could produce the same hash using the same password and vice-versa. Which is the probability for each of those cases? That is something maybe I should ask in crypto.SE. But I leave it here in case someone has the answer to it.

Design:

The algorithm was designed to protect passwords and not salts. This means that salts are not mean to be safe by design, which suggests that there could potentially be a way to obtain them without brute-forcing them.

Fictitious Case:

We are used to the user-password method to protect access to a system. But, what if something like this happens (please bare with me, its just an example)?:

Company CauseWeWantItThatWay use microchips to store a unique 22-hex-chars value (to be used as salt). Each user will generate a total of 5 passwords or PIN numbers (4 digits each, yes, they are lazy) with that unique salt to access 5 different systems.

Now let's assume I'm assigned to one of those systems and I know one of those PIN numbers, and somehow I have access to the database. If the salt were included, it would be trivial to get those PIN numbers, however without the salt, I would have to crack it.

I know what you are thinking. The company has a really bad security implementation (and they should burn in hell). Also, that they could have used the "salt" as pepper instead, and leave the salt random. So my question was, in that case, it would be the same to add a 22-hex-chars as pepper than using those as salt? According to Peleus, is the same (so no shortcuts exists to get the salt).

After all not everyone follows the recommendations and the algorithm allows you to set the salt, which makes this kind of scenario totally possible (although not so probable nor recommended).

I think you've misunderstood the purpose of a salt, because if you understood what it is designed to achieve you perhaps wouldn't be asking this question. The only purpose is to provide a level of uniqueness to each password in order to prevent precomputed tables ("rainbow tables") being an effective form of attack.

As a result, it's not designed to be "secret" or add entropy to the password in any way, and that is why it is stored alongside the hash of the password. In fact in most cases it cannot be secret because the application itself will need access to the salt in order to calculate the correct hash of the password. It's very difficult to allow access to the application, but prevent an attacker who has breached the application from obtaining the same privilege.

Anyway to answer your actual question - in a theoretical world where you had to "crack" the salt because it was unknown, and could not be retrieved for some reason, it would be exactly the same level of complexity as passwords. Basically (character space)^(length).

In your example you give a hash of "H0mRpD2XJZDguAzxTehwzu". Assuming upper / lower case alphanumeric that's a character space of 62 characters, and it has a length of 22 characters. Hence 62^22 = 3.397504e+23   years of guessing assuming 1 billion guesses per second. In other words, uncrackable (this is even assuming the password is known and you're trying to simply guess a system wide salt).


Is the 'SUIDGuard' patch safe to implement? Can someone who really knows what they're looking at advise whether the patch published here by Stefan Esser is in fact safe to install?

While I'm very concerned that Apple haven't published an official patch yet (especially now that I've tried Esser's example myself), this is a kernel extension so I'm equally hesitant to just rush into implementing it.

Note: I'm grateful to Esser for drawing attention to this and am not implying his fix might by 'malicious' (particularly as it's openly published). I just want an informed answer on exactly how it works and whether there are any side-effects.

The first important thing is to think about the meaning of this security hole. This is a local privilege escalation: if an attacker can get to run code of his choosing on the machine, with "normal" privileges, then that attacker can use this hole to obtain more extended privileges on that machine.

In general, for a desktop system, when attackers can run their own code on your machine, they have already won. On a desktop systems, your own actions, as a "normal user", are all done as process running, from the point of view of the kernel, with the privileges attached to your user account. If an attacker manages to run his own code, it will be through subverting one of your applications, or making you unwittingly run a seemingly honest screensaver or something like that. Privileges attached to your account are sufficient to plunder the contents of all your files, display spurious ads, hijack your network connections, and generally steal your whole life. Also obtaining root privileges on the machine does not substantially increase the scope of the disaster, though it may make life easier for the attacker.

Moreover, as a "normal user", you already have ways to obtain root privileges, and you do use them on a regular basis -- e.g. to authorize an update of the Flash plugin. The updater system will ask you for your password and use it to request and obtain root privileges. An attacker who can run code under your name just has to mimic a Flash update to display the popup and obtain the privileges. In that sense, the new vulnerability is irrelevant for a desktop system. Correspondingly, there is no hurry in fixing it.

Privilege escalation holes make a lot more sense on shared servers, where several users who can potentially be hostile to each other share the same hardware, and the  OS must arbitrate between users and protect them from each other. Shared servers are an old model, back when we were talking of mainframes. An information security professional who is now in his forties must have been exposed to that model while he was a student, in the 1980s or 1990s. At that time, computer students were typically using terminals in some shared computer room, and accessing one or a few central servers with a Unix-like operating systems. Privilege escalation was then a much sought after grail.

This rarely applies nowadays. Right now, in 2015, when there is shared hardware, users are granted virtual machines, not simply shell accounts. There still are places where servers are shared in the old way, but they are a vanishing species. If your OS X machines are servers that are used that way, with users that you cannot all trust (or that do not trust each other), then yes, the privilege escalation hole is a big concern. However, chances are that this is not the case.

Assuming that you still want to fix the hole quickly by installing Esser's patch, then you have two points to consider:

You are, basically, inserting in your machine, with "kernel privileges", a piece of code downloaded off the Internet. This entails a rather heavy dose of trust. You must be sure that the Internet persona that appears to go by the name of "Stefan Esser" is trustworthy enough, and that nobody else could alter the patch where it is stored or while you download it.

How would some "guarantee" by another Internet persona, even with an awesome avatar, create some extra trust ?

You could, though, get the source code, audit it, then compile it yourself. But if you feel that you can do that, then you do not need any help from a StackExchange site; you already know enough.
The patch changes the behaviour of the machine, conceptually to make it "better" (or "safer"), but a change is always a change and may break things. It is possible that some application developer, somewhere, had noticed that some DYLD_* environment variables survive through SUID execution, and actually used it for some functionality (without necessarily noticing that this has security implications). While the patch appears to be harmless enough (at least from what I see in the source code -- but can you trust me ?), I cannot exclude the possibility that it impacts the behaviour of some parts of the OS or applications.


Is possible to implement a Web Cryptography API custom provider? I'm reading some basic info about Web Cryptography API and I'm wondering if is possible to implement some crypto provider (C/C++ library or something) with some extra algorithms or is mandatory to use the ones "embedded" with the web browser. I have finded articles about the security and tutorials about how to use it but nothing about custom implementation. I don't know if it uses Operating System libraries or only web browser libraries, if should be used "as is"... Some reference or clarification is appreciated.

See the specification 5.1:

  This specification assumes, but does not require, that conforming user
  agents do not and will not be directly implementing cryptographic
  operations within the user agent itself.

...

  While it is assumed that most user agents will be interacting with a
  cryptographic provider that is implemented purely in software, it is
  not required by this specification. As a result, the capabilities of
  some implementations may be limited by the capabilities of the
  underlying hardware, and, depending on how the user has configured the
  underlying cryptographic library, this may be entirely opaque to the
  User Agent.

Does it answer your question?


Can I check that a plain SSL private key corresponds to an encrypted SSL private key without decrypting it? I have an AES256-encrypted file ssl.key and the script which sets up some software required this to be decrypted to plain text as ssl.plain.key as in

openssl rsa -in ssl.private.key -out ssl.plain.key

This will interactively ask for the password.

However, if the software is reconfigured there is no need to regenerate ssl.plain.key unless the originating ssl.key has changed. (For convenience's sake, I would like to not have to re-enter the password each time the settings are flushed during development.)

Can I verify that ssl.plain.key was derived from ssl.private.key without decrypting the private key again?

Given that you use the openssl rsa command, I will assume that you refer to RSA private key files in the PEM format, encrypted using AES256. These look like:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,87FD3191BA64A020594BD81962FB092A

pqS/qSsKxhodfAafiqFyx4opaMo4HsQ9c97gT1YgI3DmZBN1w/8mlAPn8YAe98j6
...
/IlNA3RyQdHY1JIcHsnZ0HWW13kGQ1pzofhNbHQkOWimrKupKMmhPKSSMx6Q+lCm
-----END RSA PRIVATE KEY-----

Unfortunately for you, all the base64-encoded data here is encrypted (emphasis mine):

  The line beginning with Proc-Type contains the version and the
  protection on the encapsulated data. The line beginning DEK-Info
  contains two comma separated values: the encryption algorithm name as
  used by EVP_get_cipherbyname() and an initialization vector used by
  the cipher encoded as a set of hexadecimal digits. After those two
  lines is the base64-encoded encrypted data.

So it is impossible to obtain the original private RSA key without decrypting it.

Your configuration script must find other ways to detect that a RSA private key file has been updated (for example, by comparing timestamps, reading some markers, etc, etc.).

Since you mentioned SSL, note that certificates are bound to a RSA private key. In that case you can extract the public key from the RSA private key and certificate using:

openssl rsa -in server.key -noout -modulus
openssl x509 -in server.crt -noout -modulus


Excel vs PDF protection A recent requirement been received to automatically email Excel documents to customers. The customer would then amend the Excel file and send it back.

The current options are to password protect the excel document using unique customer data as the password (example: ID number) or to embed the Excel document into a PDF file and then password protect the PDF file using the same password.

With the above in mind, which would be easiest to send via email (less chance of errors during sending from server and receiving at the customer email address) and offer the best security?

Office 2012 or greater would be used.

Hmmmm.

On the one hand you want to store the data inside a file format which is a known malware propagation vector and send it on a round trip to the client, or on the other hand you want to embed this file inside another file which is also a known malware vector. Leaving aside the question of whether the content will actually be editable when embedded in the PDF file, it looks to me like you have increased the attack surface.

Speaking with my programmer hat on, if I want to send and receive tabular data, then (any of the) MS Excel format(s) would be well down my list of choices for a container. In addition to the known dangers of malware, it is horrendously difficult to parse and process compared with CSV, JSON, XML.

OTOH I recognize that for most mortals, trying to edit an XML or JSON file must seem like rocket science (but CSV isn't that much of a pain considering you need them to maintain the appropriate encryption for the return trip). But if its small amounts data then why not just use an online form over HTTPS which solves the problem of how the user manages the clear text as well as the issue of proprietary file formats and the issue of malware injection.

Maybe sharing an online spreadsheet is not an ideal solution.


Client-side attacks with custom malware in penetration tests I regularly perform pen-tests against web applications, operating systems, etc. Occasionally, I'm luck enough to do a 'red-teaming' exercise and get to attack at all conceivable points of a network (people etc as well) which is good fun and usually goes quite smoothly.

However, a client recently mentioned that they'd be interested in testing client-side (end-user) machines such as desktops/laptops as well, in order to see what type of attacks could be conducted against them, as a means of testing endpoint security (firewall/HIPS/AV/app whitelisting), and also to put their incident response program under stress.

They're looking at using custom malware to do this and are willing to let us try and propagate our own code in their environment.

Since most successful attacks these days involve client-side attacks (spear phishing, drive-by downloads, etc.) it makes sense to test the actual endpoints (which are usually a big problem). However, I'm worried that if we create a self-spreading piece of malware it will eventually get loose from the network, or that in one of the infinite possible application interactions, it will knock some server offline. Obviously the client will sign a waiver and shoulder risks like this.

Are client-side attack scenarios common requests? What other people do in these types of scenarios? Are there any methodologies to follow regarding the use of custom malware in client-side pentests?

You don't need a self spreading malware in order to test the end user machines. For example, if you decide to target the end user machines browsers, applications (MS Office, PDFs, Java, Flash) or physical security of the machines, what you need is a custom exploit and a payload. The payload need not to be self spreading. You just need a type of payload that give you control over only the machine you have targeted.

Let us take an example. Suppose I want to target 10 user machines and I decided to target the their browsers. The first thing I would do is I would host the Metasploit exploits on my machine. The exploits needs to be customized in order to bypass AV and other types of defenses. I can use meterpreter as my payload. Then I would send these 10 users a link to my server which is hosting the exploit files. If out of these 10 users I managed to make 5 users connect to my Metasploit server and I successfully exploit their browsers and gain access to their machine, the meterpreter is going to give me access to only those five machines. It is not going to target every other machine in the subnet automatically. Off course if I want to pivot further from there, I can do it manually.

So in the end, I think what you need is a custom malware but that custom malware don't need to be self spreading. Make a malware that is only going to give you access to the particular machines you are targetting.


CSRF double submit cookie pattern questions I have some questions about CSRF protection, specifically about the "double submit cookie" pattern.
What I have learned so far, is that this pattern has some weaknesses.
But we can add some improvements to protect ourselves from them.
Some of them are:

Sign cookie
Bind cookie to user
Use custom HTTP header to send request token
Cookie prefixes

If I understand correctly, CSRF attacks are performed by using (e.g. <img>, <iframe>) using GET request cannot set headers.
Submitting a <form> by JavaScript (HTMLFormElment.submit()) has limited headers but cannot send custom headers.
Am I right?
Here are my questions
1. Let's say we choose to send a custom HTTP header with the request to verify if the token is valid.
But before that we create a cookie with the name "XSRF-TOKEN" or a different name.
The problem with this approach is that in order to get the value from "XSRF-TOKEN" cookie, we have to allow
JavaScript to have access to cookies.
This, in turn, can lead to bigger problems like XSS attacks if we have some vulnerabilities.
Is this approach correct?
Is there any way to access the value from "XSRF-TOKEN" cookie without allowing to be accessed via JavaScript?
2. Suppose I have a REST API and using CORS configured to get and read the response data only from allowed domain.
To be more specific I also allow CORS requests with credentials.
If the attacker somehow manage to get the user to fill out and submit a form from his malicious site, even if the response are blocked by CORS policy the request will be sent with the user cookie.
In the case of the above pattern if I allow the cookies to be accessed by JavaScript is there a possibility for the hacker to access the user cookie and make a new request via JavaScript with the custom header and the value (token) from the cookie?
3. Is it necessary to add hidden field with the token on my form when using this CSRF protection pattern?
And if so, this question is related to my first question how to access the "XSRF-TOKEN" cookie safely if there is a way without allowing to be accessed via JavaScript and create new hidden field inside my form.
4. Let's say before I create a custom header I also sign the cookie with some secret.
For example what Next.js do is hash the token along with some secret and the result is stored on cookie.
Should every secret be randomly generated?
And if so, where it should be stored?
I will appreciate if someone can explain to me how methods (Bind cookie to user & Cookie prefixes) works.
Can I use one secret for every cookie stored in an .env file on the server or this is a bad pattern?

Starting with the questions:

Scripts can send CSRF requests (via XMLHttpRequest and fetch), not just forms and implicit GETs of page resources. However, there are very strong limits on what types of requests a script can send cross-origin. In particular, you can't send custom headers cross-origin at all unless the target origin (your site) sends a suitable response to a CORS pre-flight request (a special OPTIONS requests that the browser automatically sends before making any cross-origin request that an HTML form couldn't make). The response would need to specifically allow the custom header(s), along with allowing to source origin and, if relevant, user credentials (generally cookies). Thus, unless you've gone well out of your way to allow unwise things in CORS, simply requiring a custom header at all is proof against CSRF. You don't need to worry about the header value; it could even be the same for every user.
With that said, though, no. There isn't any way to get the value of a cookie into a header in a way that wouldn't be readable to a same-origin script (such as one injected via XSS). You could make the cookie HttpOnly and then either include the value somewhere in the response body or make it available via an API, but a script running in the user's browser on your origin can read such values.

Unless the attacker has a script running on your domain, or is able to intercept plain-text traffic between your server and the user, the attacker won't even be able to read non-HttpOnly cookies. Even if you make CORS tear as large a hole as possible in the Same-Origin Policy, there's just no API for scripts to read cross-origin cookies. That includes cross-origin cookies in requests originating from the script's origin.
With that said, I'm not sure why you think configuring CORS is relevant to anything an HTML form does. For "simple" requests - the kinds a form can send - CORS has no impact at all except on whether the sending origin can read the response, and forms can't do that anyhow (except in the sense that navigating the page is "reading the response", but it changes origins when doing navigating). If you didn't mean using an HTML form submission, there's no need to trick a user into filling out anything (actually, there isn't anyway, forms can be pre-filled or filled using JS and submitted automatically using JS, all with no user interaction).

The hidden form field is needed if, and only if, you're relying on an anti-CSRF secret token that is otherwise only sent in a cookie. If the token is sent in a header (or if you're just relying on the existence of the header, see #1), you're fine. If you're instead relying on the SameSite attribute on the cookie (don't do this yet, some very few people still use outdated browsers), then - much like the header - it won't be sent on cross-site requests anyhow so no need to compare the value to anything. Of course, you can send the value in both header and body (as well as cookie), and just check whichever is expected for the particular endpoint; this is sometimes done for sites that need to be usable without JS (precludes custom headers) or that are based on legacy web frameworks that relied on HTML form submissions instead of submitting requests via script.
There still isn't any way to do this without XSS being able to read the value.

Signing the token with a secret generally implies a server-wide (or even cluster-wide) secret, so you'd store it the same as any other such value (possibly in an environment variable, file outside the webroot including possibly a .env, database field, etc.). There's no point in using double-submit cookies at all if you're going to require a per-user secret to verify them; the whole point of this pattern is to avoid storing any per-session or per-user data that causes a bunch of extra DB hits / cache coherency issues. If you don't mind storing per-session state and looking it up on each state-changing request, generate a random token when the session is created, store it in the DB, and require it be present in request bodies; no need for anti-CSRF cookies at all in that case (their advantage is that no server state is needed).

In general, you don't need to worry about your CSRF protection holding up in the face of XSS. XSS pretty strictly dominates CSRF in terms of what it can do; if the attacker is able to pull off an XSS attack, CSRF protections are pretty meaningless (some, like SameSite on cookies, might present a bit of a speed bump, but even then I wouldn't count on it being sufficient). Remember, once a malicious script is injected into a page running on an origin (which is what XSS is), any requests it forges aren't actually cross-site any more.
Binding anti-CSRF tokens (in a cookie or otherwise) to a user just means that the token value depends on something known about the user and not known by an attacker. A simple example is to use, as an anti-CSRF token, the hash of the user's session token (assuming it doesn't change too frequently). Since the attacker doesn't know the session token - if they did, they could just hijack the session directly, no need for CSRF or XSS - they can neither guess the actual anti-CSRF value nor plant a forged anti-CSRF cookie on the victim. Another upside if this approach is that you don't need a separate cookie for anti-CSRF; the session cookie becomes, effectively, also the anti-CSRF cookie (hash it and see if the result matches the token in the request body).
Cookie prefixes are a way to avoid the risk of cookie-planting attacks, by specifying that cookies with certain names (those that start __Host- or __Secure- can only be set under certain conditions. This is necessary because, historically, cookies could be clobbered by other cookies from less-secure sources (e.g. HTTPS-created cookies from HTTP responses, specific-domain cookies from a subdomain or parent domain). Additionally, since cookie metadata (flags, origin, etc.) is not transmitted in browser requests, the server couldn't tell the difference between (in this case) the anti-CSRF double-submit cookie that it created, and one that an attacker created (assuming the attacker had some vector for planting cookies). However, cookie names are transmitted in browser requests, so a few name prefixes were carved out for special treatment that blocks cookie planting attacks. The idea is, you'd rename your cookies from, e.g. sessionid and anticsrf to __Host-sessionid and __Host-anticsrf. You have to change the name of the cookie that your check for in the request, too - the browser includes the prefixes when sending it back to the server - but the idea is that if those prefixed cookies are present, you can be sure the cookies weren't set by a different (sub/parent) domain or an insecure connection. Of course, this feature is new and not yet universally adapted, so it's not entirely safe to rely on it today (though it doesn't hurt to use it anyhow).

Honestly, at the end of the day, I really can't recommend anybody implement double-submit cookies today. Much like X-Frame-Options and then CSP made framebusting JS obsolete, and CORS made JSONP obsolete, double-submit cookies were a quick-and-dirty hack of a solution that has been superseded by better options.

Use script-initiated requests and add something to make them non-simple (couldn't be sent via HTML form submission), such as:

Any custom header
A verb other than GET, POST, or HEAD
A content type other than text/plain, application/x-www-form-urlencoded, or multipart/form-data (a common choice is application/json or sometimes application/xml)
A custom value in one of the standard headers that aren't a "CORS-safelisted request header", such as setting a custom Authorization header containing a bearer token (in which case you can avoid security-sensitive cookies altogether).

If you can't / don't want to do that, require that the request body (and thus, realistically, the HTML forms) contain a hidden anti-CSRF token that is the hash digest (or possibly HMAC signature generated using a server-secret key, though that adds little real benefit) of the session token.

If you're really paranoid about timing attacks, hash the session token once to generate the hidden anti-CSRF token, and hash it twice (and the token from the request body once) before comparing.

Use SameSite=Lax flags on your security-relevant cookies for any site that doesn't need to support authenticated calls across sites. Use SameSite=Strict for cookies on sites where the site doesn't even need to support top-level navigation from an external domain directly into an authenticated request.

While SameSite support isn't 100% yet, it's getting close, and it doesn't hurt anything to use it.
In fact, newer browsers are starting to treat cookies as Lax SameSite by default, now, so it really doesn't hurt anything to use that. You'd need to explicitly mark the cookies SameSite=None to get them to send on cross-site requests.
EDIT: As another contributor pointed out, "Sites" (as relevant for SameSite) are broader (and just harder to identify) than "origins". SameSite acts on sites, not origins, and might therefore allow cookies in some situations where you'd expect it not to. https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/


What happens if STARTTLS dropped in SMTP? SMTP uses STARTTLS extension to upgrade SMTP to SMTP Secure (STMPS). According the the RFC, the client and server starts TLS as follows:

S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

In the same document, the specs mention the possibility of MITM:

  A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server.

What I do not get it from the specs is: What delete exactly means? is it deleting the content of the message but sending it empty? (i.e. corrupting it) or dropping it so the client does not receive it?

If it means dropping the message so the client does not receive it, will the server send 250 DSN ? it is not clear to me if 250-STARTTLS dropped what is the next message going to be? how the client gets to know that it must send EHLO mail.example.com and that there is not 250-STARTTLS?

SMTP with STARTTLS works by first creating a plain connection to the server and then upgrading it to TLS if the server supports it. The server shows support for STARTTLS within the response to the EHLO command. A man in the middle could simply modify the response from the server and remove the information that it supports STARTTLS. In this case the client believes that STARTTLS is not supported and will not upgrade TLS.

For example the original SMTP dialog might look like this:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org
  << 250-HELP
  << 250-8BITMIME
  << 250 STARTTLS

From this the client will know that STARTTLS is support. A man in the middle or a firewall like Cisco ASA (but also others) might modify the response to make the client believe that TLS is not supported in order to inspect the traffic in plain:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org
  << 250-HELP
  << 250-8BITMIME
  << 250 XXXXXXXX

Due to this modification (in this case replacing STARTTLS with XXXXXXXX)  the client is not aware that the server supports TLS and thus will not try it. Even if the client still tries it the man in the middle could rewrite the STARTTLS command of the client into some other (maybe invalid) command so that the server seems to refuse the STARTTLS.

Note that the exact behavior in this case depends on the client configuration. While end user applications (i.e. MUA - mail user agent) are often configured to enforce TLS with the single configured mail server they use this is different with MTA (mail server - mail transfer agent) to MTA communication. MTA's usually don't know up front which next hop in delivery will support TLS so they just check if TLS is possible but continue in plain if it does not look like TLS is possible.

In summary: opportunistic encryption like this is a bad idea since a man in the middle can simply make both sides believe that the other side does not support encryption.


How safe is my private key? I'm keeping my private key in .ssh/id_rsa with -rw------- permissions.

But that means every user process can steal my private key which would be disastrous, I'm not going around running random executables, but how can you be sure no one reads it, if you are not compiling everything on your own? Can you spot if Google Chrome reads it?

I feel like I should employ security by obscurity.. like storing my private key in a random place and only letting SSH know the path (again maybe compiling my own executable, otherwise the hackers can just read the config value)

How do you keep your private files safe? Especially if you are managing many servers which allow access to this key.

Store the key encrypted (using passphrase). Then it can be read be any process, but not used.

Or store the key on the HSM (Smart Card, Yubikey), where from it can not be read, but only used upon your confirmation.

Also SELinux as mentioned in the comments can be answer for you, which implements labeling of files and processes and prevents unauthorized access to files the process does not need.


Preventing XSS and SQL-injection attacks I have a question about XSS and SQL-injection attacks. All of the prevention methods against these attacks that I've read about rely on changing the application itself. Validating, filtering and encoding input/output, in the case of SQL injection using parameterized statements etc.

Are there any methods that could be applied on the environment level (network, server, OS, web server, SQL database server) that could help protect against such attacks?

As Arminius mentioned, a web application firewall (WAF) (https://en.wikipedia.org/wiki/Web_application_firewall) is a service which sits in between the client and your server which attempts to filter out bad traffic.  The issue with WAFs is that they are prone to false negatives (permitting malicious traffic).  For example, a WAF may be able to block a SQL injection attempt for ' OR 1=1; --' but allow ' OR 3<4; --'

I recommend people view them as bandaids, rather than a final solution.  Use them to provide an extra layer of defense while you work on patching the application itself.


If an ATM is stolen, how easy can the personal information of the users be recovered? ATMs get occasionally stolen. How easy would be for the thiefs to retieve the PINs and other information of the users that have previously used the ATM? Is there a periodic wipe of all records/logs/traces on the machine within the ATM enclosure?

There is no way to no for sure what happens inside the ATM, but most ATMs handle transactions by connecting to a server.  There is no reason that it should have to keep any record of transactions internally.