What type of encryption/encoding is this? (Linux) I've been struggling with encrypting this hash for a school homework.
(Backstory) I had to gain access from my Kali Linux machine to an "unknown" Linux machine and I've done it, but now I have to basically get the username and password of the unknown Linux machine. I located the passwords file "/etc/shadow" and I nano'd the file to see the passwords and this came up:

The password that I need is for root, so I'm guessing it's this one?

root: $1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.

If you're able to decrypt it, can you please explain how you did it and what type of encryption it is?

To quote Wikipedia:

  $id$salt$hashed", the printable form of a password hash as produced by
  crypt (C), where "$id" is the algorithm used.

  $1$ – MD5

So in your example $1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.

1 means it's an MD5 hash,

avpfBJ1 is the salt, and

x0z8w5UF9Iv./DR9E9Lid. is the password hash

You cannot decrypt a password hash; you can only brute-force it by hashing a large number of potential passwords and hoping you find a match.


Is DNSSEC immune to stripping signatures? In my opinion, it should be possible to forge DNS reply so it doesn't include DS/RRSIG/... parts for any request, thus bypassing DNSSEC validation of resolved domain.

Is DNSSEC system immune to this kind of attack?
Does Unbound with locally stored DLV and ROOT anchor files make any difference?

Yes, DNSSEC is immune to this kind of attack. Starting at an anchor (usually the root, sometimes DLV), every delegation is either explicitly secure (presence of DS set on delegation):

powerdns.com.       172800  IN  NS  powerdnssec1.ds9a.nl.
powerdns.com.       172800  IN  NS  powerdnssec2.ds9a.nl.
powerdns.com.       86400   IN  DS  44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com.       86400   IN  DS  44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com.       86400   IN  DS  44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279

or explicitly insecure (NSEC[3] bitmap proves absence of DS on delegation):

gov-1l.us.      7200    IN  NS  HNS1.BEYONDHOSTING.NET.
gov-1l.us.      7200    IN  NS  HNS2.BEYONDHOSTING.NET.
gov-1l.us.      86400   IN  NSEC    GOV-ABUSE.us. NS RRSIG NSEC

or implicitly insecure (NSEC3 opt-out):

stackexchange.com.  172800  IN  NS  brad.ns.cloudflare.com.
stackexchange.com.  172800  IN  NS  roxy.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
4OTDAP6T1E8VS8BHMCK8CDHSGE3GCOBM.com. 86400 IN NSEC3 1 1 0 - 4OTJJUP7OGM6C149HPOE7O9M1L9LS1OP NS DS RRSIG

(stackexchange.com hashes to 4otjehvpu9q5tm1d5v0ec302rcbll9um which is covered by the second denial, thus there is no secure delegation).

In all of these cases, IF there is a secure delegation, the NSEC[3] record for the name in question will prove the presence of DS. Thus, if signatures are stripped, a validating client can detect this.

For further reading, I highly recommend RFC7129: Authenticated Denial of Existence in the DNS and section 5.2 (Authenticating Referrals) of RFC4035 (Protocol Modifications for the DNS Security Extensions)


Any reason not to use same key for multiple SSL domains on one server? Assume I've generated a server key for use by Apache for SSL. The server will be handling several different domains that use SSL via unique IPs (no SNI).

I want to generate a CSR for each domain from the same key, get it signed, and then configure each domain to present the appropriate certificate.

Is there any reason I should generate a server key for each domain instead of doing this, if all domains will be hosted on the same server?

I can see two primary reasons why you might not want to re-use the same key:

Compromise resilience: If the private key gets leaked, and if you've re-used it for multiple domains, then multiple domains will be affected.  If you use separate private keys and store each on a separate server, then compromise of one doesn't affect the others.  If you're planning to host all the domains on a single server, this probably doesn't matter -- but using separate keys may preserve your flexibility to change the hosting details.

Future-proofing: Suppose one day in the future the owner of one of the domains says "I'd like to start hosting the domain myself; can you please give me the cert and private key for that domain?"  If you've reused the same private key for multiple domains, you cannot oblige them.
Or similarly, maybe one day one of these domains will become highly popular, and you'll want to buy multiple servers to host it and start load-balancing across them.  If you've re-used the same private key, then all of those servers need to receive the common private key, and if any of the servers is compromised, all the domains are hosed.  On the other hand, if you use separate private keys, then you can give each of those new servers a copy of just the private key for the one domain that became very popular.

These considerations may or may not matter in your particular situation.  You can decide for yourself the convenience benefits of having a single private key, vs. the flexibility for the future of having multipel private keys.


Browsing on a USB OS (Linux) safe from malware? Let's say I have a computer. It's a personal computer - the one you'd typically find in homes. In this scenario, it's running Windows XP SP3, although it could run 7, Vista, etc.

I have a USB drive which runs as a Linux Boot Disc - with something like Ubuntu, Puppy Linux, DSL...

If that USB OS is loaded into the RAM at boot, without any persistence (nothing is saved after each session), how possible (if at all) is it for malware to infect the main system (the Windows XP/Vista/7 system) that the USB OS is running off of?

Also, if a foreign computer is riddled with malware, is it safe to assume that booting the system to a USB OS will keep the USB OS safe from the Windows malware on the machine?

Thanks.

It all depends on the configuration of your OS, be it USB "stick-ed" or not.

If your live system enable you to write in one way or an other to the physical disk of your home computer, then there is a non null probability that the computer could get infected. Take for example a virus that would copy itself on the MBR of your main disk.

Concerning infection from the main computer to the live OS, it is not impossible too. The thing is that if the malware is a resident one, loaded when you read you disk, it won't be running on your live system because the boot sequence of the infected OS won't be run.
But if you have some latent viruses in your files and that virus would know how to target your live OS system, then opening this file with a vulnerable application (or executing it) can trigger infection of your live OS.

In conclusion, it's up to you to configure your OS to take the precautions needed to your operations. In fact, if you don't want to infect or get infected, the best thing to do is to disconnect the drives from the machine. If this is not an option, you would need to take care of the options on the live OS (read-only mode, no exec mode, no auto mounting of disks, running with the least privileges, ...)


Securely using JWTs with CSRF protection and refresh tokens I'm implementing JWTs in my app and I'd like to make them as secure as possible. I'll lay out everything I'm planning, I'd greatly appreciate any suggestions as to the security of this implementation. This is my site, I have full access to every aspect of it, both front-end and back-end.

This will be an SPA, using an API to access the back-end. I'm using JWTs to save DB calls with each API hit.

JWTs

JWTs are stored in an access_token cookie. They are first signed then encrypted using jose-jwt. Signing algorithm is HS256, encryption is DIR. They include the user's ID, an expiration exp claim, and several other custom claims. JWTs expire in 30 minutes, and the JWT cookie expires in 7 days.

(short version):

JWT stored in cookie
JWT includes user ID
JWT signed and then encrypted
JWT exp claim set to 30 minutes in the future
JWT cookie set to expire 7 days in the future

CSRF Protection

JWTs include a cst claim that stores a randomly-generated CSRF token. The CSRF token is sent in the response body upon login and when a new JWT is issued. The CSRF token is stored in the browser's localStorage. It is sent with every request and validated against the value in the JWT.

(short version):

JWT includes a randomly-generated CSRF token
CSRF token sent upon login and stored in localStorage
CSRF token sent in request header of all requests
Header CSRF token compared to CSRF token in the JWT

Refreshing Tokens

As the JWTs expire in 30 minutes, it is necessary to refresh them. The JWT includes an rfs claim that stores a random refresh token. This refresh token is also stored in the DB (a separate table from users to allow for multiple sessions). If the JWT is expired (based on its exp claim), the DB is checked to ensure the user is still valid (e.g. account not deleted, password not changed, etc.). If the user is valid, the refresh token is verified and a new JWT/CSRF token are generated and passed back in the response. If the user is invalid, the access_token is sent back with an arbitrary value like 0, and its expiration is set to the past so the browser will clear it. The CSRF token is passed back empty so it will be cleared from localStorage. All refresh tokens for the user are cleared from the DB.

(short version):

If JWT expired, check user DB to verify user is still valid
IF VALID:

Compare refresh token with DB (assume it matches for the rest of this)
Generate new refresh token, overwrite previous value in DB
Reissue JWT with new exp date
Pass refresh token back and store in localStorage

IF INVALID:

Clear JWT cookie by a) setting to invalid value, b) setting expiration to past
Tell browser to clear localStorage CSRF token
Clear all refresh tokens for user from DB

Quick and dirty TL;DR

Upon login, add a random CSRF token to the JWT.
Send that same CSRF token back to the client in the response body.
Store the CSRF token in localStorage.
Include a refresh token in the JWT.
Set the JWT cookie to expire after 1 week.
Set the JWT exp claim to 30 minutes.
If JWT claim is expired, verify refresh token against DB to ensure user is still valid.
IF USER VALID:

Issue updated JWT with new CSRF token and new refresh token.
Set expiration of JWT cookie to one week in the future. (reissue the cookie, basically)
Send new CSRF token in body of response, overwrite existing localStorage value.

IF USER INVALID:

Return JWT cookie with the same name but no content.
Set cookie expiration to an arbitrary date in the past.
Tell browser to clear the localStorage value.

You seem to be mixing up several different opposing technologies, and do not make it clear why you have chosen these technologies and why they control the threats you are trying to secure against.

  JWTs are stored in an access_token cookie. They are first signed then
  encrypted using jose-jwt.

