What should I do to develop a secure note taking app in Android 8.0? One of the factors I considered was, having all the text encrypted and stored in the device memory. But we cannot avoid having raw unencrypted data on the RAM, when the application runs. Won't Antivirus, and other system level processes have access to the contents in my application's memory? Is there a way to ensure that the app's runtime memory is not viewed or monitored by another application?

I want this application to work well on Samsung Galaxy on8 that runs Android  8.0.

The purpose of this is, I want to be able to store notes/data that I don't want even the phone manufacturers or Google (through the OS) to have access to its contents. I do understand that people with a requirement of security at this level, will have a custom built hardware. But I just want to create a super secure application as a project.

These two goals are incompatible.

  I want this application to work well on [platform] that runs Android 8.0.

and

  Google (through the OS) to [not] have access to its contents.

"runs on Android 8.0" by definition means the OS (Android 8.0) will have access.

Assuming you want to do minimize that access, at the very least you will want to write your own keyboard. All those spell-check, auto-correct, and text prediction features are part of the OS, and the keyboard will have access to every key stroke you enter.

More reasonably, you probably shouldn't worry about RAM scrapers for memory, or the OS and keyboard, and just encrypt the bytes stored on disk for "good enough" protection.


How can I send an email from my laptop anonymously? I have a vpn, if I connect it and create an email account while connected to the vpn, and then send the email to the desired recipient, what other levels of protection/anonymity am I missing? I use PIA (Private Internet Access). I have the kill switch on as well so if the VPN disconnects, it will kill my internet access. Also, what is the difference in this case between using Tor and the vpn? If I use Tor then if I send an email to an  outlook or gmail account then would it go to their spam mail? I want to send an email from an outlook or gmail account. And can I access gmail or outlook through Tor? I want to know to what extent my VPN will help me from having my IP address traced back.

I have a vpn, if I connect it and create an email account while connected to the vpn, and then send the email to the desired recipient, what other levels of protection/anonymity am I missing?

If you create and use the email account through an anonymizing service (your VPN) and use the service correctly, there is no straightforward way to de-anonymize you. Of course, the usual side channels apply. Your ISP might correlate the time of your VPN usage, someone might recognize your writing style, your browser can be fingerprinted, etc.

If you use Google Chrome through a VPN with GMail, they might also employ additional means to be able to exactly identify your browser instance and could theoretically correlate that with a point in time where you use the same Chrome instance without a VPN. In contrast to that, the Tor browser developers went to great length to prevent various ways of fingerprinting.

  If I use Tor then if I send an email to an outlook or gmail account then would it go to their spam mail?

No. If you use a GMail account through Tor and send an email to an Outlook account, that's a connection between Microsoft's and Google's mail servers. For the mail delivery between the providers it doesn't matter how you connected to GMail in the first place.

  And can I access gmail or outlook through Tor?

Generally, yes. But GMail and Outlook might employ anti-spam measures to cope with fake accounts and hence might block some Tor exit nodes or VPN servers. You'd have to try out for yourself.

  I want to know to what extent my VPN will help me from having my IP address traced back.

That's too broad to answer in a single post. We have plenty of questions on VPN security here that you might want to have a look at. Also see: Differences between using Tor browser and VPN


What reasonable steps can I take to secure a used computer against malware or hardware modification? I’ve purchased a used laptop that should be arriving soon, and I’m wondering what best practices I can follow to make sure I wipe clean all the likely places any malware could be hiding.

I assume wiping the drives (one SSD and one HDD) and reinstalling Windows from a known-good ISO is a good first step. Should I also reflash the BIOS? Is there a way to check for hardware vulnerabilities? What order should I perform these important tasks? Are there any other vulnerabilities I’m over looking? Thank you!

About the software side first:

Yes, absolutely wipe the disks.
It will defeat most malware (because most are simply not sophisticated enough to remain somewhere else ), ti helps the privacy of the previous owner, saves you some possible legal troubles because of software licenses and/or confidential data, etc.

Anf of course, you have clean and fast system, instead of all additional garbage that collected with long-term computer usage before; with the settings and softwares of your choice only.

About the "how" - it should go without saying that wiping is not deleting files in Windows. However partitioning and/or dd from /dev/zero isn't enough anymore either.

With eg. an Linux USB (or any other system capable of this) first wipe both disks eg. with dd from /dev/zero, and then for the SSD also run a "secure erase" eg. with hdparm. Because due to wear levelling etc., the dd only isn't enough there. Since it is a laptop (often without SATA hotplug capabilites) and many buggy USB connectors, it might be a bit tricky, but nonetheless recommended.

And the hardware ...

It depends who you want to protect against.
 - The previous owner who was an average computer user?
 - State-level actors, HW vendors, and technical people capable of actually writing BIOS malware etc., who might have done something while (or before) the previous owner was using the computer?

For the first:
 - Per definition above, these people are not capable of doing much. Maybe able to buy a keylogger in the internet, but else...
 - Yes, flash the BIOS. Not so much because of malware, but just to have an update.
 - Make sure that, if you have Intel ME/AMT, that it is at least disabled completely. If you don't need it, I'd recommend using me_cleaner to get rid of it as much as possible. (In case you dont know what ME is, this "feature" allows full remote control of the computer, even when turned off (but with power). Of course the intended usage is that unauthorized people get no access. However the previous owner might have configured access for himself, and furhtermore there are several known security bugs).
 - If you want, open the computer and identify what each part is for. Eg. a small black box plugged in between keyboard and mainboard might save your typed passwords and probably shouldn't be there...