Is there any reason why they are encrypted? Signing is used when you want to verify the integrity of the data - i.e. that it has not been altered by anyone without the key. Encryption is used when you want to protect the confidentiality of the data - i.e. that it cannot be read by anyone without the key. If there is nothing in the token that shouldn't be able to be read by the end-user then there is no reason to encrypt.

  JWTs include a cst claim that stores a randomly-generated CSRF token.
  The CSRF token is sent in the response body upon login and when a new
  JWT is issued. The CSRF token is stored in the browser's localStorage.
  It is sent with every request and validated against the value in the
  JWT.

This sounds like an implementation of the Double Submit Cookie CSRF control. localStorage is protected by the Same Origin Policy preventing another web session in the user's browser from accessing the token.

Ensure that the CSRF token has at least 128 bits of entropy.

  As the JWTs expire in 30 minutes, it is necessary to refresh them. The
  JWT includes an rfs claim that stores a random refresh token. This
  refresh token is also stored in the DB (a separate table from users to
  allow for multiple sessions). If the JWT is expired (based on its exp
  claim), the DB is checked to ensure the user is still valid (e.g.
  account not deleted, password not changed, etc.). If the user is
  valid, the refresh token is verified and a new JWT/CSRF token are
  generated and passed back in the response.

This is where things get mixed up. Your security model should decide on either client-side sessions or server-side sessions. JWTs are usually employed for the former. That is, if you have a token in the client signed by a key only available to the server then your application should be trusting that the presence of this token denotes a valid session should it not have expired and that the signature is valid.

The disadvantage of this method is that it is difficult to revoke tokens. If a user account is compromised, and a user changes their password, any attacker sessions will still be active for 30 minutes because they still have a valid, unexpired and signed token.

The fix for this is to implement server-side sessions instead. For example, you keep track of sessions in a database table which means they can be instantly logged out of by removing the row in the database. The session token can be a 128 bit entropy random string, supplied as a cookie client-side and stored hashed with SHA-256 server-side to mitigate any data leakage from your database. You could always send a plain text expiry date with your cookie, so the client knows that when it needs to refresh the token. e.g. a HttpOnly cookie for the token, and a non-HttpOnly cookie containing the expiry so the client-side JavaScript can read it. HttpOnly cookies can help mitigate the impact of an XSS flaw.

Therefore, if you are tracking sessions server-side there is little advantage of having a signed JWT client-side. Extra code means more attack surface and more chance of vulnerabilities being introduced into the surplus code. Complexity in an application is often inverse to security.

If you are using Double Submit Cookie in combination with a server-side session for session state, then you are wise to use a different cookie for the CSRF token. This will enable you to add the CSRF token as a header using client-side code without risking your session identifier token. Note that if you are setting custom headers and not implementing CORS, then this can mitigate CSRF somewhat. It is recommended to use a token as well though, because technologies like Flash tend to disrupt browser security (Flash means more code running, more code gives more attack surface, more code means more chance of vulnerabilities).


Is this VM-sandbox idea a good idea for testing viruses? You want to look at some viruses, so you use something like VirtualBox to create a sandbox environment. But what if we change that environment? What if we do:
STEP ONE: Create a bootable flash drive/hard drive with a Linux distro on it,  denied the bootable flash drive/hard drive permission to access the main hard drive, and denied the main hard drive access to the bootable flash drive/hard drive. In other words, don't let the main installed hard drive and the bootable to talk and write to each other.
STEP TWO: install VirtualBox and create a sandbox with it in the Linux distro on the bootable flash drive/hard drive and don't connect it to the network at all.
Is this a safe way to run a virus to analyze it? It like a OS in a virtual machine in a OS in a bootable flash drive/hard drive in your computer? Will it work because the bootable device will be cleared when rebooted?

These are good ideas but ensuring the system in Step One is not writeable may be a challenge.

Other things you may want to consider is the potential risk of a BIOS infection to the hypervisor host on the off-chance you are dealing with something advanced.

Similarly all connected devices may be vectors for infection think about BAD USB infecting all shared USB devices. I would have a concern about this in your setup more than anything.

https://srlabs.de/badusb/

An alternative might be to dedicate a computer to this task and leverage bootable CD/DVD's for your base OS and have no hard-drive at all. Then use a second dedicated CD/DVD drive to import data to be analyzed via CD/DVD-rw disks. Optionally you may need to treat these as dirty unless you can forensically wipe them.

Again, I think you have a good idea but I would seriously consider the long-term risks of a BIOS infection as well as potential data bus infections to things like USB devices, Firewire, Thunderbolt, etc...

Obviously you want no network connection here either and if possible no wireless connections including things like bluetooth. You want to think of this more as a forensically-sound workstation if possible.

Finally you may also want to have a fake virtual network connection so the machine doesn't appear to look like a forensic workstation to the malware.

Note: I think you can do all this very inexpensively so you may be able to try a few different methods until you find what works best for you but that said I do think you have a good idea for basic stuff I would just take into consideration the issues I mentioned above.


Is using SHA-512 for storing passwords tolerable? I know that the best options to use for storing passwords are bcrypt/PBKDF2/scrypt.

However, suppose you have to audit a system and it uses SHA-512 with salt. Is that "fine"? Or it is a vulnerability that must be addressed, even thought your site is a discussion forum?

Of course, if it is weak, it must be addressed, because users passwords may be used on other sites as well. The question is - is it too weak not to tolerate it as a possibility.

No, you're solving the wrong problem.

Moving from SHA-1 or SHA-256 to SHA-512 doesn't make cracking the hash significantly harder. Hashes generally aren't reversed by means of some mathematical property of the algorithm, so advancing the algorithm doesn't changing the security very much.

Instead, hashes are brute-forced using a "guess and check" technique. You guess a password, compute the hash, and then check to see if you guessed correctly. And repeat, and repeat, and repeat until you finally get it.

So the way to slow down the attacker is to slow down the hashing process. If it takes longer to check each single password, then the attacker can't guess as many of them. And in this case, SHA-512 isn't appreciably slower than SHA-256 or SHA-1 or MD5. So you're not really adding any security.

Instead, the common thread between techniques like bcrypt, PBKDF2, and scrypt, is that they all run the hashing function over and over and over, thousands of times for just one single password guess. So say a site uses PBKDF2 at 10,000 iterations: this means that the attacker has to expend as much time and resources on a single guess as he otherwise would have to on an entire dictionary of 10,000 passwords. By slowing the attacker, you limit the number of passwords he ultimately can guess, and therefore decrease the likelihood of him eventually guessing correctly.

Many installations tailor their configuration to fit existing hardware. So for example, LUKS uses a minimum of 1000 iterations, or however many it takes to consume 1/8th of a second, whichever is longer.


Why is a wildcard-subdomain callback URL in OAuth considered unsafe? In this post: http://technotes.iangreenleaf.com/posts/closing-another-nasty-security-hole-in-oauth.html

  Enter your full callback URL(s) in this field. This means you should
  be providing the entire path, such as
  https://mysite.com/oauth/callback. Do not use wildcards, and do not
  use only the domain.

The post calls out that wildcards aren't safe.

Later, the post offers an example that only shows a vulnerability of an arbitrary callback URL.

I wonder why a callback like https://*.mysite.com/oauth/callback would be unsafe. It seems none of the OAuth provider supports it (e.g. Google and Facebook).

Thank you.

There are more reasons why this is unsafe:

OAuth can be redirected to any subdomain under wildcard potencial leak token and so on
Example: If you have just some subdomain and don't own the whole wildcard then the attacker can register other subdomain and make real good phishing attack like login page or serve malicious webpage
Each token issued this way will be cross wildcard origin (I don't know how many apps do you have under this wildcard)
If you have ssl just for some subdomain user wildcard the MitM attack is easy as I can redirect to non HTTPS web service of yours and obtain token and login as that user
Depending on OAuths providers implementation and yours if you have SSL for *.example.com the attacker can still use ..example.com to MitM attack the enduser as the DNS takes this but the. Sure if the OAuth doesn't validate if subdomain of subdomain

Related question: Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?


Use bidirectional SSL with CAC from phone Is it possible to extract the certificate from a CAC (DOD common access card) and install it on a phone so that access to websites using bidirectional SSL can be done from a user phone.  Ideally, the certificate would still be protected by a PIN/passphrase.  Initially interested in Android phones.

The CAC seems to be a typical smartcard where the private key is stored on the card itself and crypto operations involving the private key like signing are also done on the card. Such smartcards do not allow extraction of the private key. In fact, that is the main purpose of these cards that any use of the private key should explicitly require physical possession of the smartcard.

In other words: you will not be able to extract the necessary secrets (private key of the certificate) from the card so that you can use these to authenticate yourself without the physical card being involved.


Outlook service is storing decrypted password in server memory – how insecure is it? I am evaluating the possibility of using Outlook mobile client with an on-premise Exchange 2013 server. However it seems that the app sends quite a bit of data to Microsoft's cloud servers. It also stores users' decrypted passwords in the cloud server memory. From the TechNet article:

  After the Outlook service has decrypted the password at runtime, the service can then connect to the Exchange server to synchronize mail, calendar, and other mailbox data. As long as the user continues to open and use Outlook periodically, the Outlook cservice [sic] will keep a copy of the user's decrypted password in memory to keep the connection to the Exchange server active.

This bit worries me in particular, but I'm not sure why. Can somebody please explain whether this is a big security risk? Is Microsoft's design acceptable, or bad enough to abandon the idea of using Outlook for mobile? Which factors should I consider?

I believe it is fairly standard to keep secrets in memory. Why it is generally better not to store passwords themselves, but rather use tokens/keys, it is not too bad IMO. The app has to store some kind of authentication token/key anyway, so by not using password, the only gain would be that an attacker capable of obtaining said key/token would loose access after the key/token were changed (you logged out). Because they would still be able to access your current and old mail at least until you logged out/had to type password again, this would be of little comfort.


access to mounted luks partition by non-root user Recently I searched substitute for truecrypt and played a bit with cryptsetup. The steps I did:

mkfs -t ext4 /dev/sdb1
sudo cryptsetup open --type luks /dev/sdb1 enc_vol
sudo mount /dev/mapper/enc_vol /mnt

After that I (non-root user) can chdir to /mnt and can see files but can't write anything there. Only root can write, but that is very inconvenient for me. As ls -l /dev/mapper/enc_vol shows it is symlink owned by root and which points to /dev/dm-1.

Commands like chown "username":"username" and chmod 777 cannot change "root"ness of the beforementioned symlink to /dev/dm-1.

My question: how can I mount LUKS partitions encrypted by cryptsetup to be able to write files in it being non-root user?

TLDR: Mount the filesystem in the user's home directory.

This is not specific to luks since it applies to mounting in general. I have not tested with ext4 but I don't see a reason why it will be different from ext3 (which I have tested).

sudo cryptsetup luksOpen /dev/sdb1 enc_vol
mkdir ~/enc_vol_mnt
sudo mount /dev/mapper/enc_vol ~/enc_vol_mnt

The regular user should now be able to read, write and delete files and directories in ~/enc_vol_mnt.

There are some other solutions to this problem on superuser.

As a side note, you can also use the -o users,rw,umask=0000 mount options when the file system being mounted is FAT or NTFS. The mount man page has more info on this.


What is a simple example of a trap door function? I was attempting to explain public key cryptography to a layman the other day which requires an explanation of a trap door function.  While I do know in principle what a trap door function is, I have to admit the specific mathematical properties behind the prime factorization problem and the ECC problem are beyond me.

Is there a simple example that can be used to exemplify a trap door function?  I was thinking of squares and square roots, since squares are easily computed but square roots, in a way, require guided brute force.

The most basic answer is simply factorization.  It's easy to compute the product of two prime numbers.  It would take a minute or two, but you can calculate on pen and paper that 1093*1039=1,135,627.  Going the other way is much harder.  If I just gave you the number 1,135,627 and asked you what two numbers I multiplied to get that number, it might take you hours of trial factorization with pen and paper to factor it.  To do it quickly you'd need a computer.

But if I asked you to factor 15, you'd quickly answer 5 and 3.  So the difficulty of factoring goes up as the primes go up in value.  If the two primes are chosen sufficiently large even a computer, or even thousands of computers aren't sufficient to arrive at the two factors.


Password Salts and Randomness Alright, so I understand that users are the kind of beasts who like to use one password and make it short and easy to remember (like "doggies"). If I understand correctly, that's one reason we use password salts. They add length and some level of randomness. My problem is how to generate them. The way I've been generating my salts (and the password hashes) in a recent (still entirely in-house) project is to do the following:

Grab the time in seconds since the epoch
Grab the time the process has been running (as granular as the OS allows)
Create the MD5 hash of both results above
Append the 4 strings I now have in a varying combination
Store this as plaintext
Append the password and salt in a few ways
SHA-512 hash that to create the password hash

Is this sufficiently random? Does it add enough entropy? I recently read I need a stronger hashing algorithm (looking at bcrypt) and need multiple hashes (1000+) to be safe enough, but that's not the focus of the question.

This seems misguided.

Time in seconds from any source lacks almost any entropy, and is almost immediately guessable. If your OS allows microsecond granularity for a running process, you'll get 4 or 5 bits of entropy there, from the lower bits, but a lot less if someone finds a way to get the exact system uptime.

You're then talking about MD5, which isn't really useful in this case. All it does it give you the impression that you've made it more random, without actually making it random. Really you've only got a couple of integers that are dependant on each other (process time is always going to be in sync with system uptime) and that are entirely non-random. Your system will almost certainly leak its uptime in one form or another. You'd actually be better off using an LCG like PHP's rand(), since the internal state can't be guessed as easily.

This approach to random number generation is bad, because it's not random at all, and can be predicted. However, salts don't actually need to be particularly random, they just need to be unique; they're only there to prevent rainbow table attacks. Unpredictability helps (see "how to store salt?") but isn't entirely required. Regardless, there are some benefits to making the salt difficult to predict.

If you're on Linux, read some bytes from /dev/urandom to generate the salt - you don't need to do anything more than take those bytes and use them, because they're already strong random numbers.

If not, you could generate the salt as SHA256(username || email || time || mt_rand()) where || denotes concatenation, time is the current system time in as high a resoluton as you can get, and mt_rand() is an output value from whatever random generator is available in your programming language's default library. In PHP you should use mt_rand rather than rand, since it has better characteristics. This provides enough entropy for a salt to be very difficult to guess remotely, especially given the limited opportunities for re-use of username and email combinations.

For storing the password, you should definitely be using PBKDF2 or bcrypt. A single use of a cryptographic hash function is simply not enough to protect you from bruteforce attacks, especially when almost everyone has an OpenCL-compatible GPU these days.


Decentralized e-commerce site, what to do about SSL/security? I'm building a service that is basically a decentralized Amazon.

Basically, each seller hosts a copy of the site, at their own IP address, and accepts (bitcoin) payments using a self-hosted bitcoin wallet that I made for this purpose.

My difficulty is this: I don't want to force every single one of these nodes to buy their own TLS certificates, but I still need the requests to be encrypted. Would self-signed certificates work for this situation?

If they wouldn't work, what options do I have?

From your description at this query at stackoverflow I get the information, that all customers will use their browsers to contact these sellers.

When you only use self-signed certificates or use your own CA for the sellers each of these customers must explicitly add an exception (or your CA) to their browser. And of course they should not just trust anybody claiming to be the seller, so they need a way to verify the certificate using an independent way before accepting the exception, like a written letter from you with the certificates fingerprint.

Of course this does not scale. Also lots of customers will probably refrain from using this service, because of all the hassle and the perceived (and maybe real) insecurity.


Solaris: IP Spoofing Across Ethernet Ports Given a Solaris machine with two network interfaces corresponding to the separate ethernet ports in the back.

0: 192.168.0.5/255.255.255.0
1: 192.168.1.5/255.255.255.0

with /etc/defaultrouter set to 192.168.0.1

If a connection (either TCP or UDP) comes in on port 0, but it is from 192.168.1.6 (obviously spoofed), does that mean that any responses (the SYN-ACK packet in the case of a TCP server, or the DNS response in case of a DNS server) will be sent out on port 1 (due to the IP address).

Or will they be dropped, or worse, will they be sent back out on port 0?

I am attempting to asses the risk of IP spoofing across physical interfaces. If a server listens on all interfaces, but only authorizes connections from 192.168.1.*, I want to know how likely it is that it will accept connections from the wrong port.

Hypothetical threat environment: port 1 is connected to trusted, non-internet network. Port 0's subnet might have a compromised machine on it.

Under Solaris, the ip_strict_dst_multihoming parameter will perform the anti-IP spoofing function you're looking for.  To quote, "by setting the parameter ip_strict_dst_multihoming to 0 the system drops any packets that appear to originate from a network attached to another interface "Solaris Kernel Tuning for Security".  So to answer your question: risk can be addressed by properly configuring the box not to forward spoofed packets.

Note that this addresses the simple case that you've outlined.  I don't think it will help in the case of routing multiple networks via multiple interfaces.  In other words, if you had a static route so that traffic for 192.168.2.0/24 was also routed over interface 1, then I'm not sure Solaris would drop a packet from 192.168.2.5 that came in on interface 0.  I think only the networks defined by interface 1's bound address will be dropped.

If you're looking on turning a Solaris box into a router, you should carefully read guides such as the link above.  Solaris is not, in my humble opinion, a great router system.  Solaris 11 did add the ipfw firewall, however, which brings closer to par with your average BSD/Linux box.  If you're going to route between networks of differing security levels, you should do it right and NAT and/or apply firewall rules.


detecting MITM attacker on WIFI I have read this: Can I detect a MITM attack? My question is very simple, since a MITM attacker consumes double number of packets, is possible to identify him, isn't it?

Technically, if the attacker is sitting between point (A: Your Device) and point (B: Server/ Another User/ ..etc). The attacker will be trying to sniff all the traffic between A and B in order to get access to sensitive information.

Now theoretically speaking, the attacker will be generating a larger amount of traffic since he is sniffing the traffic, maybe modifying it before relaying it to (B), on top of the network traffic it generates.

Now, just because of a attacker generates a large amount of traffic on your network, is not necessarily a correct indication that an MITM attack is taking place.  However, the device in question may be a likely candidate. Even then, it is not a valid indication.
Also, it is import to note that the attacker not necessarily needs to sniff of the traffic originating from (A), it is possible to regulate it, in this case, your hypothesis of double the traffic generating will fail.

I am not sure if you are understanding a MITM attack properly. Here is an Okayish guide that might be useful: https://www.wandera.com/mobile-security/man-in-the-middle/man-in-the-middle-attack/


Are encryption algorithms designed to hinder parallelization? Are things like large memory requirements and constantly mutable state typically added to encryption alogrithms to hinder the ability of attackers to try multiple candidate keys simultaneously?  Also, is an encryption algorithm being less parallelizable often touted as an advantage of that algorithm?

In the case of a know ciphertext attack (the most likely one) the attacker would have access to the cipher text. He can make any number of copies of the cipher text now and run his bruteforce attack with multiple keys in parallel if he so chooses to.

In fact when specifically speaking of Block Ciphers (in symmetric encryption) the block cipher itself does not dictate parallelization as it always works with just one block in fact the Block Cipher or Stream Cipher "Mode" that it used can decide if the algorithm can be run in parallel on a given multi-block cipher text. For example Output Feedback "Mode" can be run in parallel for encryption but Cipher Block Chaining cannot be run in parallel. Either of these modes can be used with AES or other block ciphers that support these modes.

When it comes to asymmetric encryption like RSA or even Diffie-Hellman the idea is to never encrypt anything more than a single block in size. They are typically used to simply encrypt a symmetric key to perform more intensive encryption. So parallelization is less of a concern here.


Biostar 2 data breach According to this blog post (which I assume is an accurate description of the breach):

https://www.vpnmentor.com/blog/report-biostar2-leak/

a large amount of very sensitive BioStar 2 biometric data has been leaked. I'm not familiar with BioStar 2 but I had been fingerprinted in some situations in the past and I'd like to know if there's a way to know if I'm affected by this or not.

(I don't know if this breach would only affect people who explicitly ordered some device or work in particular places (my work doesn't use fingerprint checks) or if this would affect people going through immigration checks when crossing borders, for example.)