For the other group: If you think they might have done something with this computer (and something they don't do to all computers in your country etc.), then do not use it.
Even with all technical knowledge of the world, searching "something" they could have done would be searching a needle in a haystack. It isn't worth the effort. And of course we don't have "all" knowledge either.

Jus to address the BIOS / mainboard firmware: Updating it per software is useless against malware in it, because updating requires the cooperation of the mainboard (of course). If there exists some malware already, it just could say "ok, update finished" without actually replacing the infected parts.
As the relevant data usually is in a distinct device on the mainboard, changing it with proper hardware is better (as the turned-off mainboard can't prevent it). However, even if you find someone to do that, it's just one of very many possible attack vectors, so...

Related example: Devices like hard disks, network cards and CPUs have their own firmware. What about these? Right, you would have to replace them too (because of this cases, the next computer repair shop too has no tools anymore to force in clean data). And then you can replace everything and end up with a new computer.


how to extract binaries from SOHO routers and other devices I read this excellent article about vulnerability research into a DLINK wireless router.  The researcher explains clearly the coding mistake that leads to the vulnerability.  He obviously reverse-engineered a binary running on the device  but skips a step in how he acquired the code:

  The login action is performed via the URI /apply_sec.cgi. A quick search reveals that the apply_sec.cgi code is located at function do_ssc (0x40a210) in the /www/cgi/ssi binary.

What are some methods for acquiring these binaries (that is, the firmware)?  I've been learning how to use Ghidra.  Looking at vulnerable binaries from routers would be a good learning exercise.

Aside from the already-mentioned option of pulling and extracting firmware updates, most routers offer a command-line admin interface, available over SSH or even Telnet. Connect to this interface, and you'll be dropped into what is supposed to be a secure, restricted shell. In practice, the shell will almost certainly have some way to do command injection (for example, on some routers, running any allowed command followed by $(command) or even ; command will work).

Once you've got command injection, verify that you're root (quite likely). At that point, you can use common Linux commands (the device will have a limited command selection but you should be able to find what you need) to get a way to copy binary files. Extract individual binaries and/or entire volume images to your PC through that, and analyze them to your heart's content.

If you aren't root, you'll need to find a local EoP vulnerability on the router; these are common enough in Linux that old firmware will almost certainly have some, though you might need to compile the exploit for your specific platform. I've yet to see a SOHO router where I needed to do this; though.


If my server was compromised, is my database safe? I have an AWS instance running a rails app that I don't actively maintain. Since I didn't keep track of what was going on with this app, I didn't update it promptly when all the rails vulnerabilities were being discovered, so I think there's a good chance that it's been compromised. I want to save some of the data on it by ftp'ing a copy of the database (SQLite, if it matters) before I wipe it. Is it safe to do that, and to put the database back once everything's been wiped? Is there a way I can check the database to see if it's safe?

There are a couple of ways to check the validity of your data. Not finding signs of tampering doesn't mean your data was not compromised because the logs could be compromised as well. Logs should be kept in a different security container.

Check for changes against a backup. Even if the backup is old you could still identify changes to old data.
Check HTTP server logs for requests that would have touched the data.
Check DB server logs for queries that change data in a different way than the web application does. You can eliminate valid queries and identify malicious ones by sorting the queries by type and count.


Packet Injection during attacks on WPA/WPA2/WEP -- How it works Most Wi-Fi attacks rely on some kind of packet injection. This could be in the form of injecting deauth packets, arp packets, etc.

I have a question about these fake packets -- Are they constructed from scratch by the wireless network interface card? Or are they just clones of captured packets --- i.e., mere modifications of certain packet fields in already existing packets?

Looking at the TCP/IP stack, a packet typically gets built step by step at each layer; with each layer adding something to it. This makes me think that a NIC card, by virtue of operating at layer 2, would not build a full packet on its own. Any thoughts?

So, I'm going to say for this it works by understanding the protocols in place. I think that's going to be the only real answer for this question. See why below.

Basically packet injection is beacons that contain faked or generated packet details. Usually involving details from the iv or arp data you can pull in passive sniffing. Some tools allow you to try to get data such as ivs from launching other attacks, who would have guessed.

This site (or google yourself) shows an example of manually forging wireless beacons:
www.4armed.com/blog/forging-wifi-beacon-frames-using-scapy/

Which is largely similar to whats done in aireplay:
github.com/aircrack-ng/aircrack-ng/blob/db3e34dfb6bac7df69b6a05146ddfe57fe60a25b/src/aireplay-ng.c

In cases like this deauth attack, it builds a frame beacon that requires the generic broadcast mac. This is a known, hardcoded thing so it's easy to identify. Then sends this beacon. It's knowledge of the protocol that will help here, because (depending on implementation tbh) some cases routers will allow clients to deauth without requiring ivs. However, note the code for aireplay does provide the ability to use known ivs and replay them against the router. If you hit one system and one router, and tell them both to disconnect, you can usually just time attack it until it succeeds.

security.stackexchange.com/questions/20219/preventing-deauthentication-attacks

This previous example goes into details on why this beacon works, but tldr, it's a beacon you can send to your router, router says "okay, toodles" and kills its end of a session. At the same time, you kill the clients doing the opposite. Most situations you'd want to tell the client to disconnect from the router, or send the corresponding details to both.

The fakeauth tool on aireplay is a little more detailed in that it has to try a few more things. This can also be done in scapy, or really any language. The card doesn't necessarily handle this creation, the os or the program does (not to discredit the driver or the hardware, just not really relevant where it's created). Directly building these beacons in this sense is easier than rewriting an entire library just to handle the entire stack though. All you really need to worry about is your operating system's ability to handle these requests. However, as far as a layer by layer thing, I've actually come across debate to whether wireless communication is layer 1 or layer 2. either way, the idea behind the physical connection being the radio waves and the 802.11x or similar authentication stuff will be layer 2. This beacon, can contain arp packages and move the chain up to layer 3. With all that said again, protocol knowledge will help.

Other examples:
github.com/cyrus-and/zizzania/tree/master/src

Some people actually drop their own handlers for ieee802*. In which they built the compatible hex codes so they can be used accordingly.

The IEEE does provide standards documentation that details how to form your requests, this also gives you the baseline for researching these functions:
standards.ieee.org/getieee802/download/802.11ad-2012.pdf


What are the risks of a rogue Access Point?  What lessons can be learned from the Wifi Pineapple? I'd like to educate colleagues and peers on rogue access points using the tool "Wifi Pineapple".

What are some specific security-related lessons I could demonstrate?  If applicable, what are the mitigations to those attacks?

First and foremost, the pineapple demonstrates the concept of a rogue AP, as that is essentially what it is.

Every wireless card that has been configured to automatically connect to a previously known network will get connected to the pineapple. This is a hardware implementation of the karma attack.

Once connected, the pineapple becomes a powerful tool for conducting MITM attacks, coming with a good range of tools built in.

The pineapple can also be extended using modules that provide functionality like sslstrip, tcpdump and nmap.

Mitigation techniques that apply to standard MITM attacks also applies to guarding against the pineapple. One very interesting technique that is pineapple specific is to set a network with a name like pineapple as the SSID as the priority trusted network. If your card connects to that network, it means you have fallen prey to the pineapple. I read about it in a blog post about the pineapple, but i can't find it now.


Why do porn websies not use HTTPS? It seems that information relating to porn habits is quite telling, why wouldn't porn websites make the effort in protecting them?

Porn sites and advertisements are two business models which often depend on getting the best performance with the fewest costs. HTTPS impacts performance during the initial TLS handshake (can be reduced but not eliminated with session resumption). It also needs more computing resources to encrypt the traffic on the server side and decrypt it on the client side, which again impacts performance and/or increases the costs to run the site.
Another problem is the inclusion of third party sites (advertisements etc). To work with a https porn site these resources would need to be https too, because otherwise they will not show up (mixed content error in the browser).
But probably as soon as enough paying customers ask for https they will provide it optionally, because losing traffic because of an unsatisfied customer is probably more significant than losing performance or increasing costs.


Demonstrating SQL injection I want to do a demo for a login page that is vulnerable to SQL injection for training purposes. I already tried to build one using PHP and MySQL. I commented the code sanitation to make the page vulnerable.

The login page code is this:

//step 1a: sanitise and store data into vars (storing encrypted password)
//$usr = mysqli_real_escape_string($dbc, htmlentities($_POST['u_name']));
//$psw = SHA1($_POST['u_pass']) ; //using SHA1() to encrypt passwords
$usr = $_POST['u_name'];
$psw = $_POST['u_pass'] ;

//step2: create query to check if username and password match
$q = "SELECT * FROM users WHERE userName='$usr' AND password='$psw'  ";

//step3: run the query and store result
$res = mysqli_query($dbc, $q);

Then, I tried to enter this in the user name and password fields:
' or '1' = '1

However, the web page tells me the user name and password is wrong. How can I make SQL injection work?

If you are injecting both fields at the same time:

Think about the SQL string with the replaced text:

"SELECT * FROM users WHERE userName='$usr' AND password='$psw'  "

becomes

"SELECT * FROM users WHERE userName='' OR '1' = '1' AND password='' OR '1' = '1'  "

Can you run that query from a SQL prompt and get a response? I think you might find that the logic flow with all those ANDs and ORs will trip you up.


Security against IP Spoofing without consulting network administrator I was wondering that if there is a Local Area Network and one public IP,through which various clients connect(which have been allocated private IP's).Suppose one of the clients spoofs his IP to try to launch an attack against a server(say Google).Does there exist a way that Google uses to secure itself against such attacks,without the help of network administrator.

Under normal circumstances, the NAT / PAT rules on the router will change the source IP address to its own (public) address.  This is done by the router/gateway itself, and can not be set by a client (unless [mis]configured to do so).

The target webserver will still get packets from the real (public) IP address.


How to secure containerized python source code deployed at client side cloud How can we secure a source code which is deployed at client side cloud and is difficult to reverse engineer just like a licensed product The major difference is that I have a service to protect and do not have exe or dmg file.
I want to obfuscate the code deployed at the client side which was an internal API service till now but will be white-labelled and deployed away from my access. The usual methods to obfuscate isn't the ones feasible to opt for an always evolving code. The deployment needs to be scalable, updatable which is why container tech is preferred. However, container security is not my forte and I have read from different blogs that it involves user access management only which cannot 100% guarantee security.

Accept that you can't do it...
If you deploy a container (that needs to be accessible and re-bootable by the client, 101 times out of 100) then the container's contents is at the complete mercy of whatever containerization technology will have been adopted.
Either you can trust your client, or you cannot. If you cannot, then nothing stops them from cloning the container and either access its storage (if unencrypted; but if you encrypt it, you'll have to be available at each reboot) or pin the container memory and read the source off it. Almost always, the latter approach is available even without cloning, and containerization technology means that the application is not aware of what is happening, and has no way of detecting or stopping it.
All protection schemes in these cases rely on something that the client has not access to. You need to ask, "is there something - before I give them the container - that the client has not access to?". If the answer is "No", then you can stop right there (if it is "Yes", then you need to ask, "and do I have access to that?"). Hardware keys, for example, is something the client hasn't access to. External keyservers are also something they don't have access to. Third-party PAAS services also. Android "secure space", to a large extent. So, what you ask can be done in principle, but very probably, not in your scenario.
...and move on.
Now, unless you're doing "jobsecurity through obscurity", there's an overwhelming chance that your code will be something complex, probably difficult to maintain for somebody unfamiliar with it, and will contain nothing embarrassing or unprofessional.
So, your target becomes simply to be cheaper than just stealing your work. This can be done in several ways, starting from making it clear than stealing from you now will mean not simply renouncing to the next few fixes (which someone might be willing to accept), but to any and all maintenance. This you can do by calculating e.g. the hashes of your code units, and verifying them to ensure they haven't been tampered with -- in which case you will charge for the restoration or for your reverse engineering any changes.


What are the benefits of using IP whitelists to secure cloud servers/resources? Consider the following scenario:

There is a "server" (e.g. database, API, etc) that is "in the cloud" (i.e. hosted on physical hardware that is physically distant from the clients and reachable only by IP through the public internet).
The server only processes requests that provide valid credentials (e.g. password, access token, SSH key, etc.).  It can be assumed that this authentication mechanism is "sufficiently secure". (i.e. an outside without knowledge of the credentials would not be able to fabricate credentials via reasonable brute force)
The server is expected to only serve requests to a small list of clients that are pre-known.  Each client sends its traffic from a fixed public IP address that is pre-known to the server.

What security benefits are providing by configuring an IP whitelist on the server? (i.e configuring the server to only accept incoming IP traffic from whitelisted IP addresses assuming the client provides valid credentials and to reject all other incoming traffic even if that incoming traffic provides valid credentials.)  What types of attacks become impossible or more difficult based on the configuration of an IP whitelist on the server?

Security benefits:

If an attacker had stole your client credentials then he or she will have an additional trouble connecting to your server. Basically the intruder will have to connect from one of your client networks to have whitelisted IP address. An example of such a case: client looses his laptop or some one copies his hardrive or stole his flashdrive. IP of the client becomes one of the factors in your multifactor authentication system (credentials + IP address).
If your client has a malicious intent and leaves a simple backdoor on the server then after you revoke his access and remove his IP from the whitelist he would have an additional trouble connecting back to the server using the backdoor. If he didn't have root access to the server before then whitelist would make it impossible for him to connect through backdoor.
There are always some possibility that there will be a zeroday or oneday exploit to your authentication system (SSH or telnet or whatever you using). If your server blocks all traffic except whitelisted IPs then it makes impossible for an attacker to hack you from the internet. He or she would need to search for your whitelisted networks and then hack to some of them first.


Weird visitor from Samara ----forum.topic5982...908.darodar.com? I have seen this question asked about a user from Samara,Russia, and when I sifted through all the other occurances,everything everyone else is experiencing matched my experience, except for one thing. The number of visits. In one week the visits to my site from this one user are around 174, all from Samara, or another place that begins with a U inside Russia.  So other people were saying referring spam and whatnot, but this many visits? Also, the name of my business is Puppet Regime. So I am wondering if we are actually being monitored politically in some way. I have no political agenda, I actually make puppets, but I guess if I were a paranoid country I might take a look at a site that uses that phrase. Is there some way to stop the visits?

I am pretty sure that this is (as you already figured out) just regular referrer spam.

The "huge" number of visits makes sure that the referrer appears near the top of the referrer lists in you favorite analytics tool or you spot it in a manual analysis of the logs.
So no, this is not an extraordinary high number of visits but fairly normal. So it is highly unlikely that this is a manual monitoring process that masks as referrer spam.

There are ways to stop these kinds of visits (like blocking IP ranges) but these will certainly block regular users at some point.
I would not bother making extensive changes since your time might be spent better at some other point. If it bothers you, you might want to filter them out of you statistics.
Regarding ways to block IPs or filter certain users out of e.g. Google Analytics you will find a number of posts on this site.


What stops someone from just redirecting a HTTPS connection to a HTTP version of the site? Let's say someone does an ARP spoofing or DNS poisoning attack to redirect traffic to their own web server. If the real site has an SSL/TLS certificate, would that stop the hacker from redirecting let's say google.com to their own server? Doesn't the web server determine whether to connect via HTTP or HTTPS? And DNS lookup is done before they connect to the server. Couldn't they just tell the client to connect via HTTP instead of HTTPS?

The decision on whether to use HTTP or HTTPS is the client's.

If the user goes directly to http://example.com, an attacker could simply hijack that connection and perform a man-in-the-middle attack. If the user goes directly to https://example.com, then the attacker must spoof the SSL/TLS connection somehow; doing so without showing the user an invalid certificate warning requires the attacker to have access to a Certificate Authority's private key. This situation should never happen. Without this, the user's browser would reject the connection, not allowing the attacker to redirect.

In the case of Google and a number of other websites, they set the HTTP Strict Transport Security (HSTS) header, which causes the user's browser to cache a rule saying that they should never ever visit the site via plaintext HTTP, even if the user asks for it or Google itself redirects to a HTTP URL. The browser will automatically re-write the URL to HTTPS, or block the request entirely. This also prevents the user from clicking through a certificate warning in most browsers; the option simply isn't there.


How to assure my customer that my software is malware proof? We are delivering an application which our customers can use on their network cluster. Now, is there any way that we can certify that the software is malware proof and is not going to spread malware on their network? That caused me to think:

Executables sitting on a shared file server where only handful of the users can have access to it should be, in theory, "Safe". But how do we put an objective certificate to that statement?
Also, we can scan our files and may make sure the files are OK. However, how do we convey this fact to our customers in a categorical manner?

Two parts to this question:

  How do I show there isn't any malware in the product I'm selling?

Have a trusted third party scan, test, and verify that there is no malware. along with a good protocol for product transfer with a chain of custody will confirm. I used to work in this field and there are multiple penetration testing and scanning companies out there.

  How do I show that my application cannot be infected by malware (malware proof)?

This question can go down a rabbit hole. I would never tell someone that your application is malware-proof unless it only broadcasts out, has read-only filesystem, and is locked inside a safe with every hardware level I/O disabled and covered in epoxy.

If this isn't the case, I believe you can list the protections you have that make your device "malware resistant". Is there firmware scanning (checks for changes against a signature)? Is there antivirus installed? Does it have application whitelisting, etc. That, plus the 3rd party verification above should be a fair answer to your customer.


How to use Windows User Certificate (S/MIME) to sign data I am working on an internal ERP for my company. The portal is written in PHP and the current purchasing process is the following:

Create a new order on the ERP portal
Print the order (PDF)
Ask for signature (manual ones)
Scan the order
Attach the scanned file to the digital order

Instead of this cumbersome process, I would like to use the employees certificates (Installed for each user) to generate a digital signature directly on the web portal. Of course, the private key must remain safely stored by Windows. This new process is much simpler, and more secure than a scanned document

Create a new order on the ERP portal
Concerned managers receive a signature request
They approve the request (this is the tricky part)

Theoretically I just need to do this computation:

 $i = $order->id
 $a = $order->id + $order->integrityHash()
 $b = sign($a, $private_key) // Done on the client side
 $order->signature = $b
 $order->save()

My main issue is how can I securely execute:

 $b = sign($a, $private_key)

With a user certificate stored in Windows 10  under Certificates - Current User - Personal - Certificates to sign JavaScript data in my Chrome browser.

I am thinking of these possible solutions:

Use an existing solution
Write a Chrome plugin

Any advise?

You may look at this question

In C# you will need to use the Windows Store:

using System.Security.Cryptography.X509Certificates;
using System.Security.Cryptography;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);

            store.Open(OpenFlags.ReadOnly);

            foreach (var cert in store.Certificates)
            {
                string desc = cert.GetNameInfo(X509NameType.SimpleName, true);
                if (desc.Contains("WISeKey"))
                {
                    RSA pk = cert.GetRSAPrivateKey();
                    byte[] buffer = Encoding.Default.GetBytes("Hello World ... !");
                    byte[] signature = pk.SignData(buffer, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
                    System.Console.WriteLine(BitConverter.ToString(signature));

                    break;
                }
            }
            Console.ReadLine();
        }
    }
}