Is there a way to learn if I'm impacted by this breach?

From the linked article:

  BioStar 2 is a web-based biometric security smart lock platform. A centralized application, it allows admins to control access to secure areas of facilities, manage user permissions, integrate with 3rd party security apps, and record activity logs.

It seems that unless you have access to somewhere that uses biometrics for that (and they used this software), you won't be affected.


How is "security word" safe from man in the middle attack? In this bank site I read the following lines

  Item #2 - You will also need to create a "Security Word". This allows you to verify that you have reached our Internet Banking site, and not some other site. Every time you attempt to log in to your accounts, we will send you a graphical representation of the Security Word that you created. If you do not see that Security Word or it is not the one you created then you know that you are NOT at OUR site. If this happens, please contact us immediately.

It says that bank displays the security word so that user can know that if he/she has reached the correct site, but I don't understand how it prevents man-in-middle attack.

The attacker can ask victim to enter the credentials, which then it can use to send REST back-end request to original bank site, which will return an html containing the security word of the victim, which can easily be parsed and can be shown on phishing site. So how does this security word actually help?

Long answer:
This type of security mechanism is not meant to protect against MitM: it's meant to protect against URL mimicry/spoofing/phishing. Example:

Users receive a spam message which looks like it's from "Legit Bank"
Spam message contains a link to "Update your information", hosted on a criminally-controlled server
Users enter their information, fooled by the convincing website

This security mechanism is meant to help end users verify that the site they're visiting is legitimate, without having to teach them the logic mechanisms behind how to identify phishing emails or spoofed/mimic URLs.

Additionally, the sophistication required for this kind of MitM would exceed the return from ordinary bank fraud. Simply put, if you're that good, it's not worth your time or risk to go after end-users.

Short answer: No, it doesn't protect against MitM.

Edited for brevity.


Reverse shell connections Why are reverse shell connections so popular in the event of a successful intrusion? Many "hacking" videos show this and it is often seen in practice.

Would not most servers restrict outgoing connections initiated by the server on an odd port? Would this not be a basic firewall rule?

Apparently not as this technique is used as it is more likely to bypass firewalls, what I don't understand is why.

According to my experience, many people concentrate on preventing attacks in the first place and not on mitigating the impact. Therefore outgoing firewalls rules are often not a priority. Especially since you have to define exceptions for update servers, if automatic updates are desired. The list of IP-adresses has to be kept uptodate.

In my experience it is way more common for attackers to try to upload phpshell/perlshell/etc. in file upload forms. The attacker hopes that the files are stored in a folder that is reachable via the webserver with script execution enabled. Or to inject php code and remote includes into request parameters. Furthermore SQL and XSS attacks are quite common, so is phishing. Of course my observations are biases by the areas I am active in: web application and online game security.

That being said, it is of course still a good idea to have outgoing firewall rules.


How to prevent Insecure Direct Object References? I've just gone through the video that presents "A4 Test Insecure DOR Change Secret" and even though I fully understand what the problem is, I don't know how to mitigate it. Can anyone give me an idea please how to avoid this threat?

Insecure Direct Object Reference is essentially a combination of two issues, in the most common case: enumerable identifiers used for externally exposed objects, and a lack of sufficient checking for access rights to those objects. The first of these isn't actually required, but makes detection of the issue harder (guessing a GUID, for example, is much harder than incrementing an integer).

Therefore, fixes ideally address both points. The application should verify that the current user has permission to access the object, every time access is attempted. If a user has access to record 3 and no others, any attempt to access record 4 should be rejected. Note that in some cases, just checking on read access is insufficient: if they can write to a record, even without being able to read it, it may allow further compromise. For example, if a PUT request made to /user/1 contains a password value, it is important to check that the same PUT request cannot be made to /user/2, even if it is known that GET /user/2 is rejected.

Secondly, object references can be modified to be user-specific. This can prevent exposing information which can be commercially sensitive: if your client id field is 1045, and you signed up to a site yesterday, you can make a pretty reasonable guess that there are unlikely to be more than 1050 clients. This could be exposed through profile screens at paths such as /profile/1045/edit, or through a parameter being passed in a POST request, among other ways. If, however,  the path was /profile/edit, and the client id was determined by the server based on the currently active user session, this information is not exposed.

Obviously, in some cases, this isn't an appropriate method: in a CRM system, multiple users need to be able to access the same records, for example, as well as being able to share them. In this case, there needs to be some way to reference them across user accounts. A hash of the object id would be one option, although this needs to be used in conjunction with access controls.

For things like permissions, however, there is no particular need for users to be able to share an identifier. It's more important that they can only set values which are appropriate to their user level. In this case, assigning a user specific identifier to those values which they should be able to access can prevent them even being aware of other values. By performing a server side mapping - 1:read only, 2:read-write for standard users, but 1:full control, 2:read only, 3:read-write, 4:delete for administrative users, say - and then processing that when the data is stored, standard users never even see that there are higher levels, and even if they did, would have no way to set them: attempting to copy an admin user's POST request setting the access level to 1 would result in it being set to read only, rather than full control.

It is important to note that without insufficient access controls, the amount of information exposed through direct object reference is limited: it might not matter than people can tell how many objects of a given type exist (e.g. Twitter uses (big) integers for tweets), and just preventing unauthorised users from accessing other objects is the important part. Direct object references can be appropriate in some cases, usually where there is a requirement to share a common identifier between users.


Intercepting AJAX request and response using BURP I would like to intercept an AJAX request using BURP. I have used BURP for web applications testing before. This, however, appears to be a weird case. I am not certain what am I missing here.

The situation is:

I have a web page, lets say:
http://www.example.com/forum/register.php.

Amongst the other fields on the REGISTRATION form on this page, there is an emailID text field. Due to some weird logic of the application, and I do not really care what, as and when I type out characters in this text filed it pulls up a drop down box with all the matching suggestions for that character.

  Example :
  Say I type in the character 'a', then some of the suggestions that get pulled up are like abc@yahoo.com, ana@gmail.com, aka@yahoo.com etc.

Note: This is not an autocomplete enabled field/form that is leading to these suggestions being pulled up, just in case you were wondering on those lines.

I checked the request in BURP and there is an ajax request being made, as suspected, for each character typed in the emailID text field.

So from BURP the request is of the form:

  GET /abcd/register.php?mod=ajax&inajax=yes&infloat=register&ajaxmenu=1&action=email_verify&email=allTheCharactersIEntered HTTP/1.1

  Host: www.example.com

Now although INTERCEPT is ON in BURP and I can see that the above GET Request is paused (intercepted) for me to modify and forward the request, actually the response has already been received and the suggestion box has already been populated with the respective suggestions as I can see that in the browser and also in the HTTP History tab in BURP.