What does "exploit price" on vuldb.com means? I was checking vuldb.com, and they state in one of the boxes:

  Top vulnerabilities with the highest current exploit price of the
  current month. The evaluation happens multiple times per day.

What do they mean by "current exploit price"?

I think it means that in the "black market" that vulnerability could cost around that, am I right? If so, how do they measure it?

More info here: https://vuldb.com/?exploits.2016

Yes, it means that in the exploit market that kind of exploit can be sold and bought for something in that range (e.g. $25k-$50k). That website doesn't specifically talk about black market:

  The ongoing observation of the exploit market structure helps to collect current prices.

but, if you don't report vulnerabilities to bug bounties, the market you'll find is somewhat gray, if not definitely black, as the legality of selling exploits to a third party is dubious.

A well-known company in this sector, Zerodium, has published its payout ranges for different types of exploits: https://zerodium.com/program.html. There is also a famous 2012 Forbes article on the topic.

It is also very likely that vuldb.com crawls black market websites, in order to find more accurate information on the prices. However, there are probably market areas which cannot be easily found, such as the three/four-letter agency market (i.e. worldwide intelligence agencies, such as the NSA). It has been speculated that prices in those areas are much higher than the ones typical of the "standard" black market.


Is there a table that compares hashing algorithms by speed, relatively (machine independent) As far as I understood*, one of the major criteria when choosing a password / salt hashing algorithm is it's speed. To prevent brute force attacks, a slower algorithm is better (and also makes it more impractical to generate rainbow tables)

Assuming I understood correctly, is there any table that has machine independent relative benchmarks of those algorithms, sorted by speed?

e.g.

MD5
SHA-1
SHA-256
PBKDF2
bcrypt

e.g. if theoretically bcrypt is x times slower than SHA-1, then is repeating SHA-1 x iterations considered equivalent? (for brute force attack prevention related to hashed and salted passwords at least)

* I'm new to security, and to this site, please be gentle

To get an accurate measurement, you need to benchmark using your intended hardware with your intended software. Implementation makes a huge difference, plus some hardware can built-in acceleration for certain algorithms.

If you intend to use OpenSSL then you're in luck, because they have a built-in benchmarking suite.

$ openssl speed md5 sha1 sha256
Doing md5 for 3s on 16 size blocks: 4595381 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3732906 md5's in 3.00s
....
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              24508.70k    79635.33k   227390.21k   419190.78k   557154.30k
sha1             21918.90k    68573.48k   164350.12k   256347.14k   305924.78k
sha256           20979.09k    52742.04k   100939.52k   130634.07k   142630.91k


What considerations are there for using USB WiFI adapters and how to protect against them? Often with older machines, the built-in WiFi adapters have failed. These in turn drive a demand to procure USB WiFi adapters since ethernet connectivity is not a choice.

Since the devices will be plugged into a USB port, what are the security considerations when using USB WiFi adapters?

For example, does it make them more susceptible to physical attacks wherein they may be stolen and used to connect to the WiFi network? If yes, how can these attacks be protected against? Note, the devices that the USB WiFi adapters will be plugged into are not stationary. The users often work remotely or off-site.

The devices will be used for both Microsoft Windows and Linux desktops.

The passwords/phrases for a WiFi connection are not stored on the adapter so there is little additional data risk. The dongle by itself is not sufficient to connect to a network. In other words, if you are worried about theft of the dongle leading to network access - it's not a big deal. (Of course, bigger threat of theft of device may be an issue but exists in both cases)

I postulate that the device might be able to be switched out with a specially crafted special one which includes unwanted additional functionality (remotely controllable keyboard?) but that would be beyond the scope of most attackers, and could hide easily in ANY attached USB device.


How do I know that the request and response is using encryption protocols in burp suite? I know these things can easily be done on wireshark, tshark, etc but is it possible to know that the request I forwarded and the response I received is using protocols such as TLS, TLSv1.2, TCP, HTTP, etc in Burp Suite? So I won't have to switch to other network applications to see the protocols

Sample Request

POST /api/v2/app/login?optionalKeys=Yes HTTP/1.1

Accept: application/json; charset=utf-8
app-version: 2.3.12
version-code: 321
Tid: 21bb65df-0682-4085-8775-68e70f5653db
sid: dn6e4e7c-d956-4b3e-956b-9c6b9634ef39
os-version: 5.1
deviceId: a62fb2d91cb17587
swuid: a62fb2d91cb17587
User-Agent: Android
Connection: close
Accept-Encoding: gzip, deflate
latitude: 12.904043
longitude: 77.642919
X-NETWORK-QUALITY: GOOD
Content-Type: application/json; charset=UTF-8
Content-Length: 48
Host: xyz.abc.com
X-NewRelic-ID: UwUAVV5VGwIEXVJRAwcO

{"mobile":"1234567890","password":"Yt!*3773@8ATQwEr"}

I don't see any protocol mentioned

This depends on the tool you are using within Burp:

Site map - HTTP and HTTPS URLs are shown separately in the tree
Proxy - There is an SSL tick box in the table
Repeater - The target URL will show HTTP or HTTPS
Logger++ There is an SSL tick box similar to Proxy

Burp does not show the SSL cipher suite used. You can use the SSL Scanner extension in the BApp Store to scan for SSL vulnerabilities.


Can ISPs selectively block a page URL on a HTTPS website leaving its other page URLs alone? I want certain web pages blocked (within my country) by my Govt on a website that uses HTTPS on all pages. My Govt agrees that the specific URLs need to be blocked but expresses helplessness as their ISPs claim they can't selectively block HTTPS URLs but must block the entire website/domain / sub-domain which will cause genuine users to be affected. The prominent website in question has refused to take down the impugned web pages despite notices from my government and law enforcement requests.

No, the ISP cannot block specific HTTPS protected pages because it cannot determine which page is being accessed.
HTTPS does not hide the server that is being accessed, because it needs the SNI (Server Name Indication) to be on the clear, so the server can know which certificate to use on the connection. Once the handshake is established, everything else is encrypted, including which page you are requesting.
So the ISP have two non-optimal ways to answer: don't block anything, or block the entire server.

Encrypted SNI is actually a thing (I think Cloudflare did add support back in 2018). Admittedly I have no idea how widespread it is. – s1lv3r

Encrypted SNI is a thing for the future. It is part of the TLS 1.3 specification, but isn't something that can be enabled by changing a configuration option on the webserver. It needs changes on the DNS records, and support from the webserver. It still don't have widespread support among webservers and web browsers, and is still not mature enough for high-traffic servers to adopt it.
ESNI would help hide the domain you are accessing from your ISP and government (depending heavily on your network configuration), but would not help the ISP selectively block pages on the domain.