What I want to achieve is that: every time I type in a single character in the emailID text box (that's when the ajax call is being made, from my understanding), before the response (the suggestion drop down box) is generated I should be able to intercept and make changes to the typed in character on the fly.

What is it that I am missing here? How do I achieve the above? Please feel free to ask something that does not make sense in the above scenario.

Are you intercepting all requests or just "in scope" requests? Could it be that the logic in the JavaScript code tries another domain if it does not get a timely response - one you are not intercepting.

Another possibility is that there's a client-side cache of responses that is accessed if a timeout elapses. Maybe Burp Intercept is causing the timeout so the application simply accesses its local storage.

Have a look at the application's client scripts to find out exactly how this works. Also examine the full proxy logs in Burp to check you are not missing any requests.


Safer way to access paypal, Mobile or Pc? I often find it difficult to chose if it is safer (in any context) to log in to my paypal, or other similar banking accounts using my Nokia or my PC.

Maybe, I am assuming the fact, that since I do have a lots downloaded stuff in my PC, it may contain a virus or not, even though I have anti virus, I rather tend to trust my mobile more often. I am thinking, since there may not be as much viruses made for mobiles or the fact I don't download anything in my mobile, that they are safer than PC while loggin in to sensitive places. I would like to know, if Mobiles phones, more specifically Nokia's are less vulnerable than your regular desktop.

There has been some questions about Nokia phones and how they handled SSL; namely, that up to recently the data was intercepted and decrypted on some servers owned by Nokia. While in this specific case they were probably doing it for the explicit purpose of adding compression and not at all for stealing cookies and passwords, this highlights the fact that a lot of things can occur within the guts of your mobile phone that you have very few ways of knowing about. Compared to that, a desktop PC is rather "open".

If you really worry about your PC, I suggest that, for bank-browsing, you reboot on a Linux LiveCD. Linux is rather robust against virus and malware, especially when used only for connections to "safe sites" and running off a read-only DVD.

One might notice that "rebooting off a DVD" is one of the things you can do with a PC and not with a smartphone.


Is it safe to type a password in a VNC client connected to a server to access another server? I am using VNC GUI client from my Desktop to connect to a remote (ubuntu) server, say S1. From the remote server (S1), I will be logging into another server (say S2) via SSH. Via VNC client, I will be typing in the SSH password of S2 on putty running on S1 to gain access to S2. Is this a safe way of doing things?

If the VNC connection is not encrypted, anyone on its path can capture and inspect the traffic. VNC uses the RFB Protocol (Remote Frame Buffer), and Wireshark, for example, already have dissectors for it, so don't count on it.
Some VNC solutions have proprietary plugins that add security (UltraVNC is one of those), but you don't need that. If you use a SSH tunnel to access S1, all traffic will be protected by SSH's encryption.
And I have way more trust on SSH doing encryption than a VNC solution.


Proving a forwarded email attachment was not modified There was an issue and my employer asked me to forward the email that I sent out to a client a few days prior. The email contained 3 PDF attachments and I immediately sent this to my manager. I am being accused of replacing one of the PDFs with an altered or new PDF file in the email that I sent to my manager.

Of course, I did not do this.

Is there any way to track the activity on my computer or help to prove my innocence? I've heard of "keystroke monitors" on servers but I don't believe my organization uses such monitoring.

We use a remote server and we do not have Microsoft Exchange.

Is there anyway to ... help to prove my innocence ...?

Ask your client to send an Email send the email to your employer, if you can.

In the future you can confirm that the Email is unchanged by automatically signing your Emails with SSL certificate. There are a lot of providers of affordable certificates. In the popular Email clients like MS Outlook there is functionality that allows you to automatically sign every Email you send. So you can at any time in the future show, that any of your Emails remains unchanged.


Can I use a private key as a public key and vice versa? I have code to encrypt data using a public key and decrypt it using a private key. This is useful when a client wants to send data to a server and know that only the server can decrypt it.

But say I want the server to encrypt data using the private key and decrypt it using the public key, as a way of distributing data that can be verified to have come from the right server. Rather than modify the code to allow this, can I simply publish the private key and keep the public key secret? Does this affect the security of the system?

But say I want the server to encrypt data using the private key and decrypt it using the public key, as a way of distributing data that can be verified to have come from the right server.

You can do this - this is, at a very simplistic level, how RSA signing works (note, simplistic - there is a bit more to it).

  Rather than modify the code to allow this, can I simply publish the private key and keep the public key secret? Does this affect the security of the system?

You don't need to publish the private key at all - RSA is a trapdoor permutation which means:

If you encrypt with a public key, you can decrypt with the private key.
If you encrypt with a private key, you can decrypt with a public key.

Thus, RSA supports doing both signing and encryption relying on the end user having only the public key.

In your case, if the client wishes to verify data came from the server, you apply the second case of RSA and decrypt the signature data using the public key you already have.

Furthermore, because it is a permutation, you shouldn't need to modify your code at all. Both keys should work using the same function. I would expect any decent crypto library would have APIs for verifying signatures according to the varying standards that exist - one of these would probably be a good bet.

RSA Labs provide a nice explanation of this.

If you want to extend this between servers, or verify client communication - generate keys for each entity and swap the public ones. The process can then be used at both ends.

Theoretically speaking, e and d are interchangeable (which is why RSA works)(one must be designated secret and kept secret) but p and q must always be kept secret as these allow you to derive d from e and vice versa. However, you need to be extremely careful in your understanding of the private key - does your software store p/q in the private key? If so, you can't publish it as is. Also, when I say interchangeable - once you publish one of that pair (e or d along with your modulus n) you must guard the other with your life. Practically speaking as Graeme linked to in the comments e is often chosed as a small/fixed value. My comment on e/d being interchangeable clearly does not apply when e is easily determined. Doing this sort of thing therefore has the potential for confusion and mis-implementation. Use a third-party library/don't start publishing private keys.


Self-signed certificates in embedded IoT device I have multiple IoT devices that will be connected to a cloud based platform in order to control these devices (IoT node running baremetal arm SoC).

These IoT nodes would be deployed and, during configuration, they would create a secure communication channel with backend generating a synmmetric key (one symmetric key per node). Once this symmetric key is generated and secure channel is created, there should not be a problem.

In order to avoid MITM attacks during configuration I would like to understand the implication and risks of using Station-to-Station protocol (STS).

This requires certificates for authentication.

Before key exchange using Diffie-Hellman, both endpoints should force to authenticate, this implies generating certificates for both endpoints.
For this specific scenario, the option of generating a certificate signed by a CA per IoT for a unique initial operation during IoT device configuration seems too expensive for the application (certificate management, pay for certificate loading services).

One alternative regarding certificate is the generation of a self-signed certificate per IoT device.
 This certificate will only be used during IoT device deployment, so is it really useful for this specific case?

Considering your self-signed certificate is unique per device (which is absolutely should be), then yes there's massive advantage to using these as opposed to plain text or a shared certificate. This raises the effort required to exploit the process which is the purpose of security features. Yes it can be defeated locally, but not in a repeatable way and certainly not against all deployed devices.

You could consider using certificate pinning on your code and validating the server connection in that way. There are issues with this due to firmware images being infrequently updated and servers invariably changing.

The effective solution to this is having factory provisioning of unique signed certificates I'm afraid. You may get away with using a self-signed CA if you also apply certificate pinning.

This is a huge and complex field and I am glad you are thinking of these implications. I work with a couple of absolute experts in the field and we get to see the bad, the ugly and the "don't even want to touch that".

Also plex did amazing things around using signed TLS certs on internal deployments. Yeah it's a tangent but pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/


how to specify pkcs#7 requirements for a third party you are exchanging data with? I am looking to use PKCS#7 to sign and encrypt data (offline batch data files) that are exchanged with a 3rd party.

I need to write an interface specification for the 3rd party so that they can decrypt and verify the signature, but I'm wondering what that interface spec should contain.

So far, I have:

A specification for the zip file that is to be signed/encrypted
A specification for the signing/encryption which looks like this:

Asymmetric key pair algorithm: e.g. RSA 2048 SHA 256
Data Encryption algorithm: e.g. AES 256 CBC
Signing Hash algorithm: e.g. SHA 256

Do I need to specify anything else for the 3rd party to be able to verify and decrypt the data?

EDIT:

The PKCS#7 CMS specification encapsulates the algorithms used so that the recipient has enough information to verify and decrypt the data.  In this respect, the sender does not need to specify the algorithms.

However, if you wish to use CMS to protect files that a third party is sending to you, then you will probably want to specify the minimum strengths of the algorithms that the sender may use to protect the data.

It looks like you asked a second similar question shortly after asking this question. However, the bounty is here, so I'll give it a shot!
In your other question, you mention that you're looking for confidentiality and non-repudiation as part of your file exchange scheme. This means that you're looking to send data from Alice to Bob such that Bob can verify that Alice (and only Alice) could have sent the file and Alice can verify that Bob (and only Bob) can read the contents. You're also, as far as I can tell, looking to send this data in a single package, so you only have to send one communication with all of the information required.
PKCS7 is an older format that's been largely wrapped up in the Cryptographic Message Syntax (CMS) format, which includes PKCS7 data, but also has many more features. This format is primarily used for sending encrypted email (S/MIME), but you could theoretically use it for your purposes. There are other formats for sending an encrypted package, e.g. using XML, that are standard in various contexts.
But this is overkill. Don't re-implement the wheel.
There are existing tools (e.g. these) that can do public-key file encryption and signing out of the box so that you don't have to risk implementing your own cryptosystem. If you can use GNU Privacy Guard (GPG) or another tool like it for this purpose, I would recommend doing that. I would be shocked if these tools couldn't output messages in CMS/PKCS-compatible formats.
If you need something more basic, OpenSSL is capable of encrypting and decrypting signed CMS content on the command line and via the library. There are plenty of examples if you search.
There are also a variety of answers here on Stack Exchange on this same topic, e.g. What's the standard way to encrypt a file with a public key in Java?:

One common, standard encryption format is Cryptographic Message Syntax (CMS, evolved from PKCS#7), and e.g. BouncyCastle supports it. It allows for signatures also, and is the basis, e.g., for S/MIME mail message security. It may be overkill, but is widely supported.
Example code is provided by Bouncy Castle. For CMS, see org.bouncycastle.cms.test, probably the Enveloped Data examples.
Another option is the XML Encryption format, standardized by W3C. For Java examples, see e.g. Exploring XML Encryption, Part 1 or do it with XSS4J: Implementing XML Encryption in Java

For non-repudiation purposes, there are established third-party services that provide timestamping services, along the lines of a notary public validating a paper document, if you need that. These are called Trusted Timestamp Authorities. This way, Bob can verify that Alice signed the document no later than the trusted timestamp, since the document was already signed and encrypted when timestamped by the TTA, and Alice cannot claim to have signed the document later. This could (IANAL) also allow a secure trace for court purposes, if, for instance, Alice and Bob are negotiating a contract and Bob needs to sue Alice later.
It's generally a bad idea, security-wise, for a non-expert to re-implement an cryptography standard. You could, and probably will, make a mistake, usually a protocol error, which would blow your system wide open. As Schneier says, it's trivial to create a crypto system that you yourself cannot break. Using a standard system also allows you to send your data to any recipient, who doesn't necessarily need to know your protocols and interfaces.
Cryptosystems like PGP, GPG, and OpenSSL have been around for two decades and have had the proverbial kitchen sink thrown at them. Security experts still depend on them. So use one of those, if possible.
If it's not possible to use existing libraries and systems (and there aren't very many situations where that would be the case - university homework is one of the few I can think of), you'll need to do at least the following:

Alice and Bob will each need a public and private keypair. When Alice sends a file to Bob, she will encrypt it using her private key and Bob's public key. This means that only Alice could have sent the file, and only Bob can decrypt the contents.
You will need a secure way to communicate keys from Alice to Bob, or at least to verify that the key you received is the key Bob sent. Ideally, you'll need to have your keys signed by a certificate authority like Verisign. If you can't, you'll need to use some kind of trusted out-of-band method of verifying your exchanged public keys. Otherwise, all you've got is a key that claims to be Bob's key.
Please please use a standard mechanism to generate your keys (e.g. OpenSSL).
Do not re-use a symmetric key. Ever. Similarly, don't re-use an initialization vector (IV) for your symmetric system. Ever.
If you need trusted timestamping, as mentioned above, using a trusted third-party service is one of the most reliable ways to accomplish this. You would send them your already-encrypted file, and they would return a package including a signed timestamp and hash of your encrypted blob. If you need this and can't use a third-party, you'll need to figure out a way of securely synchronizing timestamps with Bob before sending the document.
You'll need some way to keep your private keys safe. Using a keystore on the local machine means that your 2048-bit RSA keys are exactly as secure as the sum of your local system password and your keystore password. It's better to store keys in a dedicated crypto module, or perhaps a USB drive kept in a safe when not being used.
You can use a standard format like CMS to transmit your certificate data, or you can roll your own. I'd recommend going with standard formats whenever possible, since the recipient can then use standard tools for decryption.
You may want to consider using separate keys for signing the document vs. encrypting the document. In other words, Alice would have two keypairs - one used to encrypt the symmetric key and a second one used to encrypt the hash. Bob would need both corresponding public keys. The advantage is that you can then swap out your encryption keys on a regular basis without necessarily losing your non-repudiation. The disadvantage is that you'd have to securely communicate each new public key to Bob.

Please let me know if you need any further clarification. I cannot stress strongly enough that you should use an existing, tested, and accepted cryptography system if it's available for your purposes.


How to secure the cloud hosted web server safe from attack ? We have got a web server (Apache)  hosted externally. It has got multiple times attacks from the hackers (The Index file getting changed) even after getting  moved from another location also.

Kindly suggest.

Thanks in advance for all your suggestions.

With regards,
Sahu

Sahu,

As a baseline, please reference the NIST Special Publication 800-44 Version 2 Guidelines on Securing Public Web Servers.

Also, take a look at this post on securing Apache web servers.


it is possible to make a copy of an iPhone? Is it possible to make a copy (an image like iso or img) of an iPhone  supposing that we can only connect it to a computer?

Can I use the dd command to do this? Are any alternative ways to a clone an iPhone ?

a simple itunes backup actually backs everything up, down to the arrangement of apps on the home screens. to use the backup, you'd need another iphone to restore the backup to, that is capable of running the same version of iOS.
i would expect you'd need to know the passcode of the phone, to do the backup in the first place. it might also ask for the icloud password, on the cloned iphone. i can't remember.


BadUSB device functionality I would like to know if a BadUsb can simulate a real device or it just execute programmed functions and stop working. For example, if a "mouse" is a BadUsb, when I plug it in a PC, will it work like a real mouse and allow me to use it or will just execute programmed functions and don't work anymore?

Also, these functions are visible? For example, will a terminal always appears on screen or can the code execution be invisible?

A BadUSB device can simulate an HID (human-interface device) such as a mouse or keyboard without breaking functionality. Such a device could easily be made which both executes programmed functions and works as a real mouse. In fact, even a flash drive could do that, by pretending to be a USB hub. That would allow it to pretend to be two devices at once, behaving as a storage device and as a keyboard.

Although, in theory, the functions should be visible, there are numerous ways to execute code through an HID without any visible interactions in the screen. You can't rely on the lack of a terminal popping up with text appearing in it as an indicator that a malicious HID is not present.


If password is super long, your wpa / wpa2-psk is safe? sorry im kinda clueless with this stuff...
I heard if you set your wifi password to more than 10 or so digits (and make it complicated), then your wpa / wpa2 psk would be safe. Is that true?
If not, how do i make it secure so that i dont have to revert to Wired (=safe?)?
I just need it to be secure for one day at a time. (I mean I can keep resetting password if that helps)

If a password is strong, then it is strong. WPA2 uses PBKDF2 with 4096 iterations and the network SSID as salt to turn the password into the shared secret. This is not bad. This means that a "strong" password will be, in this case, a password with 68 bits of entropy or more: the 4096 iterations add 12 bits to the brute force effort, and I use the traditional "80 bits" as the threshold of attacker's power. Note that 280 is a lot, and an attacker who is interested in obtaining a free Internet access through your WiFi is unlikely to devote that much computing power to the effort. A weaker password in the 40-bit entropy range will already be strong enough to deter attackers.

This famous question discusses password generation and entropy. A password with 40 bits of entropy can still be compatible with a human brain.

Password derivation aside, there is no known weakness in WPA2, so you can say that with a strong password, WPA2/PSK is safe... within its functionality. Remember the following points:

WPA2 is about keeping outsiders outside. It prevents external attackers from joining the network, i.e. looking at existing traffic and inserting his own. However, WPA2 does not protect connected clients from each other.
Even without piercing the crypto layer, attackers will still be able to do some traffic analysis: they can track the client machines (their MAC addresses are visible) and get some idea of what they say based on the timing and size of each frame.
Attackers who just want to achieve wanton disruption can jam the traffic by simply emitting stronger radio waves at the same frequency; and they can do that remotely. To do the same with a wired network requires physical access to the wires. For instance, your neighbour can jam your WiFi without leaving his house, while breaking your wire network would require entering your home.


Reflected XSS in multiline script block I am trying to exploit a reflected cross site scripting in a GET request where the reflection is in the first multi line script block.

It seems I can use every character but <, > and " and the best payload I could come up with is
/?search='}]%3Balert(1)%3B%2F%2F

And it gets reflected like this:

<head><script>
  dataLayer = [{
    'pageType': 'Page',
    'category': 'Search',
    'searchTerm': ''}];alert(1);//',
    'searchResults': '0',
  }];