Bank wants my Online-banking PIN through the telephone My new girocard did not reach me. I wanted to call the bank to block the old and get a new one. So I checked my online banking and found a phone number ("Block card: girocard or visa card lost? Call 04106-...). I called said number, and I talked to a real person. So far, so good. The person wanted my Online-Banking PIN, through the phone, before doing anything.

Is this normal and safe operation, or was I correct to politely end the conversation?

What happens if my card is misused after tomorrow? I called their hotline to get it blocked, but they didn't want to do anything without my online banking PIN.

It is becoming quite commonplace in the US.  Many banks and other financial institutions require the caller to provide an identification number that has been set up beforehand to verify they are indeed talking to an authorized user of the account.

They used to ask personal information - social security number, old addresses, security questions, etc.  Those have begun to fall out of favor.

The 'telephone PIN' or user PIN, is not the same PIN as your debit or credit card nor online account password.  It can also be used as a secondary verification method when logging in online or when retrieving or resetting the online password.

So, no, it is not a sign of phishing necessarily and it is good that you found it suspicious and ended the conversation instead of blindly giving someone your PIN.


Would using a firmware password protect a MacBook Pro from Thunderstrike? And of course, any other possible attack that involves convincing the target to plug in a modified thunderbolt device into their MacBook
I know that Thunderstrike works on MacBooks with firmware passwords as of early 2015, but I'm not sure if Apple has updated it since then
Btw, is there a way to disable thunderbolt and just use the thunderbolt ports as minidisplayports?
This is on a MacBook Pro retina 13 with broadwell

No, a firmware password wouldn't prevent Thunderstrike.

The idea behind any kind of DMA attack is that a physical device can read (or possibly write) sensitive memory without the user noticing. This can also be used to bypass a lockscreen if the laptop is left unattended, though the usual attack scenario is that the user's Thunderbolt peripheral is replaced with a malicious version which performs the DMA attack and provides remote access or exfiltration, without them realising that it's happening.

As part of this scenario, the laptop would need to be attacked while switched on and in use. Otherwise there's nothing interesting in memory to steal.

As for disabling Thunderbolt, I took a quick look at some leaked circuit schematics for Apple MBPs (I can't link or embed them here for obvious reasons) and it looks like the mini-DP's data lines go directly(*) to the buses necessary to perform DMA. As such, it looks like they're directly integrated into hardware and, even if you did switch off the Thunderbolt functionality at the software level, an attached device can always talk to the memory directly.

Unless I'm missing something critical, unfortunately it looks like your only option is to physically disable the offending ports with epoxy, or switch to using a device which doesn't expose such sensitive functionality to peripheral IO.

(*) Technically they pass through some filtering and buffers, but these are irrelevant. I also only checked the schematic for one specific make and model of MBP, so others may have ways to cut off the Thunderbolt functionality via the SMC.


Promiscuous mode and packet sniffing Is it must for a packet sniffer to enable promiscuous mode?Can packets be sniffed without the NIC being in promiscuous mode?
Also when in promiscuous mode the NIC accepts all packets which are not addressed to it's MAC address.Does it also mean that it responds to all packets(it receives) that require a response? E.g : will it respond to all ARP requests(broadcast packets) not meant for it's MAC?Will it respond to all ICMP echo messages?

Is it must for a packet sniffer to enable promiscuous mode?Can packets
  be sniffed without the NIC being in promiscuous mode?

No it is not a must and sniffing can be done in non-promiscuous too.

  Also when in promiscuous mode the NIC accepts all packets which are
  not addressed to it's MAC address.Does it also mean that it responds
  to all packets(it receives) that require a response? E.g : will it
  respond to all ARP requests(broadcast packets) not meant for it's
  MAC?Will it respond to all ICMP echo messages?

Sniffing can be done in non-promiscuous mode too. But it really depends what traffic you want to sniff. If you want to sniff the traffic that is not intended to your NIC address then use promiscuous mode. On other hand in non-promiscuous mode, your NIC will drop/ignore the packet that it not intended to its address. Your machine will by default respond to all the braodcasts and multicasts(if your machine is in the same multicast group). By the way broadcast frames in general has destination MAC address of FF:FF:FF:FF:FF:FF. Thats the reason why every device will receive that packet.

In case of ARP, only that particular machine will respond who has that particular IP address for which the ARP query is being made! If I make an ARP probe for 10.0.0.1, then my ARP probe/packet will contain this information and the ARP probe will be broadcasted. So every machine on the same broadcast domain receives the ARP probe/packet but the machine with the 10.0.0.1 IP will only reply to this ARP probe. Others will drop it.

For TCP/IP I would recommend TCP/IP Illustrated, Volume 1: The Protocols, 2nd Edition By Kevin R. Fall, W. Richard Stevens I had it in my bachelors and it is a great book and will clear all the concepts. I would like to recommend it.


HTTPS and encrypted cookie for session Currently I am developing an SSO system with CAS. CAS uses an ticket granting ticket (TGT) that can be seen as the SSO-session. CAS by default will encrypt the TGT. And by default you also have HTTPS among the nodes.

Since HTTPS already deals with encryption I don't get why I need to encrypt the value of the cookie (TGT). Yes, you can still read the value from the cookie and use it I guess. But when you already hijack the session, you can also do it with the encrypted TGT since the client just send an encrypted TGT to the server and doesn't decrypt it before.

So my question is: What are the reasons for an encrypted cookie value if you already have HTTPS among all nodes? Can you mention possible attack scenarios?

Its correct that usually in accessing ssl encrypted website you don't need encrypt cookies normally , But its about even if someone somehow hijacked your ssl connection , the TGT should be unusable to that person.

As in the SSO scenarios things changes a lot .

Authentication Process / Request Flow

During Authentication process after your identity is verifies at KDC ( key distribution center ), Authentication Server sends two messages you.

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address
    lifetime of the TGT
    TGS Session Key,
    and is encrypted with the TGS Secret Key .

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGS Session Key is the shared key that will be used between you and the TGS.
 in next step

Your Client Secret Key is determined by prompting you for your password, appending a salt and hashing the whole thing. you can use it for decrypting the second message in order to obtain the TGS Session Key.
You can not, however, decrypt the TGT since you do not know the TGS Secret Key. The encrypted TGT is stored within your credential cache.

Now you have the TGS session key, you can request the final token to access the required service from TGS

The TGT ( encrypted with TGS secret key ) and for Example HTTP service request ( encrypted with TGS session key ) is send to the TGS

TGS now decrypts the TGT and fetches TGS session key , with this key it decrypts http authenctication request

The Ticket Granting Server then randomly generates the HTTP Service Session Key, and prepares the HTTP Service ticket for you that contains:

your name/ID,
HTTP Service name/ID,
your network address
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

Then the TGS sends you two messages. One is the encrypted HTTP Service Ticket; the other contains:

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

upto receiving the message client decrypts the second message and get http session key

Now User have access To HTTP service

What if TGT was not encrypted

If TGT was not encrypted anyone having that can alter the HTTP service request to either by forging anyone's identity in the request and get HTTP service session key

Even a user can exploit the authentication process anyhow jst by altering the TGT

so to avoid misuse of TGT encryption is done


Microsoft crypto libraries Since Cryptoware use the Microsoft encryption libraries, is it possible to disable them?  Or do other processes use it in the normal course of operation?

It is not possible to disable them.  They are an integral part of the operating system and heavily used by everything from schannel for secure TLS communications to innumerable third-party applications with various cryptographic needs.

In addition, even if this were possible, it wouldn't constitute any more than a minor roadblock as ransomware could be quickly adapted to ship with its own crypto implementation, making the configuration change irrelevant.


Difference between confidential, protected, and restricted data I've been reading this article about Data Handling Security Measures, what's the difference between confidential, protected, and restricted data? Maybe I could understand it well with example of the data itself.

Nevermind, those terms are depends on the data classification stated by the company (in this case NYU). Different company has different data classification so the term maybe should not be generalized.


Generating Own SSL certificate using DSC issued by a CA Ok. So, here is what I know:

SSL Certificate are used to verify domain for HTTPS protocol. These are issued by a root CA to ensure that it can be trusted by anyone using the website and trusting the CA as well.
A self signed SSL certificate won't be trusted because I am not a root CA and the user doesn't know me.
DSC (Digital Signature Certificate) is issued by a root CA to me and it has a private/public key pair and I can use this to sign things. Since it is issued by root CA too, I can sign documents and those can be verified by the third party.

Here's my question:

Is there a way to generate a SSL certificate using my DSC (Class 2) and use it for a secure SSL/HTTPS website? because in theory, this will create a whole chain of trust reaching the root CA.

(I have used both SSL & DSC and I just want to have a conceptual clarity here. I may definitely be missing something here.)

Certificates have depths, which increase as you go down a trust chain, so certificate depth 0 issues certificate depth 1, which issues certificate depth 2, etc...

To satisfactorily verify a full certificate chain, a client connecting to your SSL secured website would have to be able to find the intermediaries, and verify them, until it reaches a trusted certificate, which under any normal circumstances is a CA certificate installed with your OS.

An arbitrary client would not find your intermediary certificate in this case, because it will be equipped with all the usual certificates installed with the OS, but of course, it won't have your intermediary...

A desktop computer, or server, built as part of some sort of special corporate build for the company, can of course be tampered with, by adding certificates, and some companies do this, adding their own root CA with all the other default ones.

Your SSL secured web server can however provide intermediate certificates (along with its own) to the client when it connects so that it can complete the chained trust verification process, but...

The next problem is the intermediate certificate, the one issued to you by your CA, may not be valid as a CA itself, and if so it won't be accepted as an intermediate certificate.

Using openssl you can check this by running 'openssl x509':

openssl x509 -text -in CERT_FILENAME

Trying this on a CA certificate, looking through the output, you can see:

                ef:47:91:0a:72:ba:9e:85:3c:7e:39:6b:62:ed:d0:
                13:53:cf:52:52:e2:a8:1a:a8:27:5c:7e:08:a2:ad:
                17:1d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Key Identifier:
            5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4
        X509v3 Authority Key Identifier:
            keyid:5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4

        X509v3 Basic Constraints:
            CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
     17:e4:1d:18:d6:43:68:75:04:11:c0:6f:72:6b:ac:eb:03:18:
     1c:f3:e3:94:f8:77:b5:40:38:3b:20:cd:42:d7:de:db:7c:98:

The magic bit that you are looking for is:

            CA:TRUE

If CA is FALSE or the x509 extensions aren't there, it's not going to work as an intermediate CA.

Finally, also if you have openssl, you can do "openssl s_client -connect som.ssl.web.site:443 -CApath /path/to/your/CAcerts -verify 5", and hopefully you should, near the end of a load of output, get:

Verify return code: 0 (ok)

Where your intermediate is not valid as a CA though, you will get:

Verify return code: 26 (unsupported certificate purpose)

I tested this generating a CA, then an intermediate certificate, and an 'end' certificate signed by the intermediate, and although the chain of trust is verifiable successfully, used on a website, it does not work. If I generate a V3 intermediate with x509 extensions, setting the basic constraints of CA to TRUE, and then generate an 'end' certificate signed by that, again the trust chain is fine, but this time the web client is happy.


Deciphering ciphertext with an unknown key and algorithm How can I get started on understanding how to decipher this ciphertext when I don't know the algorithm or key used?

TDcbY xqCa NeAA OsWMirK FNFOm bYRUYAkxl,  tqwl  axZU  XTaLrBSFv OI G vWjBZyqhz.
 SUze pGUqZi fCxHFbaIK QnY n UxGMB. zHtA ViNNGQxQ esTphQ.
 EdmfAb aS vwMd oekezWAk BnHs EqEKK, DhvqTZNUn aeDo P c LeT EmuPyncQ, cimgJTk jFWcA de PlCtZ.

I performed frequency analysis and found a shallower distribution than I would expect for a monoalphabetic ciphertext of this size. Might indicate a polyalphabetic, homophonic, or polygraphic substitution cipher. These are just a few possibilities.

You can learn more about frequency analysis and its relevance to cryptanalysis here and here.

I would start with learning about frequency analysis and then running the analysis yourself. Search around with the links I've provided and google to help learn how to interpret the results and narrow the list of likely ciphers from that. Once you have a narrowed list, start looking for weaknesses in those ciphers and how to crack them. The wikis I've linked to have several descriptions on weaknesses of some implementations of these non-monoaplhabetic cryptographic methods.

If you end up narrowing the cipher list down and make a programmatic solution to bruteforce keys like I have had to in the past, you'll need to find a way to determine if a result is cleartext for each decryption attempt. Assuming this is English, you can implement an English detection tool. I've written about it here. Feel free to pilfer my English detection code in order to interpret your results. It's basic but has gotten the job done for me.

If you really want to get into solving crypto programmatically, this is a great resource: http://inventwithpython.com/hacking/.

And if you to take your learning a step further, learn about Friedman's IC, Cohen's kappa test, and the chi test and their relevancy to cryptanalysis.

If this is some school or crypto event challenge, it very well might be an implementation with a known weakness that can be exploited. If this is something like Raytheon's job offer challenges (as have been found on business cards in the past), I would expect it to require much more effort.


How can I detect HTTPS inspection? In my company I do use my computer for private things like online banking and personal email during lunch time.

I've always thought that when Firefox shows me the green lock symbol that a valid HTTPS connection has been established and no one can eavesdrop. I've now heard that HTTPS inspection can compromise this.

Actually I have two questions:

Is my understanding correct, that for HTTPS inspection my company would deploy Firefox with a "faked" security certificate so it can pretend to be the site that I actually wanted to reach and conduct a man-in-the-middle attack?
How can I detect whether my connection is snooped on?

My company uses the Forefront TMG as I can tell by a tray icon in Windows 10.

Thanks a lot in advance!

If your company owns and manages your computer, they have following options to inspect your HTTPS connections:

Adding their certification authority to operating system/browser
trusted certificate store. This will allow them to generate valid
certificates on the proxy for any website you are connecting to.
Furthermore, they are even able to turn off certificate preload
lists in the browser, thus allowing substituting “known good”
certificate with a spoofed one.
They may install software on your PC
to monitor all filesystem and network activity, including HTTPS
connections. There are a lot of data loss prevention (DLP) software
vendors who offer such functionality. It may operate in silent mode,
completely invisible to user. This software is surprisingly common
within the enterprises.

Connection snooping on proxy server is relatively easy to detect. The website certificate presented to you by proxy will differ from the one you get when opening site from your home or even using mobile device. If public keys and certificate fingerprints of aforementioned certificates don’t match, then there is almost certainly connection snooping happening (there are sometimes valid reasons for this mismatch, so it is a good idea to check the whole certificate chain the same way in this case).

If the company uses endpoint software to watch the employee activities, then detecting this becomes harder, especially if you don’t have administrator privileges. If it is not running in silent mode, you can look up list of running processes, system tray or list of installed programs to see if there are some odd/unknown programs listed (and then search their names online). In case of silent mode of operation, detecting it will probably require kernel debugging/rootkit detection skills (or asking a sysadmin).


From a PCAP file determine if the address has been spoofed? Reading about the tool hPing, it is possible to spoof an internal address, on the detection side of this how would one go about detecting this? are there tell-tail signs?

EDIT: thinking about it, you could use the MAC Address of the Internal IP, but are there other ways??

There are a couple of things to think about with your question.

First, you mention "spoof an internal address". Assuming you mean spoofing a reserved 10.a.b.c or 192.168.a.b private address space, how do you plan to get the packet into the victim's network?  Those are "non routable" addresses, meaning that no internet router knows where to send a 10. address.  This includes your home router, which will not send 10. packets onto the internet in the first place.  For this attack to work, you must already be inside the victim's network.

Now let's assume you're successfully attacking from within the internal network.  Yes, you can spoof a source IP, but how are you going to see the response?  The response will be sent to the real IP, not to your machine.  To solve this, you'll have to take over the real address.  This can be done using a technique like ARP cache poisoning.  And ARP attacks are detectable with certain kinds of network monitoring tools, so this is not guaranteed to be an entirely invisible attack.

Another option would be if your machine is on the same subnet as the victim machine, and you have full access to the network switch.  Most managed switches allow the creation of a "mirror port" to capture packets for network monitoring tools.  You could theoretically use data from the mirror port to see the replies and mount your attack; but be aware that this will still be delivering those reply packets to the victim's computer.


Determining network topology from the outside To what extent can an attacker generate a map of a network from outside of it?

Are network scanning tools such as nmap the only means to do this? Otherwise what other types of tools or techniques could be used?

Say you have a network with internet facing servers in a DMZ, the internal network, then internal servers in a special subnet. Is it possible to prevent attacks outside the network from learning the IP addresses of the internal servers?

What could you do to prevent this?

NOTE: I am aware that too much effort should not go into hiding this information, I am just curious and wish to learn more about what is possible.

I am also aware there are a variety of ways to gather the addresses of the internal servers in my scenario, I am only interested in the scanning aspect however.

Natting can help, but there are places where information leakage is common.  If you have internal mail servers you may be exposing your internal DNS naming conventions through mail headers.  IP addresses could even be listed in those headers depending on your configuration.

Error pages on servers in the DMZ could expose the internal (ie DMZ) addresses of hosts, and sometimes can even expose information about systems with interfaces internal to the network.

How much should you work to mask this information?  It depends on the sensitivity of the information you're protecting internally.  If you're extremely worried you'd want to look at application level firewalls that can strip that sort of information on the fly, as a double check to your configurations.  Further some systems just can't have these pieces of information hidden, and an inline solution could help cover the gaps.


CA certificate and Local certificate There is something which is bothering me when i think about the CA cert and Local cert.

Below are my queries which pertains to juniper but may be generic as well.

1) "request security pki ca-certificate enroll ca-profile ROOT2" The above is used to get the CA certificate from the CA server if I am not wrong. And the same(certificate) is used to confirm that its indeed a trusted CA server. But what does the cert actually contain? How does the device know that its the intended CA server?

The above diagram shows how the Recipient receives the Cert and decrypts it using the CA's public key. But how does the Recipient know about the public key and the Hash algorithm?

->Is that negotiated separately before all this happens?

-> And does that happen in clear-text?

->And also, is it a one time thing, as in is the CA cert loaded onto the router and is used only once to just authenticate the CA server or is it used again during any time of the traffic flow between the IPSec peers?

2) "request security pki local-certificate enroll certificate-id"

In the above step, the VPN peer is requesting for a local cert.

->So, is it during this step that the CA server gets to know about the peer's public key or is it exchanged well in advance?

-> And does the above diagram hold good for the local cert as well? In this case, the cert contains the peer's public key and other info such as subject, etc and does it hash it to create a "fingerprint/digest" and again encrypts it with its private key?

-> And if the above process is correct, then do the peers again check the local cert's integrity and authenticity by decrypting using the CA's public key and then only sending it to the other peer ? If not, does it directly send the received local cert to the peer?

I couldnt get the answers for the questions asked above.

Please help me understand the same. Thanks a lot in advance.

First, the diagram you posted just shows the general process of a CA issuing a certificate (by signing a hash of the certificate's contents with its private key), and a client verifying that a certificate is issued by a specific CA (by verifying the signature using the CA certificate's public key).  For this to work, the client has to trust that particular CA (or at least the root of a multi-level PKI), i.e. it has to be in possession of its certificate beforehand.

This is only generally related to the Simple Certificate Enrollment Protocol (SCEP), which the mentioned commands on Junos OS use.

As you mentioned, request security pki ca-certificate enroll ... requests the CA certificate(s) from a SCEP server. The device does not trust these certificates automatically. Instead, the command prints the subject distinguished names (DN) and fingerprints (hashes of the public key) of these certificates and it's up to the user to verify and confirm them. According to the documentation this could look something like this:

user@host> request security pki ca-certificate enroll ca-profile entrust
Received following certificates:
  Certificate: C=us, O=juniper, CN=First Officer
    Fingerprint: 46:71:15:34:f0:a6:41:76:65:81:33:4f:68:47:c4:df:78:b8:e3:3f
  Certificate: C=us, O=juniper, CN=First Officer
    Fingerprint: bc:78:87:9b:a7:91:13:20:71:db:ac:b5:56:71:42:ad:1a:b6:46:17
  Certificate: C=us, O=juniper
    Fingerprint: 00:8e:6f:58:dd:68:bf:25:0a:e3:f9:17:70:d6:61:f3:53:a7:79:10
Do you want to load the above CA certificate ? [yes,no] (no) yes

An alternative to using that command is request security pki ca-certificate load ..., which will load the CA certificates from a file (i.e. not via SCEP).

After the CA certificates are installed and trusted, they can be used to request end-entity certificates via SCEP. The command request security pki local-certificate enroll ... does exactly that. It will create a public key pair and generate a certificate request, which contains the client's public key and subject DN and e.g. certain extensions like subjectAlernativeNames. It may also contain a challenge password if the CA requires it. That PKCS#10 request is encrypted with the CA's public key (or in certain cases the challenge password) and sent via SCEP to the server. There the CA verifies the request and, if accepted, issues a certificate, which is then returned via SCEP to the client.


Sending Salts For Key Generation I am working on a project that uses a combination of a web based framework (Django) and an installed app (Python) for the purpose of data entry/upload. I will have to send medical records over the web and I've been trying to come up with a way to make a system that is cryptographically sound. I figure I can use django's auth_user table which contains usernames and hashed and salted passwords. The default format for this field is

algorithm_____$#iter$Salt_____$_________hashedpassword_____________________
pbkdf2_sha256$100000$6ID5G1Xym$s2snCtv3UncgSfGIS49d38ksv9LYuLGEsvWQwU66/xE=

If I have password and the salt, I can recreate the hashed password which I want to use as the key for AES. The problem is that the salt is randomly created by django during password creation.

My question is, would it create any insecurities to send the salt along with the encrypted information?

I'm thinking that it would not because the salt is assumed to be known by an attacker anyway.

Side question: Is AES considered secure for medical information? Are there any pitfalls I should be aware of?

The standard advice is: Don't roll your own security system and expect it to be secure, especially in an area with strong regulations for data security and especially if you are new to the field (though its good to ask questions).

First, your intuition is right; there's no big problem in revealing your salt, which does not need to be kept secret like the password (and the hash).  All the salt needs to be is to have a high probability of uniqueness (so all accounts aren't easily attacked in parallel).

Next, AES is a secure block cipher and when used in a proper block cipher mode provides a good deal of security.  ECB mode definitely should be avoided as it often leaks information.  CBC and CTR modes are secure to keep the contents of your file secret, however these modes do not come with any sort of authentication code/MAC built in that verifies no one tampered with your data.  You probably should use a mode of authenticated encryption, preferrably encrypt-then-MAC.

I worry about whether an network eavesdropper could listen in on a session cookie of the django web-server, then use that cookie to log in as the administrator and then get all the users' hashes and decrypt all the information sent over the network that they shouldn't have access to.

I also would be wary of potential replay attacks (add one-time nonces to encrypted requests) or leaking information from the size of the encrypted responses; e.g., if an anonymous person could make a request to the server every day for X's medical records and find by the size of the response that they've visited or not visited recently.  Also, I would be wary about where the medical records are going and will they be encrypted at rest on user's hard disks.

I also worry whether you are doing adequate audit logging of who is viewing what medical data and whether that data cannot be easily tampered with.

Not knowing the full details of your scenario and security requirements, I think it may be better to just use TLS (formerly known as SSL) with a secure certificate, plus a well-known utility to provide full disk encryption.


Difference between X-Forwarded-For IP, X-Real-IP, VPNs and TOR I have this Google Chrome Privacy Preserving Extension that I am working on. Where I can spoof the header information e.g user agents and else.

When I spoof X-Forwarded-For IP and go to http://whatsmyuseragent.com/ I see a different IP and my physical location. Whereas if I go to http://whatismyipaddress.com/location-feedback I see my actual IP and physical location.

If I access the same site from TOR/VPNs I see entirely different location and IP. which means TOR/VPNs hide my true identity. I know that proxy receives my request and forward them on its behalf, why doesn't X-Forwarded-For IP do the same ? I mean what is the point of spoofing X-Forwarded-For IP when it just tells the originating IP despite of I have changed it many times?

X-Forwarded-For header may be used to forward client's real IP in case of source NAT. But not all application use them.

This header is often inserted by load-balancers or reverse-proxies, depending the architecture in place, when the application needs to know the real IP belonging to a client.

When this header is inserted, the application can see 2 IPs:

Source IP used in TCP/IP connection
IP set in X-Forwarded-For header

Setting this header does not hide your real IP (as it is still used in TCP/IP connection) but can trick applications using it. However as you were able to see, not all applications are using it.

With TOR and VPN, this is the IP used in TCP/IP connection which is modified by (respectively) your exit node/your VPN gateway. However, they don't (and should not) operate at application layer, and they don't (and shouldn't be able to) insert the X-Forwarded-For HTTP header, thus your real IP is hidden.


Implementing generic login for Zap I need to build an automated tool that will be able to login to any website supporting basic auth to perform an authenticated scan with OWASP Zap (credentials provided). Here is what I have in mind: using python requests library, make an initial login request to the login page, parse the response, and based on it, create a login Zest script. Then use that to authenticate Zap for spidering and scanning. Are there are the potential pitfalls with this design, can it work in principle? Many thanks.

ZAP supports HTTP basic authentication natively, so you wont need to use Zest in this case. If you know that an app uses basic auth then you can set that up via the API. However I recommend that you start by using the ZAP desktop as this is much easier to use when debugging issues. For specific help with this its probably quicker to ask on the ZAP User Group: https://groups.google.com/group/zaproxy-users


Difficulty using SET within Kali Linux When setting a website attack vector, I find that Kali does not give me the option to specify a port in order to receive information back to my local. Furthermore, I am unable to access the listener I created as I simply get a "this page cannot be loaded" error when I attempt to open the external IP address in another computer. My SET configuration is as follows:

set:webattack>3

The first method will allow SET to import a list of pre-defined web
 applications that it can utilize within the attack.

 The second method will completely clone a website of your choosing
 and allow you to utilize the attack vectors within the completely
 same web application you were attempting to clone.

 The third method allows you to import your own website, note that you
 should only have an index.html when using the import website
 functionality.

   1) Web Templates
   2) Site Cloner
   3) Custom Import

  99) Return to Webattack Menu