</script>

Unfortunately this does not work. Neither does it with /* instead of // to comment out the rest of the script block. Is there any way to make it work without using "<" and ">"? Now it fails with "SyntaxError: unexpected token: ':'"

You don't need to comment anything out.

Use:

/?search='-alert()-'

JS will attempt to create the search term string from the expression '' - alert() - '' which will trigger the alert function. I preferred - over + because it avoids potential issues with URL encoding and is rarely blacklisted, but you may also use any other binary operators to squeeze in your payload without causing a syntax error.


OAuth2 for first party web-app I am building a web (also potentially mobile app) for a platform that allows plugins. We're using the OAuth2 Authorization Code grant type for third-party client plugins.

Which, if any, grant type should I use for our first party clients (i.e. our web/mobile apps)?

Currently, our users log in with an external service, i.e. Google as an OAuth2 consumer. We then issue a JWT (with the username and a CSRF token) as a cookie, and this is used to authorize our users in our API; for third-party clients, we look for OAuth2 tokens.

However, I'm wondering if we should use a 'password' or 'implicit' or 'authorization code with PKCE' grant for our apps so that our endpoints are consistently using OAuth2 for authorization, rather than checking for the JWT (to see if it's a user) and if not checking for an OAuth2 token (if it's a third-party client).

A bit more (possibly unnecessary) detail: we're using the scopes in a GraphQL endpoint to validate queries/mutations and just giving JWT (user) bearers access to all scopes (since a user has access to all their resources from our app). This article seems to suggest I should use 'password' grant type, but I'm a bit confused because we offload our authentication to another provider, so we would just be validating the JWT and then issuing the token, rather than doing anything with username/passwords.

Or should I just issue a token after they authenticate with Google to access resources on our platform (what would flow would this be?). Lastly, and perhaps beyond the scope of this post -- we also want to issue personal tokens so that devs can start working without registering an app using their own data.

You have mainly a session management rather than an authentication issue.

As you noted, users are already authenticated, what you have to decide on is how to maintain the user's session. Issuing a JWT upon Google atuhentication is reasonable choice albeit with non-trivial caveats as a quick search will demonstrate. Instead of a JWT you could rely on HTTP session and cookies - just to present alternatives. IMO you are best off using an infrastructure/library that does this e.g. Spring Security, which you can customize to your needs.

In so far as authorization (access control) is concerned, you noted that users have full access rights. Should that change in the future the nice thing about using a JWT is that it can also contain information about what is in scope. For a more standards based approach I suggest looking at UMA (User Managed Access)   libraries/services to build on.

On a side note, using authorization code grant is likely the most secure choice given a third party authentication service is involved - stay with it. Might I also suggest being aware of RFC8252 OAuth 2 for Native apps to ensure authorization code grant is also used properly with mobile apps - it details how redirects/codes are securely managed between the mobile system browser used for authentication and your mobile app.


About onion packet and onion routing? I was just wondering if anyone has a diagram showing what is encrypted inside an onion packet when it leaves the sender?

When a Tor client sends the packet out, wouldn't the entry onion node know send real IP address? When reply traffic comes, what is the destination address for the traffic when it leaves the server?

The image below shows how a packet is encrypted, and sent through the network.

Tor uses its own protocol to negotiate encryption keys.  Through this protocol the client receives encryption keys for Routers A, B and C.

From the Tor Project

  The client negotiates a separate set of encryption keys for each hop
  along the circuit to ensure that each hop can't trace these
  connections as they pass through.

Before a packet is sent, it is encrypted with C's then B's then A's encryption key.  When the message reaches router A it decrypts its layer, and forwards the rest to router B.  Router A only know that the message needs to go to router B, and that it came from the client. It cannot see any other IP information.

For Tor (and onion routing) to work a minimum of 3 routers are required.  So that no two routers will know both the source and destination IPs.  When a Tor client sends a packet out the Entry Node will know the source IP address, but not the destination.  The Exit Node will know the end destination, but not the real source address (just the previous relay).  The IP address the server uses for the first layer will be the Exit Node's.

To address questions in your comments
If an Entry Node is compromised then it can reveal the source's IP address.  But it will only know the next node in the circuit.  Without some type of relationship to the destination the anonymity stays intact.

The Exit Node never seeds the original source address, and uses its own IP for communication with the end destination.

For more info look at the original Tor design paper.


Is End to End security possible without physical contact? I noticed that a lot of messaging start to provide "End2End" security, but I wonder how this can be possible without a key exchange between the the two clients.

To my understanding to provide real end to end security you have to exchange the key between both clients without using the internet, as all the other could be sniffed or changed by some one else. So how can for example WhatsApp provide End2End security ?

Sincerly,
Thalhammer

I think you need to separate in your mind confidentiality protection from authentication.

It is quite possible to simultaneous generate a key between two parties over the Internet, with everyone from your ISP to every Govt possible listening in, yet they cannot as an eavesdropper also generate that key.  That is the essential point of say the Diffie–Hellman key exchange (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange).  But both parties can use that key for confidentiality protection ONLY; in that scenario neither party truly knows who they formed the key with.

The reason being, if all those baddies on the Internet are active man-in-the-middle, each party could wind up creating a key over-the-Internet with the man-in-the-middle, and be none the wiser.  Hence a proper secure communication system includes authentication first, then confidentiality second.  For authentication, indeed you need some means out-of-band to get the absolutely true identity key of the other party (and there are a lot of ways to do that with varying levels of reliability).  But once you've established identify and authentication of your other party, it is possible to develop keys used for confidentiality purposes over the Internet (by also including the authentication keys in the key exchange process so the man-in-the-middle cannot hijack it).

Re WhatsApp, it gets its security from TextSecure, which relies upon the security of the Off-the-Record Messaging protocol.  Start with the Wikipedia article; it has a subsection that discusses authentication of the two parties: https://en.wikipedia.org/wiki/Off-the-Record_Messaging


How high is the entropy of this salt-generating code? (No code-reading actually necessary) What is the best method?

Assumption: I have a function that generates a number of medium-high entropy bytes

Step1:
I generate 3 of these medium-high entropy bytes.
Step2:
I hash these bytes using a known crypto-strong algorithm (sha256)
Step3:
I cut a substring from the result.
Step4:
I use this string as my salt (3 byte salt)

So, I can do:

Step1 and 4;
1, 2, 3, and 4;
1, 3, and 4; etc.

The question is which of these operations increases entropy, and which does not?

Some code:

function delicious_delicious_salt()
    {
        $string = openssl_random_pseudo_bytes(3);
        //Do I hash this? Do I generate a longer byte string and cut it?
        return $string;
    }

What I actually don't know

Does passing pseudo-random bits through a hashing algorithm and cutting a pseudo-random set of bits from the output produce high entropy bits?

I want to implement a salt-generating function for my SHA256 password hashes on my web server, and as an exercise in my own understanding I want it to be as cryptographically secure as I can reasonably make it without going crazy (and taking entropy encoded from HIDs (mouse, mic, video)).

Entropy is a measure of the number of possible outcomes for the whole system. If you start with three random bytes, then there are 16777216 possible inputs. Regardless of what you do from these inputs, you will only get 16777216 possible outputs; no amount of hashing & cutting & praying will change anything to that -- except possibly by reducing the number of possible outputs. With your hashing and then truncation to 3 final bytes, there is no guarantee that all 16777216 values for these three bytes will be possible. In fact, you should get about 10 millions of them, no more.

A salt is only as good as it is unique. It does not need to be secret or unpredictable, but you should strive for never using the same salt value twice, or at least to keep the reuse to the bare minimum. If your salts must fit in three bytes, and your source of randomness is three bytes, then the best you can do is to simply use these three random bytes as salt. Hashing them is just a needless complication, which has no security benefit, and actually reduces the space of possible salt values, thus implying a higher reuse rate.

You could generate salts with a non-random process, if you can keep a state. Namely, maintain a counter, which is incremented for every generated salt. Counter management can be troublesome (especially in multi-frontend systems), which is why using randomness is often preferred. But that randomness is just a tool to achieve uniqueness. It is not a problem if salts are not random or follow a predictable sequence. The problem is when you reuse a salt value.


Fuzzing versus Symbolic Execution -- what's the difference? Fuzzing, per a current Wikipedia definition is defined the following way:

  Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs.

  https://en.wikipedia.org/wiki/Fuzzing

Symbolic execution, by contrast, is defined the following way, also pulling from Wikipedia:

  In computer science, symbolic execution (also symbolic evaluation) is a means of analyzing a program to determine what inputs cause each part of a program to execute. An interpreter follows the program, assuming symbolic values for inputs rather than obtaining actual inputs as normal execution of the program would, a case of abstract interpretation.

  https://en.wikipedia.org/wiki/Symbolic_execution

What I am trying to understand is the functional difference between these two methods. I see the line that says symbolic execution determines "what inputs cause each part of a program to execute," so you might differentiate each method by the "goal" a security researcher has in mind. Papers I have read recently differentiate symbolic execution from fuzzing by saying the former has significantly more overhead / runs more slowly.

From my perspective, symbolic execution utilizes a form of "targeted fuzzing" that specifically hits certain symbolic values. I've also heard it said that symbolic execution is just "more sophisticated fuzzing."

Can someone clarify what the real difference is between the two and why or when we should prefer one method over the other?

Can someone clarify what the real difference is between the two and
  why or when we should prefer one method over the other?

(Dynamic) symbolic execution is sometimes called whitebox fuzzing, see, e.g., SAGE. Fuzzing can be grouped into categories:

Blackbox fuzzing: doesn't require any information about the system under test (SUT). There are two strategies to generate input: generate from a grammar/model, or mutate from existing ones.
Whitebox fuzzing: require all the information about the SUT, including APIs, environment etc. It needs to know which instruction is executed, so that it can replace the semantics of the instruction with the symbolic semantics.
Greybox fuzzing: require to know a little information about the SUT, i.e. basic block transition. Currently it is the most successful, see, e.g., this trophy case.

  Can someone clarify what the real difference is between the two and
  why or when we should prefer one method over the other?

Let consider a program with an input x, having the following condition: if (x > 5 && x < 10) abort();
Suppose x is an integer, i.e. its domain is 232. The probability to randomly generate an input x that triggers the error is 4/232. This probability is a bit higher in clever greybox fuzzing, but in general they suck for this kind of condition.

On the other hand, whitebox fuzzing executes the program with a symbol x = X, and use a constraint solver, e.g. Z3, to solve the constraint. Z3 can solve X > 5 ∧ X < 10 in mili or nano second.

However, there is no free lunch, this power comes with an expensive price.

A recent paper shows that for just one path, i.e. no constraint solving, an execution in KLEE is 3000 times slower than native execution, while angr is 300,000 times slower. Since it is very slow, it is unrealistic to achieve 100% coverage.
Constraint solver is only good for linear arithmetic. There is no efficient solver for the theory of string, floating point arithmetic etc
It is unrealistic to know all information about APIs, environment etc.

The current state-of-the-art is hybrid fuzzing, combining both greybox and whitebox. The idea is to use greybox fuzzer as global search to quickly sample the state space. When it gets stuck, then use the heavyweight whitebox as local search. This is the technique used by all the team in the Cyber Grand Challenge. The hybrid fuzzer QSym , running on a modest machine, discovered some CVE that Google couldn't find with greybox fuzzers running on the cloud.


"Reflected XSS"-like attack on chatbot AI This is a theoretical question. I just watched a certain video in which the author apparently unmasks a chatbot AI that is likely trying to harvest data and spread influence in a cult-like manner on a given social network. The video is hosted on YouTube:
Who or What is Stephanie Lawson Stevens?

What really caught my attention was that at some point one of the investigators, who has an IT background, starts asking some questions to the user (who up to that point was just a person, not a supposed AI) and then infers from the answers that that might be an actual chatbot. The video I linked above shows the process.

I'm no specialist in AI at all but it made me wonder: The AI reads information coming from a text input (the chatbox). Would it be theoretically possible for a user to craft a certain coded message through a chat that, once read by the AI, acts as if a reflected XSS attack was made on the AI (the same way that people can reflect code that is executed by a victim's browser)?

In this scenario, if the programming of the AI itself doesn't include the necessary precautions in sanitizing the text input, the AI might read a snippet of code from the chatbox and end up executing it.

Is this an actual possibility?

XSS? Highly unlikely. General injection attacks? Sure.

XSS is essentially a vulnerability that allows an attacker to execute Javascript in another users browser. But it's unlikely that an AI would simulate real-world users to a degree where it logs in with a browser, gains a session, etc.

It is more likely that the AI would run on the server itself (or some other server and communicate via API).

Without (user/AI) interaction in a web browser, there's by definition no XSS. But you can have various other injection vulnerabilities. OS command injection, SQL injection, etc.

A very simple example:

$userinput = [input]
// do complex stuff. Find an unknown word $word (defined as a string of chars in-between spaces) and look it up via OS command:
$definition = system("dict " + $word);

What is also possible is that user input can contain some HTML (eg for links), and that the HTML parser which feeds data to the AI contains vulnerabilities (SSRF comes to mind). But again, without executing Javascript in a browser and abusing the current authorization of the attacked user, any vulnerability here wouldn't be an XSS vulnerability.


Storing account numbers and sort codes online There are a lot of questions on storing credit card information, and of how PCI SSC/PA-DSS regulations apply to such activities and systems. I have read a lot of these, but my question relates to a different question that may or may not have anything to do with PCI compliance.

My question is specifically, what are the implications of storing sort-codes and account numbers online, considering we are not taking any kind of payment. So, nothing to do with using the information to make payments through the system, but using the information to enable other users who have access to the system to make payments.

I have taken a look at this question:
Is PCI DSS applicable to other solutions than those dealing with payment cards?, but I really need to know the regulations and what is mandatory.

I understand that if we did have payment provision on the website we are developing, then the storage of account numbers would affect the level of PCI compliance we would need to adhere to.

Currently we are adhering to what would be considered security 'best practices', so using SSL, encrypting information in the db, dedicated server with hardware firewall etc., but these 'best practices' are from an internal point of view of a development team. I know the software in PCI compliance is only one part of overall security regulations. Outside of PCI compliance, is there, for example, a definitive set of rules for storing sensitive information? Are we for example obligated to adhere to ISO 27001 standards? Who defines what information is considered 'sensitive'.

The general consensus regarding PCI compliance and the handling of credit cards, is if you need to ask then you shouldn't be doing it. I'm not necessarily asking whether or how we can do it or not, but whether anyone has experience of this, and whether we need to engage a 3rd party consultant who specialises in such areas.

If you're not handling credit cards, debit cards or other related payment cards, PCI does not apply to you in the sense that you are not beholden to follow its requirements in any way.  PCI is "enforced" by the business relationships between merchants, acquirers, and issuing banks; if you aren't handling cards, you don't have those relationships.
Because the PCI standard "represents a common set of industry tools and measurements to help ensure the safe handling of sensitive information", it is useful and relevant to sort codes, bank routing numbers, and account numbers.  However, it also assumes an environment (generally, cardholder data in transactional motion) which may not apply, so as someone said in the other post you linked, parts of PCI may be irrelevant or counterproductive for your particular problem.
It cannot hurt you to talk to your bank about any advice or regulations they consider relevant.  Where you use the term "sort codes" I assume you're in Europe, and I have no idea what other regulations - consensual or governmental - would apply to you.
The bottom line is, PCI is common sense security, and even if holding non-PCI account data you'd be smart to follow any applicable parts while being careful to understand what doesn't apply to your situation.  PCI is also a lowest-common-denominator standard, so you should continue to improve your security from there.  Good luck!


How do we secure image parsing libraries against buffer overflow? New to buffer overflow through image parsing. How can one design a secure library that parses images, and ensure there are no security vulnerabilities in it? It is common knowledge that image parsing libraries are vulnerable to Buffer Overflow, so I would appreciate it if someone could specifically explain how to secure image parsing libraries against buffer overflow.

There are a couple of obvious things which are not limited to image parsing libraries:

Don't assume that the input is well-formed but actually check it. It is actually a common problem with image or video libraries that they were not designed with deliberately malformed input in mind but which are nevertheless used to process input from dubious origins.
Use a safe programming language which by design is not affected by buffer overflows or makes it at least very unlikely. This means use a language which does not allow to write out of array boundaries and which does not allow to double free memory or similar memory management problems. Most higher level languages don't have this kind of problems though they might affect the performance more than you like. But there are also lower level languages like Rust which provide both memory safety and high performance at the same time.
Limit impact of programming errors by using compiler-specific or system-wide mechanisms which protect the stack (canaries), prevent code execution from the stack, provide some kind of sandbox around the application etc.


Do I require a SSL certificate for using Google Login? I am working on a new site, and in order to avoid security hassles, I'm planning to provide Google and Facebook login to my website.

Do I still need a SSL certificate or is it not necessary?

Moreover, when a user goes through Google or Facebook Oauth, do Google and Facebook take care of credentials and passwords?

Using SSL protects your users from being phished

If you don't secure the connection between your website and your client, a man in the middle can change the page content to try stealing users credentials. When the Bob connects to your website his browser fetches the page content. If there is a man in the middle between Bob's PC and your server, he can change the page content before sending them to Bob. In this case, when Bob tries to login your website with Facebook, he will connect to malicious guys website, which tries to fool the user and steal his Facebook credentials.

If you use https in your website, the scenario above will never happen. Because Bob's browser will know the connection is interrupted.


Is there a common best practice for naming public and private PGP keys when exporting them? Is there a common best practice for naming exported public and private GPG keys when exporting them or otherwise storing them as files?

I know that GnuPG doesn’t care what keys are named when you import them. However, there must be some naming conventions for exporting. There always is for this sort of thing. I just can’t find a clear answer myself here or through Google.

I imagine there might not be a common best practice for naming private keys. In server environments, the private key seldom gets exported. But for personal communication encryption, a private key needs to be backed up, and possibly imported on a new computer. Therefore, it must be exported. In theory, you are the only person who will ever see the private key file and know what it is, so there is no need for a “best practice” naming convention. But the public key file must be shared and so there ought to be some common best practice out there.

Suppose I just created a new key pair: Bruce Wayne <bruce@wayneenterprises.com>.

Then I export the private and public keys as ASCII-armored files—the private key to be stored somewhere secure for backup and the public key to be shared with people.

What should I name the files? What extension should I use?

Generically…
public.key
private.key

Using the UID “Real Name”…
brucewayne-public.asc
brucewayne-private.asc

Using the UID email address…
bruce@wayneenterprises.com.public
bruce@wayneenterprises.com.private

When keys are generated, there’s an eight (hex) character ID that’s displayed. I have seen a public key use this as the filename.

~ # gpg --list-keys
/root/.gnupg/pubring.kbx
------------------------
pub   rsa2048/1234ABCD 2016-08-20 [SC]
uid         [ultimate] Bruce Wayne <bruce@wayneenterprises.com>
sub   rsa2048/5678EABC 2016-08-20 [E]

If there is any common best practice, please let me know. And, if possible, point me to any documentation or manual that uses it.

While obviously it's very hard to prove a negative, I think that the reason why you have found no such "common best practice" is that none exists.

The key itself doesn't care about its file name. What's more, there are ways to deal with exported keys that don't ever involve any files on a file system at all! Consider something relatively trivial, such as gpg --export 0xDEADBEEF | ssh me@remote-server.example.com gpg --import.

You should however name the exported key file such that you have some idea of what key it contains, since the exported file itself (ironically enough, more so if the file is ASCII armored than if it is not) won't hold that information in a readily readable format unless you edit it in yourself (for example, in the Comment: field of an ASCII armored data blob).

For publication, the hexadecimal key ID is usually a good place to start because it's reasonably unique, particularly if you use the full 64-bit key ID or even the fingerprint (which is practically, but not theoretically, guaranteed to be unique).

For personal storage, or to for example e-mail the public key to a correspondent, you usually want to be able to tell keys apart yourself, but don't really care about global uniqueness. Thus, something that identifies the key to you is likely a good place to start; thus, you might start by looking at information such as the associated name, the associated e-mail address, generation or expiration date, or something along those lines. If you generate a new key once every 18 months, for example, the generation date might be a reasonable thing to include in the file names, because it tells you about the chronology of the keys as well as which you could expect to be used for a specific message.

I have seen a variety of naming conventions to differentiate between the private and public portions of the key, but the bottom line there is that it really doesn't matter at all as long as you can tell with no risk of ambiguity which file is which. If you want to append -private and -public before the file name extension, or if you want to name one .asc and the other .private, or whichever scheme you prefer, really doesn't matter at all: just pick one that makes it obvious to you which file is which.


Do backups with application-level authentication defeat ransomware? While having "too much time" and after some careful thinking from my side, I kinda "found" that if you authenticate at application level, ransomware would have to carefully analyze all known settings files to recover login credentials and then implement backend-access protocols to actually also take this data ransom.

So far for the introduction and the "TL;DR", now for a more specific description:

Assume we have a computer which we want to secure from ransomware.
Assume further this computer runs regular backups.
Assume these backups are done by an application or service on the computer to a server, this application may be very popular (but not shipped with the OS).
Assume the OS isn't directly involved in the backup process / doesn't provide the target drive as mapped drive.
Assume the application authenticates itself (with PK auth or username+password) to the backend server.
Assume the authentication credentials are stored clear-text on the computer to be secured (as is usual).
Finally assume the server itself is guaranteed to be clean from ransomware.

Is the computer's backup now safe from being successfully attacked by (non-targeted) ransomware?

The answer to this question depends entirely on how smart the ransomware you want to defend against is. If you're dealing with standard ransomware, the answer is most likely yes, your backups are safe.

If you're dealing with ransomware which is aware of your application and targets it specifically, then obviously no, your backups are still at risk.

Note that in the first case, while the ransomware can't reach the backup server disk directly, it can still encrypt the local files and if your backup application doesn't stop backing them up, sooner or later backup rotation will rotate all valid backups out of existence.

May I suggest a different approach:

Keep several backup revisions. After you made a backup, sample a nontrivial number of important files to see if they pass various statistics for random data (eg even distribution of bytes, no known file type, almost 0 compression rate etc) . If most or all of your files look like random data, they are probably encrypted and you can disable the backup and alert the sysadmins, so while you've lost the most recent backup, all your earlier revisions are still available.

You could also do the tests on the live system before starting the backup, but I'd check the backup itself even if it meant losing one.

This will protect against ALL ransomware.