set:webattack>1
[-] Credential harvester will allow you to utilize the clone capabilities     within SET
[-] to harvest credentials or parameters from a website as well as place them into a report
[-] This option is used for what IP the server will POST to.
[-] If you're using an external IP, use your external IP for this
set:webattack> IP address for the POST back in     Harvester/Tabnabbing:73.196.210.4

  1. Java Required
  2. Google
  3. Facebook
  4. Twitter
  5. Yahoo

set:webattack> Select a template:2

[*] Cloning the website: http://www.google.com
[*] This could take a little bit...

The best way to use this attack is if username and password form
fields are available. Regardless, this captures all POSTs on a website.
[*] Apache is set to ON - everything will be placed in your web root directory of apache.
[*] Files will be written out to the root directory of apache.
[*] ALL files are within your Apache directory since you specified it to ON.
Apache webserver is set to ON. Copying over PHP file to the website.
Please note that all output from the harvester will be found under     apache_dir/harvester_date.txt
Feel free to customize post.php in the /var/www/html directory
[*] All files have been copied to /var/www/html
[*] SET is now listening for incoming credentials. You can control-c out of this and completely exit SET at anytime and still keep the attack going.
[*] All files are located under the Apache web root directory: /var/www/html
[*] All fields captures will be displayed below.
[Credential Harvester is now listening below...]

As you can see, I do not get the "Credential Harvester is running on Port 80" messages, and I am unable to use the harvester that I jsut created. Any help is appreciated!

Make sure that your apache2 service is running

service apache2 start

Note that using SET on a virtual machine might cause problems sometimes.

And finally, i guess in the newer versions of SET you wont find the username and password on the terminal itself, instead you will find them in the www directory


using Uuid for security I read that uuid does not bring any security advantages

But I can't find why It doesn't bring a little bit of extra security in the scenario below ?:

Consider that right now the session id is encrypting the auto-increment id (no uuid is used). If someone manages to know how the session is encrypted, then he can impersonate all the users: encrypt "1" and set the value as sessionID, encrypts "2" and set the value as sessionID, etc.

Also consider that ids are not exposed.

Now if we were using uuid in place of auto-increment id, it is harder for the attacker to attack all the users as he can hardly guess the IDs present in the table, unlike with auto-increment id where he knows that ids are sequential. So It would prevent enumeration attacks.

I read that uuid does not bring any security advantages

This entirely relative to a given context. So it's neither true or false.

  Consider that right now the session id is encrypting the auto-increment id (no uuid is used). If someone manages to know how the session is encrypted, then he can impersonate all the users: encrypt "1" and set the value as sessionID, encrypts "2" and set the value as sessionID, etc.

Session identifiers work if they're long random pieces of information. They do not encode or encrypt any information, these tokens are used by the server to locate information pertaining the established session.

In a typical scenario, client A connects to server B for the first time. They have no information or session id at this point. Server generates a new session id and sends it to client. Potentially authentication occurs and some data is stored on the server pertaining that particular session. Every subsequent request from the client carries this identifier so that the server can match the data relevant to that particular client during this particular session. Notice the data is stored on the server, all the client does is issue requests of whatever kind and tack on the session identifier as a way to maintain state in a stateless system.

Simultaneously other clients are doing the same. The server can maintain multiple states since every client uses their own unique session identifier. If the sessions weren't random or easily guessable, then an attacker could calculate or guess them and hijack established sessions.

So a randomly generated UUID is no better or worse than a randomly generated session identifier for the same length of random data.


Can a running interpreted program cryptographically prove it is the same as as a published source code version? Can a running interpreted program, for example in languages like python, javascript, ruby, java or php, cryptographically prove that it is the same as a published source code version in a way that could not be tampered with?

Said another way, is there a way to ensure that the commands/code executed by such a program are all and only the commands and code specified in a publicly disclosed repository?

The motivation for this question is the following: In an age of highly sophisticated hackers as well as pressures from government agencies for "backdoors" that allow them to snoop on private transactions and exchanges, can we ensure that an application has been neither been hacked nor had a backdoor added?

For example, consider a server running python code like PyBitMessage (Bitmessage/PyBitmessage on github) for secure messaging.

Or consider an open source-based nodejs application like lesspass (lesspass/lesspass on github) which is used to manage passwords and available for use here (https://lesspass.com/#/).

Or an alternative program for a similar purpose encryptr (SpiderOak/Encryptr on github) with its downloadable version (https://spideroak.com/solutions/encryptr).

Is there a way to ensure that the versions available on their sites to download/use/install are running exactly the same code as is presented in the open source code?

Even if we have 100% faith in the integrity of the the teams behind applications like these, how can we be sure they have not been coerced by anyone to alter the running/downloadable version of their program to create a backdoor for example?

Thank you for your help with this important issue.

Note: Since this question concerns interpreted programs, the conversation on deterministic or reproducible builds did not seem to apply and seemed worth a new question.

While it is not possible to do so at run time, applications can be verified at load time (FIPS compliant OpenSSL does so).

  Said another way, is there a way to ensure that the commands/code executed by such a program are all and only the commands and code specified in a publicly disclosed repository?

Possible but not the way that you imagine. One of the requirements of a trusted software is that it needs to be verifiable. It can be verified either manually or using static analysis. If a code is not verifiable, then you can't really ensure that the code that you are running is actually the code that you see in a repository.

When a library is loaded into the memory, you can run it's signature against a known good signature of the library and ensure that the library that is loaded is indeed the one that you got from a repository.

How do we verify?
Well, there was a time when the verification was done manually by code review and generating all possible test cases but as systems grow larger, this becomes more and more difficult. There are several static analysis tools available that ensure that a source code doesn't have any possible program flow that will cause a failure or an unexpected scenario. (Coverity has a free static analysis service for Open Source projects).
Once we have ensured that the code cannot be misused at run time, our job will be to ensure that it is not tampered with in our machine.

How do we ensure that it is not tampered?
There is a concept of secure boot. What it does is that every time a module is loaded, it verifies the signature of the module against a known good value and if it is fine, then it lets the boot to continue otherwise the boot fails. Similar concept is used over here. When a program is loaded, we compare the hash of the loaded module against a known good value and ensure that it is indeed the program that we received.

This way, ensuring that the program cannot be misused at run time and then ensuring that a known good program is loaded, we get an assurance that the program is indeed what we want.


How to securely communicate with radio controlled device? Let's say I have a drone that is controlled through radio and I would like to make sure that nobody else can control and gain data from it except for me.

I could encrypt the data with a cipher and only send encrypted data back and forth, which solves the problem of securing data. It does not however help me with controlling my drone. For example, if I tell my drone to move to the right, couldn't someone else intercept that command and execute it again at an undesirable moment by just resending the exact same data?

How can I prevent this? Also, will this solution still be valid with a not insignificant amount of packet loss?

There are commonly two methods of controlling drones. Radio receivers and data transceivers (traditionally telemetry links). This really varies by device, autopilot hardware, etc. Some even use WiFi for everything. Receivers typically are receive-only, and convert received signals into PPM or PWM signals to speed controllers, servos, etc. Transceivers typically convert data into serial or possibly connect to another data bus such as I²C.

But let's say you have a traditional drone with both a receiver and a telemetry radio to the autopilot, you may need to address security of both. You mention encryption, and this provides confidentiality, but I think what you're really after is authentication. How can you ensure the radio sending the commands is really yours?

Radio receivers typically use a pairing method, similar to a garage door, where a key or sequence is exchanged prior to use. In this way, a transmitter (handheld unit by the pilot) is paired to a receiver or multiple receivers in the drone. There are a number of ways this pairing is accomplished, you can look at the source code of Deviation which supports many protocols and pairing methods. These are frequently vulnerable to replay attacks.

Transceivers come in all sorts of configurations. In the past, many used FHSS to "secure" the communication. More realistically, FHSS provides interference avoidance. Some proof of concept take-over methods have been demonstrated. Some common sense things here to protect the radio communication would be using a mutually authenticated protocol such as TLS. Each protocol will require their own solution, but I would focus on authentication, and that likely involves encryption to achieve. Certainly a pre-shared key may meet your solution.

However, there is little you can do to avoid interference and should have some failsafe for when communication is lost or significant interference occurs. Receivers typically need very little bandwidth, and frequently many receivers can operate in the same space safely. So even with unintended interference, it may not be a problem. Data transceivers and WiFi-based units will be much more susceptible to interference and at risk with dropped communications.


How can I prevent viruses/malware from infecting my flash drive? I've a pen drive that I carry to the college lab . It seems all the systems in lab is infected.  I need to be able to write to the drive, so I can't simply write protect it.

Everytime I insert a pendrive , all the folders became an .exe file . Also several other issues . After I scan with avast , everything is cleaned and all my data is lost..

Instead of an Antivirus tool or utility that runs only on prompt , is there a program/software that will guard the pendrive by running as a background process  automatically when inserted ?

( I should have the software in my pendrive )

Many suggest Clamwin portable, Panda Vaccinate etc....

I have a couple of questions here:

Are the files fine when in the lab?
And only become 'infected' when you
move them to your USB drive?
Are you certain the USB stick is clean?
Does the USB stick have software on it which is supposed to write files as exe's (some versions do this if encryption is enabled)

The reason I ask is that it could be an issue you are bringing to the lab.

If not, and the lab machines are infected, there is nothing you can realistically do with your USB drive to combat this problem. You would need to get the lab techs to sort out the issue at their end.


How do hackers find the IP address of devices? I've been watching Defcon videos recently (in no way am I a hacker myself) and saw a video of someone demonstrating a security camera hack. For this hack you needed to know the IP address of the camera but there is no obvious way on how to do it. With devices like Phones and Computers it's easy to get the IP but it seems to be a little harder with other devices.

Connecting 'things' to the Internet is becoming common because of the benefits of remote communication. You can have your camera upload its footage to a cloud storage server, or be able to view the camera remotely, for instance.

Any device on the Internet is exposed and subject to network mapping. The entire Internet is constantly being scanned, and once an IP is identified, there are processes that attempt to determine what the IP is connected to (web server, camera, fridge, your dog, etc.) From there, attackers (or researchers) can probe those devices for weaknesses and vulnerabilities (or default passwords).

To help out the attackers and researchers, databases of these IP-to-thing mappings are maintained (Shodan, for instance). Then it is trivial to simply search for "security camera Acme Security model xyz123" and apply a specific hack (as you witnessed).


Information Security is becoming more important, but why is it still so difficult to start off in? For example i have seen countless speachess by the UK goverment on how likely a cyber attack is, if so why do they not offer more incentives for new security professionals.

I find it frustrating as a graduate that my road into InfoSec has been so hard, yet the goverment says there are not enough security professionals. Is there a specific reason for this?

NOTE:
I have a BSc in Computer Science that was focused around the foundations of security. I can pretty much get into any other field as most provide further training. Yet even though I am a moldable graduate, its near to impossible to get my foot in the door in any security field, due to my lack of experience.

In tackling your points separately:

There is a very active initiative, sponsored by the British government specifically to get young people into the security industry: https://cybersecuritychallenge.org.uk/
Organisations are crying out for hires at all levels, from new graduates to experienced professionals. The job boards are full of them. So are you looking in the right places? People hiring include the Big 4 accountancy firms (EY, PwC, KMPG, Deloitte) Pen Test companies and boutiques, as well as end user organisations such as banks.

If you are being turned down for roles, have you had your CV assessed? I often find new graduates have CV's which are very academic - and that turns off many employers.

Are you a member of IISP, ISACA, ISSA or ISC2? Joining one of these is a useful addition to your CV at your stage.

Have you looked at courses? Or getting a cert like CISSP? These will help get you past the HR firewall.

Look at the other questions tagged professional-education for more info.

I give quite a few talks to universities on career planning. One of my recent ones at Napier University in Edinburgh was videoed as part of an IISP event.


How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy? I'm working on one client's network where they have enabled HTTPS authority spoofing on their proxy.  This allows them to effectively perform a man-in-the-middle attack to decipher all outgoing encrypted traffic.

When I connect to an HTTPS site, my browser gets a certificate for the site which has been signed by the company's proxy - not the real certificate.  Chrome and Internet Explorer say the website is secured (everything's green, no warnings) but Firefox says it's not.  I know, given the SSL proxy is in place, that it isn't.

I guess that Chrome and IE accept the spoofed certificate because the proxy's certificate is deployed by the GPO.  So, when the proxy sends a spoofed certificate (signed by itself) for a website, Chrome and IE show it as valid.

How can someone be expected to browse securely in this environment?  With all certificates being signed by the proxy, how can I validate that the website isn't additionally being spoofed by some other third-party?  I'm worried that there might come a time where Firefox is also configured to ignore these spoofed certificates.  How can I prevent my browsers (Firefox, et. al.) from accepting these certificates?

Why do browsers allow this function?  It would seem almost more sensible to completely disable HTTPS than to allow such a false sense of security as this.  Is this not a major security issue - that the browser accepts seemingly-legitimate certificates even though they are not the ones provided by the websites?

How can someone be expected to browse securely in this environment?

You can't really. If there's an official MITM proxy and it's not your network, just don't do anything you don't want the network admins to be able to see. Use your own personal connection to connect to sites with personal accounts.

  With all certificates being signed by the proxy, how can I validate
  that the website isn't additionally being spoofed by some other
  third-party?

I think it's fair to assume that the proxy itself, when it makes the connection to the actual website, does check the validity of the certificate against a list of CAs it was configured with (probably that of the OS it's running on).

  I'm worried that there might come a time where Firefox is also
  configured to ignore these spoofed certificates. How can I prevent my
  browsers (Firefox, et. al.) from accepting these certificates?

The trend has always been to increase the awareness about invalid certificates in Firefox.

In Firefox, you can disable certain CAs by going into Options -> Advanced -> Encryption -> View Certificates -> Authorities. Then, use "Edit trust" (or delete a CA cert). You're likely to find the CA cert installed within this institution. You can also review the exceptions in the "Servers" tab, if any.

  Why do browsers allow this function? It would seem almost more
  sensible to completely disable HTTPS than to allow such a false sense
  of security as this. Is this not a major security issue - that the
  browser accepts seemingly-legitimate certificates even though they are
  not the ones provided by the websites?

You're misunderstanding whose responsibility it is to ensure trust. Browsers are just there to use a list of trusted anchors. Whilst they often come with a default list, it's up to the machine's administrator (and/or the user) to check for the list of CAs they want to trust. (There's a slight exception to this with EV certificates, although it's not without its own set of problems.)

If you have a doubt regarding which CA is being use, click on the lock icon or blue/green bar (depending on the browser), you should be able to see the security details. Compare it with what you see using a machine you trust on a network you trust.

If you don't trust which CA certs are installed on the machine, don't use it. More generally, this boils down to this: don't use a machine you don't trust.


Password hashing that is resistant to ASIC-assisted cracking without risking DoS of server Previously, authentication systems stored passwords in cleartext. This made it trivial for an attacker to log in to an account if he had access to a leaked password file.

Later, passwords were hashed once and the hashed value stored. If the attacker had a leaked password file he could try hashing guesses and if a hash value matched, use that guess to login.

Then passwords were salted and hashed thousands of times on the server and the salt and the resulting hash value was stored. If the attacker had a leaked password file he could use specialized ASICs to hash guesses and if a guess matched use that password to login.

Can we do better than that?

Can we make password cracking so difficult that even if he has the hashed password, he will not get a major advantage (factor of 10) over testing the passwords against the server - even if he has specialized ASICs? And can we avoid this opening an way of DoS'ing the server with many parallel login requests?

We can assume the attacker has access to the hashed password, but that he cannot intercept communication between the server and a client.

There are a few things that can be done, and are done.

One approach is to leverage TPM to create a secret that the server cannot (theoretically) leak.  This secret is used upon the password during the hashing process (I believe the term for this is a "pepper," as opposed to a "salt" which is considered public information).  The offline attacker could beat on this password file as long as they like, but unless they can guess the server's secret stored in a TPM module, they don't have anything to break.  Obviously this can be done with any sort of secret, but I point out TPM because that tends to rely on hardware solutions to provide security for these numbers, and that can make it harder to leak the secrets than losing a password file.  This is highly related to the issues the FBI has publicly had when trying to unlock iPhones.  The information they need is locked away in a chip that is intentionally difficult to get into.

The other approach is to make ASICs inefficient.  The power of ASICs is typically that they can do a massively parallel attack on the password file.  You can design the hashing process to consume a large amount of resources which are expensive to parallelize.  There are hashing algorithms out there designed to do this.  One common approach is to have a very memory intensive hashing routine, forcing the ASIC designer to expend large amounts of chip real estate on banks of memory.

Fundamentally, though, if the attacker can get two computers which are equivalent to your server, they can attack it twice as fast offline.  This is a simple information theoretic reality.  However, these approaches make it difficult to get an "equivalent" to your server.  One approach does so by creating a hard to duplicate secret.  The other approach does so by using algorithms that are not trivially parallelizable in hardware.

In response to your comment about your self answer, if you involve the client and have them do the calculations for you, some interesting solutions become options.  Consider looking at zero knowledge proofs.  They are designed to reveal that you know a number (or password) without revealing any information other than that you know the number.  If the server queries the client using one of these zero knowledge protocols to ascertain whether the client knows the password or not, the server doesn't need to know anything about the password at all, so there is no passwords file to leak.  At most, there would just be a database of data structures to use in the zero knowledge protocol, which are mathematically proven to contain no information about the password (or at least statistically nothing).  An attacker who acquires this file would be able to verify that a client that connects to them(!) is a valid client, but could not crack the password any better than you could -- which is not at all.


Opera browser: no master password? I've recently moved from Firefox to Opera (for performance issues).

I used to protect my passwords in Firefox with a Master Password. But Opera, so it appears, lacks such feature.

I use Debian 9.7 and Windows 10 and intend to use Opera in both. And I am not worried about someone accessing my machine running and unlocked. It would be more a case of the laptop getting astray, but disconnected.

If someone accessed my computer using a live-CD, would he be able to access passwords saved by Opera? Is Opera safe regarding saved passwords?

By default, your passwords are encrypted using your Opera credentials. Only encrypted password information is stored on Opera’s server and delivered to your devices. Opera uses your account credentials to decrypt passwords when you sign into your account on your other devices. When Opera receives and decrypts synced passwords, they are stored in your computer’s Keychain.

Official Source

Locally, Opera can save encrypted passwords using your OS login data and therefore they can not be read in a different device or by a different user, so no, live-CD will not access them, unless a password recovery is performed vs. the account using them.