SSL / TLS: Is a server always required to respond to a close notify? I'm a developer and I'm implementing a socket connection with SSL (using javax.net.ssl.SSLEngine). For testing I'm opening connections to arbitrary HTTPS servers on the Internet to see how the handshake process proceeds after opening the connection and before closing the connection.

My question is about the handshake just before closing the connection.

My application sends an SSL close notify alert to the server and Java's SSLEngine then expects to receive a close notify alert back from the server. However, some servers do not send a close notify back to my application - they just close the connection.

For example, https://www.oracle.com sends the close notify as I expect it, but https://www.google.com does not - it just closes the connection after my app sends the close notify.

Is it optional for a server to respond to the client's close notify? What consequences does it have for my app if the server doesn't do this? (Can I safely ignore it if the server doesn't do this?).

(Example code on Github: jesperdj/sslclient)

The close notify should be sent by both client and server according to the specifications.

RFC 2246 Section:

  The client and the server must share knowledge that the connection is
  ending in order to avoid a truncation attack.  Either party may
  initiate the exchange of closing messages.

  close_notify
        This message notifies the recipient that the sender will not send
        any more messages on this connection.  Note that as of TLS 1.1,
        failure to properly close a connection no longer requires that a
        session not be resumed.  This is a change from TLS 1.0 to conform
        with widespread implementation practice.

  Either party may initiate a close by sending a close_notify alert.
  Any data received after a closure alert is ignored.

Now, not all implementations follow the specifications.  Everyone is shocked... I know.  Look at the bolded part of that quote.  They changed the spec in 1.1 because wide spread implementations do not send close_notify messages.

To ensure that your app is doing its due diligence you should always send the close_notify.  The important thing for you is to ignore any other data that is sent to you except a close_notify.  As far as you're concerned the connection is over.  It is nice to hear this from the server, but all you need to do is drop any other data that comes along the tunnel.

As stated in the above quote, in TLS 1.1 you can still resume sessions even if one side does not perform a close_notify.

This does mean that you're susceptible to a truncation attack:

Truncation attack

A TLS truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no more data from sender) to close the connection. The server therefore doesn't receive the logout request and is unaware of the abnormal termination.

This is one good reason why most financial sites log you out if a session expires or times out.


Can anyone tell if a wireless router is plugged into an Ethernet port (without actually seeing it) In a large network if there is an Ethernet port in the wall, is it possible to tell if a switch or wireless adapter is plugged into it? (I'm talking about the cheap home routers - with the built in switch). In other words would packets appear different than those coming from a single computer?

A basic router is both a network switch and another local system with an IP address. Things vary depending on how the router was configured, and how the network was configured, and what level of surveillance is applied.

The "switch" part is nominally undetectable at the software level: a switch is a relay system, which does not have a MAC address, let alone an IP address, and it is passive: it produces no ethernet frame on its own. What the network admin might detect is that a device has been plugged: when a device is plugged, the LED on the network switch at the other end of the wire goes up, indicating an active link. If the router has been plugged into a normally "empty" plug, then this could be detected, at least if the network switches have extended reporting capabilities or the sysadmin is enough of a maniac to count the LEDs on his switches every morning. Correspondingly, the "attacker" (by which I mean "whoever plugged the router") may make himself less detectable by replacing an existing machine with his router: unplug a desktop system (or a printer), put the router in its place. Of course, this makes the unplugged system unavailable, which may show up on the sysadmin radar, depending on what that system usually does.

Then comes the "system with IP address". Now we must look at what a typical home router offers and how it behaves. The router has three kinds of "ports":

The "uplink port" which is normally linked with the ISP-provided modem (cable, ADSL...).
The "ethernet switch": the other RJ45 plugs on the router.
The "WiFi port", i.e. the over-the-air wireless LAN.

Most routers will maintain a bridge between the ethernet ports (other than the uplink port) and the WiFi, so that we may consider, for the purposes of this question, that the WiFi and the ethernet ports are equivalent.

If the attacker links the router's "uplink port" with the corporation network, then the router will automatically request an IP address with DHCP from the network infrastructure. Afterwards, it will do NAT on behalf on machines connected to its other ethernet ports or to the WiFi (the router will itself be a DHCP server on the ethernet/WiFi LAN). This can be detected by the sysadmin through the following ways:

When doing the DHCP request, the router will use its own MAC address, which is distinct from the MAC addresses of the normal systems. A meticulous sysadmin will instruct his DHCP server to give IP addresses only to a given, exhaustive list of known MAC addresses, and to raise alarms when an unknown MAC address is seen. Also, the same sysadmin may configure his switches to simply refuse any packet coming over a given port if that packet has a source MAC address which does not match the MAC address of the desktop system or printer which normally resides on this port.
Let's assume that the DHCP was allowed, or that the router was configured with a static IP address directly; then the router now has an IP address which is part of the local network, but does not react exactly like a normal machine (or printer). OS fingerprinting can be used by the sysadmin (typically with nmap -O), on a regular basis, for all IP addresses which may normally occur on the network (e.g. all the addresses that his DHCP server may normally lease).

The attacker may try to evade the first kind of detection by making his router assume the MAC address of the desktop system or printer which normally uses the plug (typically, his own desktop system). Though every piece of ethernet hardware has its own MAC address, this can be overridden in software. A stock home router will not necessarily offer this feature, but reflashing the router with a better firmware (e.g. OpenWRT) can unlock that kind of manipulation. However, this won't help the attacker against OS fingerprinting. It is very hard to emulate the network behaviour of a Windows system, down to that level, unless the OS is indeed running Windows -- and Windows won't fit in the router.

An alternative way for the attacker is to configure the router NOT to act as a DHCP server on its ethernet/WiFi LAN, and to plug one of its non-uplink ethernet port into the local network. In that case, the router is no longer used as a "router" but as a switch. With this setup, all the machines which connect over WiFi are "as if" they were directly plugged in the local network. This moves the problem of evading detection to these machines.

On the one hand, this allows the attacker to plug back his desktop system in one of the router ethernet ports, so his system will work as usual. At that point, the home router is undetectable. On the other hand, every host which connects to the WiFi becomes subject to the detection powers of the sysadmin, since there is no NAT. The local switches may block the unexpected MAC addresses. The local DHCP server may refuse to give IP addresses to these newcomers.

To sum up, the sysadmin will be able to detect the "router" by doing the following:

Maintain a list of all "allowed" MAC addresses, and configure the switches to block (and possibly report) unexpected MAC addresses on each switch port. (This requires "intelligent" switches, of course.)
Configure the local DHCP server to always give a specific IP address for each allowed MAC address. Alternatively, don't use DHCP at all, instead use static IP allocation (but DHCP is convenient to distribute addresses of gateways and DNS, so a full static, DHCP-less scheme may increase sysadmin work).
Configure switches to report on any IP packet which uses an address which is not part of the list of allowed IP addresses.
Regularly, run some nmap -O for all allowed IP addresses to see if each machine uses the expected kind of operating system.

With this setup, the sysadmin stands a very good chance of detecting any shenanigans related to a home router plugged in the local network.

At some point, you would have to consider the social side of things. When a user plugs a home router, this is for a reason, which may be legitimate. It is possible that the user wants to give free Internet access to a friend living in the next building; but it is also possible that the user really needs that kind of extra access to do his work. This might be a situation where the presence of a company-sponsored WiFi router, possibly suitably isolated in its own DMZ, could be a good idea. Detecting forbidden actions from users is good; making it so that the said users do not even wish to perform forbidden actions, is better.


IMAP with authentication set to none While adding a Mediacom email account into Apple Mail I referenced their page on IMAP settings https://supportstage.mediacomcable.com/print/1446, I noticed that authentication type for incoming email is set to none.  Does that mean anyone can access my email just by knowing my email address?

No, that means that the communication from your computer to the IMAP server is not encrypted.  You still need to send your username and password to the server, but it is visible to someone sniffing your network traffic.  I wouldn't recommend using that service.


Convert ntlm to aes256 in sekurlsa::pth In mimikatz, sekurlsa::pth also supports /aes256 switch. But where how can I get the aes256 hash?

I can retrieve NTLM hash from many different tools, is there any way to convert it to a aes256 one?

In short, no you cannot convert NTLM to AES. NTLM is a hashing function vs AES, which is an encryption algorithm (see @MikeOunsworth answer for more on this).

To recover the AES version of the password, the Domain needs to be configured to store them as such and you'd recover them by dumping the ntds.dit (Active Directory User Hive backup). Then you can use secretsdump.py or similar tool to extract the AES versions. Now that said, you'll need Domain Admin (or equivalent permissions) to dump ntds.dit (from a Domain Controller), so PTH may not be needed if you have that level of perms, but you could do it nonetheless.

EDIT

Here's what each version looks like when recovered from ntds.dit

WAKANDA$:5136:aad3__LM-HASH__d3b435b54ee:f1e03f8f94__NTLM-HASH__f0c0df:::
WAKANDA$:aes256-cts-hmac-sha1-96:8941c28ac__snip__8a51adf13336b
WAKANDA$:aes128-cts-hmac-sha1-96:cbe71ab9b__snip__2dc21d6
WAKANDA$:des-cbc-md5:576_snip_bcec
WAKANDA$:rc4_hmac:f1e036ef8f__snip__69cf0c0df


Why would a hacker/thief just use my credit card for Apple in-app purchase? I talked with Apple and finally I found out it was my credit card information got stolen instead of my Apple account. I looked at all my transactions and hacker/thief only made few Apple in-app purchases but nothing else, and the total cost is pretty small just around 100 US dollars, and I got refund. Any reason why the hacker/thief only did that even with my whole card information?

Honestly, there is a surplus of credit cards out there for cheap, so it's likely to get more for your money buying dozen(s) of them and using all of them for smaller purchases in hopes of evading notice form their owners.

I have never bought stolen credit cards, but if seemingly reputable online bloggers/news sites like Krebs are to be believed, it's a remarkably easy task with no skill level required. As to the prolific availability, there is an analysis/rant section in the below article that speaks to it a bit.

http://krebsonsecurity.com/2016/01/hyatt-card-breach-hit-250-hotels-in-50-nations/


Are there best practices concerning application account credentials? I am looking for best practices concerning application account credentials.

For example, suppose I got a corporate application which uses an Active Directory application user account to communicate with corporate LDAP. Then, what is the best way to manage this account and its credentials (client-side) ?

Is it needed to encrypt a configuration file with these credentials, with an administrator decrypting it (Password based encryption) when application starts ? It seems the best way but it is not very easy to update LDAP account password because you need to modify and re-encrypt the configuration file.

The topic is quite broad, so I'm not aware of a generic "best practices list" which addresses your questions. The topic quickly becomes very platform-specific.

Very generically:

do check your specific scenario you're trying to defend of. There is no silver bullet.
restrict (file) access permissions to those who do need access to that file.
Password-based encryption/authtentication is simply something which needs to go.

Considering your exact question:

  Is it needed to encrypt a configuration file with these credentials,
  with an administrator decrypting it (Password based encryption) when
  application starts ?

This option can improve security, but also be a major nuisance or reduce the availability of the service in question. Depending on scale, it can be highly problematic.

if the application is running without acceptable levels of redundancy (e.g. n+2), the application crashes every few hours or frequent updates do require frequent application restarts, an experienced administrator will write a script to restart the application in order to get the service back online as soon as possible. If this requires entering some password, this restart script will (sooner or later) contain the password as well. This will nullify your "extra" security.
recovering e.g. from a power outage may take a very long time, as the strategy involves manual interaction. If your application is running on hundreds or thousands of servers, it may take hours or days to manually recover from this.
in comparison to cryptographic keys, passwords are very short, restricted to a small range of ASCII characters and so do provide not that much entropy, resulting in severely limited level of security. Or, otherwise: 62^16 (16 char long alphanumeric password) is a minor fraction of what just 2^1024 (1024-bit keys) does provide in terms of entropy. If you're trying to defend against brute-force (offline) attacks, passwords can't be the only protection (unless you're willing to use very lenghty passwords).

Please do re-check your attack scenario: what are you trying to defend against?

The configuration file contains "secret" information. If the server's disk fails and is replaced, a (revived) failed disk shouldn't expose this information. Most kinds of disk or file system encryption will solve this issue while being transparent to the running application. Coupled with a hardware security module (e.g. a TPM module) instead of a password, the machine may also recover from a power outage without manual interaction.
A malicious user or attacker may get access to the machine and shouldn't have access to the config file. File system ACLs do so very fine.
A malicious user or attacker may get access to the application container and access data to be protected. This can be very hard to solve: the user could just dump memory of the running application and search for passwords in there. Many application containers also contain debugging and administration interfaces, from which a user can also directly access e.g. variables (who may contain the LDAP credentials). Securing those interfaces/consoles is also an important task.

You also didn't specify a platform or environment; e.g. in the windows environment (since you mentioned Active Directory), it may be a good idea to store passwords as a securestring in the registry. This does bind access to the specific application who stored that password. However, if the malicious user is running code or under the application's identity, this quickly results in the previous issue.

  It seems the best way but it is not very easy to update LDAP account password
  because you need to modify and re-encrypt the configuration file.

If the LDAP account password is changed, the configuration file needs to be modified anyway (and the application may require a reload/restart). Touching the file yet one more time by re-encrypting it isn't that much more work to do and can be automated in a very simple and yet secure way (e.g. gpg-encrypting the config-file using a public key whose private key is only known to the running application/machine, before pushing it to the machine).
If you're changing the LDAP account password to comply with some corporate password policy, the same policy will probably apply to the password used to encrypt the configuration file - so you need to re-encrypt that file anyway, why not combine this?

If running in a larger setup of application nodes, changing the LDAP account password may also become more complicated: you may have to shut down all running applications, change the password, wait for it to replicate to all LDAP/AD nodes, re-start the application. This does "require" an outage, and an alternative to this is to create a new LDAP/AD user with a different password, but using the same LDAP/AD permissions than the original user. You reconfigure your applications to use that new user and sequentially restart your application containers; given that those application containers are running with some redundancy mechanism, this can be an almost-seamless migration.

However, doing so requires you to maintain two user accounts with identical permissions; if they're manually managed, this will probably not work out very well.


If you phone is seized, can you erase sim or stop them from cloning? If your phone (for example, an iPhone) gets seized by the police, do they have sufficient technology to copy sim card (or any data) even if you cancel you provider and put phone in lost mode? If so, is there any way to remotely wipe sim and/or data on said phone?

No you can not. On the other hand, with iOS 11.4 it will be possible to limit what a third party can do to your phone as the Lightning USB connection will go into restricted mode if you don’t use the phone for a day.

Regarding your SIM: the data on it and the access it provides is trivial to get from the phone company. If they were interested in getting SMS messages or cloning your subscription, it would be much easier to just call the provider.


Does same hash value indicate a valid key? I send a message to someone along with a public key, which they use to hash the message.

If they get the same hash value that I get when I hash the same content with the private key, does that safely imply that they have my public key?

No, because you don't "hash" a message with a public key. You encrypt a message with a public key.

Furthermore, a message encrypted with the public key will never be identical to a message "encrypted" (e.g. the encryption function applied with the private key) with the private key.

You can't really prove if someone has your public key, because a message encrypted with your public key is indistinguishable from random data. Therefore even if B is in possession of a message that can be successfully decrypted by your private key, it can still be argued that B received this binary blob from a third-party without any knowledge of its purpose.


Encrypt/Isolate files of the Software We want to create a secure email client based on Thunderbird source code and looking for a method to encrypt files or to isolate files from being stolen by some malware.
and to avoid infecting pc via malicious emails.
Which method is more secure to use? to encrypt files or to make it run in virtual sandbox.

if you have more suggestions,you are Welcome!

Without more details about your suggested options only more general advice can be provided.

With regards to encrypting files (assuming it is the data of the received email communication), certain malware might be prevented from reading and maliciously modify the data, much less from deleting the data altogether (something that also LSerni comment hinted on).
Consider that efficient malware would strive to gain (or already have) access to the memory of your application , including the key used for encrypting the data. With encryption you might only protect against malware running as unprivileged (non-root/non-admin/non-ring0) code.

With regards to the virtualization sandbox, which sadly is not a very explicit thing to discuss much about, I would state that again this could prevent some sort of malware interaction, only under the condition that the malware again is not running in a privileged code. Frankly it is mostly the way that virtualization is a technology with merits as to contain (restrict/limit) malware, as is the concept of a sandbox. To my knowledge sandboxes are not the method of choice to prevent a program from attacks (by malware), but sandboxes are rather the tool to prevent potential malware to attack legitimate programs/data/systems.

Anyway it seems that a reason to employ either method (encryption/sandbox) would be to protect your email-client-users from receiving malware from the emails, in which case your software (email client) is the vector, in which case it seems that a sandbox might -imho- be much more effective (when well designed) to protect the host system, then the encryption of emails.

TL;DR

both options, encryption and virtualization, cannot reasonably protect you against bad malware (rootkit, ring 0).
a sandbox (well designed) might be a more effective tool to secure the host system from your email-client (and the emails), then encryption.


How can I make wordlist smaller size? I've been thinking if I create numeric 8chars wordlist and then compress it, can I directly input compressed wordlist into aircrack-ng or is there a way to make a smaller size wordlist, because if I want to create wordlist with Crunch and Mixedalpha, it's size would be around 35PB, which I don't have.

Is there anyway to make a smaller-size wordlist?

Well, technically if you put fewer words in your word list it will get smaller but the chances of it being of any use are reduced. If storage is your main concern you could use the following approach:

Split the whole word list into smaller lists
Compress each of this list individually
Send/get them each to the machine aircrack is running on
Decompress the current word list and create a session for aircrack
If a valid entry is found stop. If not continue retrieving compressed word lists

To split a large file you can use split:

split --bytes=10M /path/to/large_wordlist /path/to/small_wordlits/word_list_prefix

--bytes indicates the size of the new wordlists. and world_lists_prefix a prefix with which all smaller wordlists will start. The output of the above command will be similar to:

small_wordlits/word_list_prefix**aa**
small_wordlits/word_list_prefix**ab**
small_wordlits/word_list_prefix**ac**

...

small_wordlits/word_list_prefix**zz**

Alphabetical suffixes are added until there are enough files to reconstruct the original file that has been split. To compress them you can use tar:

cd /path/to/small_wordlists/
for i in *; do tar -czf $i.tar.gz $i; done

Next in order to send them to the machine running aircrack you can use scp and to launch aircrack you can use ssh:

for i in *.tar.gz
    > do scp $i user@server:/path/to/wordlist/directory;
    > ssh user@server "tar zxvf /path/to/wordlist/directory/$i"
    > ssh user@server "nohup  aircrack-ng <parameter list> $i &"
    > sleep 10m
    > ssh user@server "rm  /path/to/wordlist/directory/*"
 done

The first and second line copy the first archived split file to the host where aircrack is running in a specified directory and extract it.

The second line launches aircrack through ssh and uses nohup so that aircrack doesn't stop if the connection to the server is lost; this is specially the case when the server is accessible only through a wireless interface and running aircrack(setting it to run in promiscuous mode) blocks any inbound and outbound connections.

The third line gives enough time for aircrack to finish.

The fourth line reconnects to the server and removes the file to make room for the next.

Note that aircrack does not work by its own and needs airmon. The configuration of aircrack needs to be set-up prior to making the above calls. You could write a bash script and alias it as aircrack so that it also handles the adjacent steps.


Protect software from copy Imagine I wrote some software on .NET which will run on client machine. Is it possible to detect that someone copied my software to different computer? (Assuming my software can connect to a remote server - which she could use to aid itself in copy detection). If yes, how?

Without using hardware approach.

Indeed I am concerned when attacker copies software and executes it.

There is a lot of information you can acquire about the hardware of the computer your program is running on, including serial numbers of individual pieces of hardware (consult stackoverflow for code examples). This gives you a pretty accurate fingerprint of the system.

If you have your software "phone home" by contacting your server at startup, it can send you that fingerprint to tell you which machine it is executed on. If you receive far more such fingerprints than you sold licenses, then something is wrong.

However, this won't tell you from whom the pirate obtained their copy. You could find that out by only distributing personalized copies of your software: Include a serial number in each copy you sell. Send the serial to the server together with the hardware fingerprint. When your server receives the same serial number with a different hardware fingerprint, you know which of your customers pirated it and you can take legal actions.

But there are, of course, countermeasures the pirates could take:

Find the serial-number in your software and change it to hide the source
Use a personal firewall to block the phoning-home feature
When the software won't run without phoning home, crack the software to suppress the phoning-home feature
Crack the phoning-home feature to send false hardware fingerprints

Unfortunately there is not much you can do about this. Once your software is on hardware you don't control, it's no longer your software.

The software industry is trying to develop software-based copy protection since the invention of the floppy disk. So far they haven't succeeded in creating a solution which withstood serious cracking attempts from the piracy community, despite investing millions of dollar and using some ethically questionable methods (like modifying the users operating system).

I am also a software developer and I have come to the realization that there are really only two ways to make money with consumer software:

Method 1: Tie your software closely to a subscription-based online service. Consider the service your actual product and the client software a free tool to use it.

Method 2: Simply accept that only those people who really want to pay for your software will pay for it and the rest of the world will pirate it.


How to back up encrypted data over a VPN connection? The encrypted container, the data within or encrypted individual files? Given a (TrueCrypt) encrypted volume on one device A, what is the more secure way to back it up via a VPN connection to the physically far away device B?

Backup the data: Requires the volume to be mounted on both devices, which a physical intruder could abuse to obtain one of them while the container is open, thus rendering the encryption useless. On the other hand, an incremental backup is easy. The transmission itself should of course still be secured...
Backup the container: No device requires the containers to remain open. However, unless small file changes only change small portions of the container and these changes are tracked, this quickly involves a lot of unnecessary data traffic
Backup individually encrypted files instead (not using TrueCrypt but e.g. encFs): Seems to eliminate the disadvantages of the other two methods. But since the encryption should be bound to one single passphrase/keyfile/... this increases the risk of a known-plaintext attack, should too many trivial files happen to be encrypted.

So, is there the secure backup solution?

Back it up using diff-based copying of the encrypted volume image. TrueCrypt uses XTS as its mode of operation, which means at most you'll alter two encrypted sectors (sector n and sector n+1) per unencrypted sector you modify. Every time you modify a sector (or file) on the disk, it'll just have to upload that sector and the next sector.

Sectors are 4096 bytes by default on NTFS, which means you'll transfer 8kB minimum each time you make a change. However, in most cases writes will be to adjacent sectors, which means that if you write 1MB to disk, you'll actually only have to back up 1MB + 4kB, since the cascading effect means that only one extra sector is altered.


Create OpenVPN/easy-rsa certificate from public key only I have been using easyrsa to generate client certificates for my application using the method described here.

The build-client-full command generates a fresh private key for each client. This is what I currently use... run build-client-full send the private key, certificate and ca cert to the client.

What I want to do is have the client generate their own private key locally, send me their public key, and I make the certificate and send it to the client where me as the CA decides the properties of the cert (Common name specifically).

How do I go about it? If I have the client generate CSR, how do I edit the properties in easyrsa before signing? Is easyrsa too simple for this and I need something more complex?

You can use import-req command to import client csr and then sign it. For more info check the documentation of easy-rsa program


Testing Poodle TLS vulnerability with OpenSSL in C++ I'm writing a command-line tool for SSL/TLS vulnerability testing and so far I was able to implement testing for all vulnerabilities that I need, except Poodle TLS. Is there any way I could utilize OpenSSL library to make a quick and reliable test for Poodle TLS? Advice and/or code is highly appreciated, thanks!

The way I made it work is by copying SSL_write implementation and manually modifying padding after encryption. SSL_write uses other non-public functions (from a couple of files) and few macros, those must be copied as well. Correct implementation of TLS protocol must check padding size and all bytes must be set to the same value (by default it's zeros in OpenSSL). Poodle TLS vulnerable implementations don't check padding contents or size. So I just added an extra block with garbage to existing padding in the encryption function. If TLS implementation is not vulnerable then the server will abort the connection or proceed if it's vulnerable.

// increase padding size
i += bs;
// fill padding with junk to test TLS protocol compliance
for(size_t j = 0; j < i; ++j) {
    rec->input[rec->length + j] = rand() % 256;
}
rec->length += i;
rec->input[l - 1] = (i - 1);


How securely should one treat their primary public key? First of all, is my understanding correct that primary keys and subkeys are all key pairs consisting of a private and a public key?
I get the rationale behind using primary keys and subkeys1, and why one should keep the private primary key (or master key) "very, very safe", but not sure what the consensus is on handling the public primary key? Is this the one that should be shared with others or uploaded to a key server2? (Sometimes this may be an explicit requirement.)

It was also confusing to see sentences such as "GnuPG actually uses a signing-only key as the master key" but realized that this refers to the private primary key because (quoting from the same source)

You use the private key to digitally sign files, and others use the public key to verify the signature. Or, others use the public key to encrypt something, and you use the private key to decrypt it.

[1]:

To use different keys for signing and encrypting
to mitigate the effect of lost/stolen keys (see also)
(TODO: continue list with more)

[2]: Superuser thread: Where to upload PGP public key? Are KeyServers still surviving?

... is my understanding correct that primary keys and subkeys are all
key pairs consisting of a private and a public key?

Absolutely. Sometimes to keep it simple we say "key", where as actually we mean "key pair".

... handling the public primary key? Is this the one that should be
shared with others or uploaded to a key server?

Correct. The public key of the master key pair is what proves that the signatures associated with this public key was made by you. That's why you make the public key of your master key pair available publicly.
How can one trust your subkeys? When you are using subkey, you provide also certification signature that shows that particular subkey (namely, the public key of subkey pair) is signed by your master key.
The idea behind this is following: When one trusts your master key, then one trusts subkey signed by this masker key.


Legacy system PCI Compliance I have a legacy system that collects and stores credit card numbers ( BAD! ).  We are in the process of replacing that system in phases.  We are going to integrate with a credit card processing system that requires us to be Level 4 Compliant.  The new system will not do the bad stuff ( storing credit card info ), but both systems will run on our network at the same time.  Will I be able to achieve PCI Level 4 for the new system so that we can do the integration even though the old legacy system is still running?

Read the document:  https://www.pcisecuritystandards.org/documents/PA-DSS_v3.pdf

On page 7, there's a table that outlines what you can and can't store.  If your legacy system only stores the allowed data, then you can theoretically get compliance, but you'll have some really really really strict security requirements for your network and systems.

IMO, it's just not worth it to do your own CC transactions in-house, unless that's your primary business.


How do I protect user data at rest? I want to encrypt the username, email, and password fields in the database AND encrypt user files at rest. How can I do this? I am aware of software such as Gazzang and since there is not cost published I can only figure that it will cost thousands of dollars each year.

Is there any alternative solution that I can build myself OR use a software that runs on the server that can encrypt the fields and the user files?

Not sure if it makes a difference but I am using PHP/MYSQL and I have cloud servers.

The simplest method of encryption  on a mysql server is aes_encrypt() using a randomly generated passphrase.

You should not encrypt user passwords,  passwords must always be hashed.  Passwords should be stored using bcrypt or sha256.


Credentials in URL for Python "Requests" library Will using the following code result in credentials being passed in the URL?
I know it is a GET method, but how does the python requests library process this?
Does it attach it to the URL or attach it to the headers?Any secure alternatives to using this?

from requests.auth import HTTPBasicAuth

requests.get('https://example.com/', auth=HTTPBasicAuth('user', 'pass'))

HTTP Basic authentication does not pass the credentials in the URL but in an Authentication header field. The credentials are only base64 encoded and not encrypted, so it should only be used over HTTPS - which you do here.


Is it possible to forge a post request? Consider the following URL http://mysite.com/form?date=x. Suppose that if x is in an incorrect format, that a page is returned with
x is not a valid date
, where the page author has forgotten to escape the variable x. Assume that x is properly escaped in all other locations.

It is possible to create a malicious link that could insert arbitrary Javascript with access to the user's credentials. What if the site required a POST rather than a GET? Would there a way to exploit this security hole?

UPDATE: Changed the situation to be more realistic and removed irrelevant references to clickjacking

Clickjacking is an attack which tricks the user to click on something he is not aware of. It is usually done by loading the attacked page into a transparent iframe. This iframe is scrolled to the correct location and kept below the mouse pointer.

A function that is often attacked by Clickjacking is the Facebook like-button.

While clickjacking does work for POST, a simple attack does not allow the attacker to manipulate the URL or form parameters.

Cross site request forgery is the name for the attack that uses the vulnerable site as target of a form on the attacker site. This form can be totally invisible and submitted via JavaScript automatically. All common browsers will include the session cookie for the target site in the request.

Cross site request forgery attacks are prevented by adding a hidden form field with a random value. Unless there are other vulnerabilities a CSRF attack is done blindly, so the attacker cannot read that hidden value.

In your case, even if the form is protected with a random CSRF prevention-token, you should still fix the cross ite scripting bug because there may be other vulnerabilities. Attacker can be very creative in combining minor vulnerabilities to a full exploit.


Bypassing XSS filters Possible Duplicate:
  New XSS cheatsheet?

Can anyone give me list of ways to encode XSS payload , or to be precise what are the ways to encode XSS payload to bypass encoding of <> or ().
I know about double encoding bypass with %253c and Unicode , but I want to know all methods available. Thanks

I don't think it would be a wise idea to give how-to's on XSS attacks; though many resources exist e.g. Ch. 12 of the WAHH on XSS.

The best way to prevent XSS attacks is to substitute every special character used in these attacks (e.g., <, >, &, ",'  with their html character equivalent &lt;, &gt;, &amp;, &quot;, &#39;) for all user-provided text and only allowing users to markup their comments using a limited non-html markup language (like markdown) that only gets substituted into a safe subset of html at the last step of processing.  (Also be careful their comments never get executed in any sort of javascript processing  you wrote).

If you choose to ignore this, and only sanitizing specific tags (like <script>, <object>, javascript check the sanitation is being done recursively (so <scr<script>ipt> doesn't become <script> after a single-pass sanitation), is case/white-space insensitive, and only stops when the last complete sanitation attempt did not change the input.  In python something like

import re
def sanitation_single_pass(user_input):
    pattern = re.compile('<[^>]*(script|object|meta|style)[^>]*>', re.IGNORECASE)
    # this is very quick sample regex that could appear in a sanitation routine
    # not meant to be inclusive of most XSS threats;
    # e.g. this doesn't prevent having javascript in links or img src, etc.
    return pattern.sub('', user_input)

def sanitation(user_input):
    processed_user_input = sanitation_single_pass(user_input)
    while processed_user_input != user_input:
        user_input = processed_user_input
        processed_user_input = sanitation_single_pass(user_input)
    return processed_user_input

Also pay attention to encoding issues, make sure you define a charset (<meta charset="utf-8"> at the top of your html templates) and that you force user input into this encoding before sanitization.  Also try to recognize that some browsers will interpret things like java&#x0A;script as javascript (&#x0A; is a line break), etc.


How does EAP/PEAP integrate with modern security protocols? How exactly does Extensible Authentication Protocol (EAP)/Protected EAP integrate into modern security protocols?

What I know (or not know) so far...

It's used by wireless networks utilizing authentication methods based upon Point to Point Protocol (PPP).  I have searched, but can't find an answer that makes sense to me.  The name implies that it's a protocol, but from what I've read the articles call it an Authentication Framework.  There are definitions of all the major security protocols/algorithms; e.g. MD5, SHA1, ISAKMP, TLS, etc.

I've tried looking at wireshark captures with EAP data traffic.  CloudShark Example.  But the descriptions of the data are less than helpful.  Here is a description of the "protocol's" data flow.  The picture is quite helpful, but what confuses me is the exchanges of "EAP Methods".  Which seem almost analogous to SSL/TLS cipher suites.

Is EAP a way for wireless protocols to agree on algorithms, and each device provides their own implementation conforming to this framework?

In which case, why is there an EAP-TLS?  This seems to put another added layer onto the wire for just performing TLS.  Can someone fill in the gaps for me?

Your understanding is already pretty good. As you say, there are a variety of EAP protocols: LEAP, PEAP, EAP-FAST, EAP-TLS, etc. Each one works differently, but they all do the same thing: authenticate a user before allowing them access to a wireless network. You could call EAP a protocol, or you could call it a framework of protocols, where each variant like EAP-FAST is a protocol. It doesn't make much difference, and I find that different documents are not always consistent with each other (or even internally!)

To answer your bolded question, basically it's yes. A client and access point will have certain EAPs enabled, and if they support the same one, the client can try to authenticate. Each EAP is a protocol, and will have different implementations. e.g. if your iPhone is logging in to your Cisco access point using EAP-TLS, then Apple EAP-TLS is talking to Cisco EAP-TLS - and because the protocol is standardised, they (should) communicate successfully.

Why is there an EAP-TLS? Remember, that the EAP occurs before the client is allowed access to the network. At that point they don't have an IP address, so it's not possible to use normal TLS. I think re-using TLS as a part of EAP is a very good idea - the security requirements are very similar for EAP as for HTTPS, so it makes sense to use a protocol that's mature (despite recent revelations!).

One challenge for EAP-TLS (and PEAP) is that the process of certificate issue and verification is less clear. Normally the network administrator needs to install the access point's certificate on all clients. If certificate verification is not done, then the clients are vulnerable to an Evil Twin attack.


How the NSA can break trillions of encrypted Web and VPN connections Based on Diffie-Hellman's negotiation of key exchange, why would it turn out that only a few primes are commonly used?  What and who determines the prime?

Would it not be safer to use a safe prime? (example: p = 2q + 1)

*The question is based on this article:

http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/?utm_source=pocket&utm_medium=email&utm_campaign=pockethits

Edit #2 (11/09/15) - I read through a few articles and a paper. See down at bottom for more comments.

I read the article, although I have no direct data on the following, so guess work on my part.

There are a combination of factors going on here.

Nature of DH exchange.
Pre-provisioned Keys.
Unchangeable of Keys.
Known attacks on DH algorithm.

DH Exchange

The exchange requires that the two parties have the Base Prime. It ought to be a Safe Prime (or Sophie-Germain Prime). If the client doesn't have it, the server will send it over. Both parties should use secure random number generators to create their exponents. Computations should be structured such that successes and failures take the same amount of wall clock time.

Pre-Provisioned Keys

Generating large Primes is not hard, but it is for the uninitiated. Having a piece of software that does it for you is best. That software must use a secure random number generator. Most people will just use whatever keys (primes) that have been pre-provisioned out of habit, ignorance or laziness.

Unchangeable Keys (Primes)

It's entirely likely that much of the software in question wasn't engineered to allow a Prime number change. Engineers who author the software are often as ignorant of proper security methodology as the users. I don't mean that pejoratively; ignorant as in "lack knowledge".

Known DH Attacks

Where to start!

A shorter key (768) was well within the ability for a couple of graduate students to compute partial discrete log matrices and attack Sun's network password authentication scheme a couple of decades ago. See reference at end of this Answer. I wouldn't be surprised if the NSA (or anyone) has the ability to compute partials for known 1024 bit keys, today.

The protocol can be attacked by replacing the Prime in transit to the client if the client doesn't have the Prime and requests it from the server.

Even better, DH is subject to man-in-the-middle attacks, especially with a client that requests the Prime from the server, but even if it doesn't. The DH algorithm relies on secure exponents being computed. However, it doesn't rely on any other data - server and client need not prove each other to establish a secure session. If somehow the client's password (or a hash of it) were mixed into the DH key negotiations without any information leakage and retaining perfect forward secrecy, then the client could be assured the server was legitimate. Look up the SPEKE and DHEKE algorithms for a start on this. In any event, NSA as MITM creates two DH sessions, one with the client and the other with the server and records all data while piping between the two. Easy peasy.

The article states that NSA relied on well known Primes to attack the sessions. I refer back to the paper I mentioned about computing discrete log partial matrices. If possible now with h/w advances, 1024 bit keys wouldn't provide secrecy from observer attacks.

Who's to say the machines running the DH algorithms weren't compromised in some other way? Perhaps, they leaked key data or gave it up when queried in the right way? There has been so much information published about how every piece of computational h/w can be compromised by the NSA, perhaps they didn't bother breaking the algorithm unless they needed to, and instead broke into the machines and got the session encryption keys directly?

Edit

Other DH attacks:

Introduce a Prime that is not Safe (doesn't conform to Sophie-Germain Prime criteria of P=2Q+1, where Q & P are Prime). An unsafe Prime P (Q is not Prime) limits the range of the DH function, thereby simplifying observer attacks (discrete log calculations), sometimes trivially. In the context of the algorithm g^(A*B)%P should map 1:1 or 2:1 over the field of P; a bad P can map large swaths of numbers to a computationally feasible small set.
Rely upon poorly coded DH algorithms which allowed (or forced!) small exponents, making attacking the session easier.
Rely upon poorly coded secure random number generators and/or poorly seeded RNGs (ones that used current time or process ID).
Timing attack in which an observer watches how hard (measured in time) a participant works to compute a result and guesses based upon the work properties of the keys (uses that information to break the keys). This is a general attack, not specific to Diffie-Hellman.

Edit #2

I read an article linked through and the twelve author paper posted.

As suspected above, here's the gist of it. At the end I'll add a little bit more on TLS+DH+RSA cipher suite, just to show another vulnerability.

First off, it appears likely that the NSA has broken a number of the commonly used DH Groups (Safe Prime P + Generator g) used for Diffie-Hellman key exchange. As I indicated above, at least a decade or so ago, this attack was completed by a couple of graduate students (still don't have reference) on Sun's 768 DH key used for network password authentication.  The attack is an observer attack, so no man-in-the-middle needed. The work required to break any particular Group is quite large. However, once broken, all exchanges using that can now be compromised.

Theoretically, DH key exchange provides Perfect Forward Secrecy (vs. RSA which does not).  Once the a DH group is broken, any exchange using that group not is compromised going forward, it's also compromised going backward (ie. recorded exchanges can be broken), so no more perfect forward secrecy for that group. It also means that a dedicated attacker could break uncommon DH keys. This is assumed to be possible for 1024 bit keys, so up your key lengths to 2048 for DH. You should already be using larger key lengths for RSA.

Next, the researchers make a number of notable points.  The paper covers Logjam, which I won't explain in detail except to say it's a MITM, cipher suite downgrade attack.  Clever, but not algorithmically complex.

I strongly urge anyone interested to read the paper. It's fantastic. Here's the second paragraph of the Abstract.

  We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We
  estimate that even in the 1024-bit case, the computations are
  plausible given nation-state resources. A small number of fixed or
  standardized groups are used by millions of servers; performing
  precomputation for a single 1024-bit group would allow passive
  eavesdropping on 18% of popular HTTPS sites, and a second group would
  allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH
  servers. A close reading of published NSA leaks shows that the
  agency’s attacks on VPNs are consistent with having achieved such a
  break. We conclude that moving to stronger key exchange methods should
  be a priority for the Internet community.

That pretty much says it all.  Fixed keys, broken by the NSA allows observer (passive) breaking of many of the secure networking protocols. So, don't use pre-provisioned or common keys (if possible) and/or up your key lengths.

As for the TLS+DH+RSA cipher suite, is this safe at higher key lengths?

I would hazard that it is safe from an observer attack, however, it's still subject to man-in-the-middle attacks and here is how.

In this mode, the Server signs its DH ephemeral with its RSA key (Sign((g^B)%P,RSA_Key_Server)). That means, the server's portion of the DH exchange is authenticated. Assuming the signature is valid when it reaches the client and the Server certificate has not been revoked, the client can proceed safely with the DH exchange knowing only the server can complete it.

How, then, is a MITM possible? Two ways, one more likely than the other.  Both rely on the client failing to do a proper signature check.

First, the client has too many root certificate authorities in its key store (many browsers have over 100). Some of these root CAs are not trustworthy. MITM gets a server cert for the remote site in question, sits in the middle and signs with its own cert (Sign((g^B2)%P,RSA_Key_Middle_Server)). The client will validate the signature, assume the server is authentic and complete the DH exchange with the server. Meanwhile, the middle server can run its own client side of the exchange with the real server and watch all data in between.

Second, I think this is less likely. The client fails to check for a revoked certificate and the MITM has the revoked private key, so it can sign as if it were the original, real server. Client won't know because it didn't check revocation. Middle server, again runs another DH exchange with remote, real server and sits in the middle.

Moral of the story is watch your client configurations and up your key lengths.

EDIT #3: Found the reference to the DH attack a couple of decades back:

  B.A. LaMacchia and A.M. Odlyzko. Computation of discrete logarithms in
  prime fields. Designs, Codes, and Cryptography, 1:46-62, 1991.


Clarifying self-signed certificates vs root certificate authority I hope someone can help me understand some fundamentals on SSL certificates that I've had trouble picking up from docs, Wikipedia, and just about everywhere else on the internet.

I'm working on an application that communicates with another on a separate network. Each application acts as both a client and a server in bi-directional communication. They will use REST services over HTTPS with each network's firewall opened explicitly for the other. All SSL certificates will be self-signed. My application is written in Java but I'm not sure about the other.

I believe I have two options to establish the HTTPS connections with self-signed certificates:

Each application's underlying Framework (e.g. Java) installs the other's self-signed certificate, resulting in that framework, and not necessarily the wider OS, trusting the certificate
Each server installs the other's certificate as a root Certificate Authority and therefore trusts any self-signed certificate produced by the other server. A framework like Java should acknowledge this OS-level root Certificate Authority but a web browser on that server might not as it maintains its own database

The server I'm working on has the following files already generated: server.crt and server.key. I believe these are generated using openssl genrsa. I understand that the .crt is the public certificate and the .key is its private key counterpart. My main question is

Can the .crt be treated as either a framework-level certificate or an OS-level root Certificate Authority by the other server (i.e. do I get to choose how I install it)? In my research online this has been very confusing as many of the terms seem overloaded. I can't tell if I'm working with a Certificate Authority or just a regular certificate.
If the answer to 1 is no, what kind of file do I need to generate from the existing files to install just the self-signed certificate?

Any help much appreciated, and please assume that providing links to Wikipedia pages will not help me much.

You should see the certificate infrastructure (that is to say the PKI, Public Key Infrastructur) as a web of trust.

When you are communicating with multiple persons, which wants to mutually authenticated themselves (and their websites), you first choose a common trusted person. This third person becomes a "Trusted Third Party" and will be called the "Certificate Authority" (CA) for the purpose of certificate management.

The CA will create a master key, also known as root CA key. The private key will be kept secret by the TTP at all cost. The public key will be embedded into a certificate, and this certificate will be signed by the public key of the CA. This means the certificate is self-signed and you can verify the signature with the key inside it.

Let's assume now that you want to access Alice's website, but you want it to really be Alice's website and not another person that claims to be her. Alice is part of you community and therefore contacts the CA you agreed to use. She sends the CA a CSR (Certificate Signing Request) which basically is a public key. The CA do the process of verifying that Alice is Alice (for example, the responsible person meets Alice in person and get the CSR from her hands). When the CA is sure Alice is Alice and the CSR belongs to her, the CA can create a certificate in the name of Alice and sign this certificate with the CA private key.

When you connects on Alice's website, you ask for the certificate. Once you get the certificate, you want to verify it's the good one. You can see in the certificate that it has been issue by a CA. If you have the CA key you can verify the signature. If you trust the CA is doing its job correctly, then you can trust that this certificate is a good one and since the CA trusts it authenticated Alice in the first place, then you can trust that this certificate belongs to Alice.

You can then be sure that encrypting a message with this public key will only be read by Alice who has the corresponding private key. You are also sure that anything singed by this certificate is a signature made by Alice.

If Alice wants to authenticate you in return, then you need to do the same things (get a certificate signed from the CA, since Alice trusts the CA as well she will trust this certificate)

In your case, since it seems you master all the endpoints, you could simply create two self-signed certificates (which are in fact two root CA certificates) and exchange the public parts to the other endpoint. Each endpoint will use their own private key to sign outgoing requests and decrypt incoming messages, and the other endpoint certificate to encrypt outgoing message and verify incoming messages.

If you happen to have a lots of endpoint, it could be worth to create your own CA. You generate a root CA certificate then you sign certificate for each endpoints. At each endpoint you can install the public root CA cert. Then each time a endpoint connects to another, the contacted endpoint can send its certificate and the caller can verify it against the root-CA cert.

The first method has the advantage of being straight forward, but compromising of one certificate implies to exchange it for a new one on all endpoints. The second method has the advantage to be scalable, one endpoint does not have to know how many other endpoints exists since it can validate the certificate on the fly anyway. Moreover there are way to manage key compromising with Certificate Revocation Lists for example.


Are there any two way + two factor authentication systems in use? My bank, Google etc. use two factor systems where they send me a One Time Password via out of band means. e.g. SMS or an App on my Cellphone or a standalone RSA token generator.

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access.

I was wondering, would it be safer if the genuine log in page was supposed to also display a short, time-dependent reverse PIN  that I could then match against a similar PIN on my out of channel device before I entered the real PIN on the website. Would that be a good way to verify that the site asking for the token is authentic?

Is this naive? Or would it improve things? If so, is it already being done by any sites / protocols?

PS. I think the secure fobs like FIDO U2F etc. do take care of this. But I am thinking of a way to secure a legacy SMS / Android app system that generates the 2nd factor.

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access.

This is what x.509/TLS certificate is supposed to prevent. If:

you trust the underlying mathematics of x.509 certificate and TLS,
both the server and the client has implemented TLS correctly,
the client machine trusts the server's CA (i.e. the CA's root certificate is in the client's trust store),
you trust your browser vendor's CA vetting process (or you have audited the trust store) and you trust the CA certificate issuance process,
you trust your browser to validate the certificate, such as checking the certificate's CN/, expiry, revocation list, etc,
you trust that the server have implemented precautions to control against its private key being misused,
you believe that the domain name belongs to the organization that you want to communicate with,
the server passes the TLS handshake,

then you can be confident that the server on the other end is who you think it is.

In any case, if the machine that runs the client you're connecting from is compromised, you're screwed anyway since you'll be entering both your credentials and OTP using the machine.


Worst-case scenario OPEN URL REDIRECTION and why google not covering it in bug bounty OPEN URL REDIRECTION as per in my opinion can be proved very dangerous by crafting attacks such as phishing.

But it seems like google thinks it as a very low level bug and does not provide any monetary reward for this. So my question comes here into play what the worst case scenario can happen with open url redirection .

  1> Can i run some system commands by webpage ?

  2>If it found in any login page (because login pages mostly redirect
  after entering credentials) which is using HTTP not HTTPS, can the
  user sessions be hijacked or Can the credentials be stolen

  3> Can the victims traffic be routed as desired (by acting as a proxy
  by malicious user or generally MITM) .

In my opinion i know possible attack vectors are

  1> Victim can be tricked by phising ,

  2> Root access by serving some browser exploits ,

  3> Victim can be made a part of BOT network by opening a connection to
  some IRC.

You seem a bit confused about the concept. An open redirect is just a redirect. You browse to http://google.net/redirect?http://stackexchange.com and it tells your browser: please go to http://stackexchange.com.

That it is an open redirect means that I can make it send you to anywhere (like an attacker web page), usually by embedding in the link the page where you will be sent.

  1> Victim can be tricked by phising

Yes, it is possible that the victim saw a link to google.net and then thought he is visiting that site (and thus blindly enters his google credentials), without noticing that the url now shows evilattacker.com.

  1> Can i run some system commands by webpage ?

I wouldn't consider the above like running system commands. It may be possible to use an open redirect to bypass the same-origin policy protections, though.

  2>If it found in any login page (because login pages mostly redirect after entering credentials) which is using HTTP not HTTPS, can the user sessions be hijacked or Can the credentials be stolen

Mostly no. Unless the redirect back (ie. when it sends you back to the attacker-controlled url) is added a token, or there is some information in the Referer header (a token, your user name…), the final page doesn't gain any additional privilege from having made you login, as it will be handled by cookies that aren't sent to the attacker page.

  2> Root access by serving some browser exploits ,

This is incorrect. If your goal was to serve the browser an exploit, you could have done that directly. Remember that the first step is to make the user follow an attacker-controlled url. The open redirect may help you trick the user (see 1), but Root access can't be considered a consequence of an open redirect.

  3> Can the victims traffic be routed as desired (by acting as a proxy by malicious user or generally MITM) .

No. The server doesn't act as a proxy (getting content in your behalf and passing it to you), just as a redirector: sending you somewhere else.

And specifically:

  3> Victim can be made a part of BOT network by opening a connection to some IRC.

An open redirect doesn't allow you to connect to irc, as the browser won't be able to follow an irc:// link (if it is able to handle it -most won't-, that would launch an application/plugin, not automatically connect you¹).

¹ And connecting to irc doesn't automatically compromise you, anyway.


X.509 Why is the signature algorithm added twice in the Attribute Certificate? As I read some parts of the X.509 specification I found the signature added twice - first in the AttributeCertificate as signatureAlgorithm and second in the AttributeCertificateInfo as signature. Could you explain me why? The same goes for the Basic Certificate Fields.

  signature: This field MUST contain the same algorithm identifier as the
     signatureAlgorithm field in the sequence Certificate

AttributeCertificate ::= SEQUENCE {
  acinfo               AttributeCertificateInfo,
  signatureAlgorithm   AlgorithmIdentifier,
  signatureValue       BIT STRING
}

AttributeCertificateInfo ::= SEQUENCE {
  version                 AttCertVersion, -- version is v2
  holder                  Holder,
  issuer                  AttCertIssuer,
  signature               AlgorithmIdentifier,
  serialNumber            CertificateSerialNumber,
  attrCertValidityPeriod  AttCertValidityPeriod,
  attributes              SEQUENCE OF Attribute,
  issuerUniqueID          UniqueIdentifier OPTIONAL,
  extensions              Extensions OPTIONAL
}

This is a remnant of some old fears. Peter Gutmann's X.509 Style Guide, an old (2001) but instructive read, includes the following paragraph:

  This rather misnamed field contains the algorithm identifier for the signature
  algorithm used by the CA to sign the certificate.  There doesn't seem to be
  much use for this field, although you should check that the algorithm
  identifier matches the one of the signature on the cert (if someone can forge
  the signature on the cert then they can also change the inner algorithm
  identifier, it's possible that this was included because of some obscure attack
  where someone who could convince (broken) signature algorithm A to produce the
  same signature value as (secure) algorithm B could change the outer,
  unprotected algorithm identifier from B to A, but couldn't change the inner
  identifier without invalidating the signature.  What this would achieve is
  unclear).

So one might infer that, one day, probably around a coffee machine during a pause between two meetings, somebody made an elaborate but not really funny crypto-joke, and it was overheard by somebody else, who did not get it, and proceeded to stir up feelings of anxiety somewhere in the dark corner of a sub-committee. More generally, X.509 makes a lot more sense if you read it as Mary Shelley's draft notes for "Frankenstein", translated for some reason into ancient Ugaritic.


Ways to inject malicious DLLs to exe file and run it I'm trying to find all vulnerabilities in my given system.

Assume a malicious user has the executable (.exe file) of my .NET application (C#), and a malicious DLL he or she created. Can the DLL be injected into my executable to run code contained in the DLL?

The wikipedia article concerning Dll injection has nicely done summary of different techniques.

To summarize:

You can list a dll under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs and it will be loaded into every (new) process that links to user32.dll (i.e. pretty much every user-mode process)
Exploiting a weakness in a function that loads a library by path incorrectly (typically, placing a dll loaded by the target process higher in the search path) or simply replacing an existing library by your own.
Via CreateRemoteThread or CreateRemoteThreadEx. This is a bit more complex (and interesting) but lets you do that for existing processes.
Via SetWindowsHookEx. This is the easiest way to do it for a running process IMNSHO.
Suspending a thread and switching its context to your own code.
Writing a shim.


How to prevent CAS from leaking user identity to arbitrary visited websites? Summary

evil.example.com could use a hidden frame to request a CAS ticket from corporation.example.net, then validate it to receive the username of the hapless user. This effectively deanonymizes the CAS user to any malicious site they visit.

As a CAS server author/maintainer, how can I prevent deanonymization of my users?
As a CAS user, how can I prevent deanonymization of myself?

Background:

CAS (Central Authentication Service) is a single sign-on system with a redirect-based flow:

Client page redirects to CAS server with a service parameter that is the URL of the client site.
CAS server authenticates user via an existing cookie, a login page, etc.
CAS server redirects to service URL with ticket parameter appended.
Client calls a server validation endpoint, exchanging the ticket for a username.

Attack

User has already authenticated with corporation.example.net's CAS server and their browser has the ticket-granting cookie for that domain.
User browses to http://evil.example.com/dancing-bunnies.html, which embeds http://corporation.example.net/cas/login?service=http://evil.example.com/attack.html as a frame. (Framing is less conspicuous than a redirect -- there's no security difference.)
The CAS server's /login endpoint in the frame sees that the user-agent already bears login cookies, so it blindly redirects to the service URL, plus a ticket: http://evil.example.com/attack.html?ticket=ST-abc123
evil.example.com reads the ticket from the querystring and GETs http://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123, which responds with yes\nalice\n.
evil.example.com now knows that the user is alice @ corporation.example.net.

Possible amelioration

Restrict the domain on service parameter URLs to a known safe set
Require user interaction before redirect back to client
Forbid framing (either with headers or scripting)

Any downsides to either of these? Are there other solutions?

Notes

Restricting the service parameter to a string-match on a set of known safe URLs is probably impractical, since it's used by clients to carry state through the redirect process.

ETA: I will be very sad if your answer assumes the following...

...that the attack relies on cross-origin communication.
...that I'm claiming that this does anything other than deanonymize the user

Disclaimer: I don't know CAS, but I think I understood what it does and how it works.

Your attack scenario is not possible this way - even if the corporate website would not have frame busting headers. These frame busting headers are more to avoid click-jacking, but that's another topic.

If the frame does a redirect, then only the frame content is redirected.

The evil site cannot access the anything of the frame it embeds (not even the URL), because it's in another site. If it could, then such scenarios would be possible, but all modern browsers (even since IE4 I think) disallow cross-site access, so the evil site cannot access the new URL and therefore has no access to the identified user of the IFRAME.

As a user you can protect yourself by always logging out and if any suspicious site asks for permissions, don't authenticate.

A good example of this scenario you mention is Facebook. Many sites embed Facebook commenting functionality and other stuff. But they don't get your user name in any way. If it would be possible to get the Facebook user name somehow (Facebook users rarely log off) then this would be a big security hole. You could apply for the bug bounty if you'd find a way to get it or to log on and post or vote in the name of the user.


Basis Authentication Protocol: a concrete attack Below is an informal protocol narration of a simple authentication protocol. A sends to B a signed hash of message M, B's name and a nonce N. B knows that the message M is intended for him, that it originates from A and that it was sent as part of the same run.

A -> B: (M, A)
B -> A: N
A -> B: {| #(M,B,N) |}sA

But what will happen if we omit B's name?

A -> B: (M, A)
B -> A: N
A -> B: {| #(M,N) |}sA

I cannot think of a concrete scenario with a harmful attack. What attack could cause harm? A possible scenario is listed below:

A -> B: (M, A)
B -> A: N
A -> I: {| #(M,N) |}sA
I -> B: {| #(M,N) |}sA

There is no proof that the message was intended for B. So, intruder I can intercept the message signed by A and redirect it to B, authenticating I as A. But what is a harmful attack? For example in a bank-client interaction scenario?

Thank you.

There is no proof that the message was intended for B. So, intruder I can intercept the message signed by A and redirect it to B, authenticating I as A. But what is a harmful attack? For example in a bank-client interaction scenario?

If I understand you correctly, you've just described the first part of a Man In The Middle (MITM) attack.


What is binary executable randomization? I am trying to get more information about binary executable randomization that is used for increasing uncertainty for attacker toward software vulnerability. I've been searching on Google but still couldn't find a clear explanation. Can someone provide an explanation of a link that can help me understand this?

My guess is you're looking for the term ASLR. The techniques mentioned in the comments are for completely preventing things like ROP gadgets. ASLR will jumble the layout of the program in memory, so an attacker cant easily say "the return address i need to overwrite to redirect the control flow of the program is at offset X past the buffer i overflowed"


Securely identify clients by web app I have a web service S that provides certain services. There are two web apps, A1 and A2, both on different servers within the same VPN, which I trust and want to grant access to my web service.

+------+     HTTPS   +-----+     HTTPS   +------+
|  A1  | <---------> |  S  | <---------> |  A2  |
+------+             +-----+             +------+
   ^                                         ^       VPN
. .|. . . . . . . . . . . . . . . . . . . . .|. . . . . . . .
   |                                         |       Internet
   |          +----------+                   |
   |        +----------+ |-------------------+
   +--------| Browsers |-+
            +----------+

However, I want to be able to distinguish in S between clients A1 and A2. A1 might not have the same privileges in S as A2. Moreover, I can't be sure there might not be some other web app A3 around that some evil guy installed in the same VPN. So, the basic problem is that S needs to know who it's talking to.

Some more clarification: A1 is JavaScript-based. A JavaScript in a browser is talking to the web server A1. The JavaScript is never directly talking to S, however. The web server A1 has some means to forward messages to S, e.g. a simple PHP script. There is probably no way to block evil users from contacting S through A1 in the same way as the JavaScript does. To prevent abuse of this, S is a session-based service that requires a username and a password to generate a session key. Browsers pass the session key to A1 or A2, which then pass it on to S.

The question is: How can S safely identify A1 and A2 and block any other calls?

Define rules based on API keys (Something like RESTful API)

A1SA2

If no one hacks the https connection the keys are ok
Ex: https://S/req?api_key=A1&contet=action


How to prove ownership of a website? We all know how banks identify themselves to users. No, not through TLS certificates. The users pay no attention to those. No, I'm talking about branding-- all those fancy logos and stock photos that give you the impression it's your actual banking site.

The trouble is that anyone can copy those images for themselves and make a convincing fake of a bank's site, and trick users into entering their banking password, even though the site they're on is the wrong domain. This is why phishing works.

So since users don't check the domain name or TLS certificate chain, how else can we prove, before they enter their password, that they're on a site they should trust? (e.g., showing an image the user could recognize, but a third party would have trouble forging, like a reverse captcha)

(P.S. The obvious alternative solution is not to require a password at all, like in Google Authentication, but I'm retrofitting a set of websites and I'm looking for alternatives.)

I know of one that let's users upload a picture of their own choosing when the account is set up. (They can change it later.) The picture is shown on the password screen, after the user ID is entered. Wrong or no picture == fake web site.

You would want to use  a back-end program to make the pics a standard size and to strip out meta data before storing them.


Security Implications of Microsoft BITS - Background Intelligent Transfer System: Use, Abuse, Limit & Remedy? I use Networx - to manage and monitor my machines network connection. It shows real download speeds and active network connections.

So, a few times all of a sudden I got these downloads and I was not downloading anything, or using the browser and even my Windows Updates are disabled.

So Networks shows it as a connection through BITS.

  TCP   PC-MACHINE-NAME: 1650
  server-54-230-186-238.cdg51.r.cloudfront.net: https
  ESTABLISHED   88.0 KB/s

But I had no way to see what BITS was downloading. So, I went online and found some applications built on top of BITS.

One of these applications called BITS Download Manager shows me what BITS is actually downloading.

  https://clientupdates.dropboxstatic.com/Client/DropboxClient_xxVerNo.exe

I am wondering about the Security Implications of BITS being used and abused by legitimately and wrongful ways?
Also, is there a way we can disable or limit access to it in some fashion, to some degree - as a Rememdy?

I am wondering about the Security Implications of BITS being used and abused by legitimately and wrongful ways?

BITS by itself does not provide any kind of security. It is just a service to provide background up- and downloads and any kind of security must be added by using the relevant protocol (i.e. http vs. https) or validating the transferred content in the application (i.e. signatures).

There are no special privileges to use BITS. So it is possible for malware to use BITS too and this is also used in practice. For more information do a simply search or see for example Malware Lingers with BITS:

  Malware authors and intruders have abused the service since at least 2007.


Validate individual hardware components process UFEI Secure Boot does not validate individual hardware components (SSD/hard drive, networking chips/card, video card, etc.) that can get infected.

Is there anything currently available that's able to do that? If there isn't how would you implement it yourself?

Nothing that can fully validate all components which exist in a general use system.

That is because components such as hard drives and video cards have their own firmware which they run. This firmware is the target of the attack, and there is no standard verification which all components in order to validate their state.

Chromium and the line of Chromebooks are one step better than secure boot. They offer something called verified boot which does a great job of detecting tampering.

https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

The downside is how limited Chromebooks are as general purpose computers.


Safely decrypting an unsolicited/untrusted PGP message I am accepting public security vulnerability reports for my website, and I publish my personal PGP (GPG) key to encourage people to encrypt their communications.

Upon receiving an encrypted message, what is the best way to safely decrypt it?

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

I know that sometimes text can 'leak' out of command output into the prompt, meaning that pressing enter again would potentially execute arbitrary commands set by the attacker. One possible way to mitigate this is to completely end your session or close your terminal emulator and start a new one.

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

Thanks

##Dangers of printing untrusted text

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

When outputting arbitrary text to a terminal, as GnuPG does by default, you are risking the exploitation of your terminal emulator. New vulnerabilities regarding handling of untrusted text being printed are found all the time, and while the most severe vulnerabilities have been weeded out, they are still an issue. One solution would be to pipe the untrusted output through a command that strips non-printing characters.  You can use cat -v for this purpose. From section 3.1 of the coreutils GNU Info page:
-v
--show-nonprinting
    Display control characters except for LFD and TAB using ^ notation
    and precede characters that have the high bit set with M-.

Printing untrusted text while stripping non-printing characters should prevent exploitation of your terminal emulator through mishandled control codes or any other typical avenue of attack.
$ gpg -d untrusted.gpg | cat -v

##Dangerous of decrypting untrusted messages

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

This is also a risk. GnuPG is incredibly complex, and any parsing of complex data can lead to exploitation. The only solution would be to run GnuPG airgapped, or in a tight sandbox or properly isolated virtual machine. GnuPG v2 has improved its architecture, allowing the decryption to occur in a process which has no access to your private key, but this is far from a complete sandbox. In general, you should always assume that a sufficiently competent attacker will be able to exploit GnuPG through way of providing you with a maliciously malformed encrypted message.
A quick search turned up several bad vulnerabilities in GnuPG in the past 10 years:

CVE-2008-1530 - Memory corruption via duplicate keys from keyservers allowing code execution.
CVE-2010-2547 - Use-after-free vulnerability in certificate parsing allowing code execution.
CVE-2013-4242 - Side-channel attack revealing private key information to local processes.
CVE-2013-4576 - Side-channel attack allowing acoustic cryptanalysis during RSA decryption.
CVE-2016-6313 - Broken RNG leaking 160 bits of random material, weakening certain key types.

##But what is the actual risk?

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

An airgapped machine would do nicely, but may not always be an option. There is no need to securely erase the messages afterwards, as an unlinked (deleted) message poses no risk. The only reason to try to securely delete something is if you do not want it to be available through forensic analysis.
Overall, the actual risk should be fairly low. Exploiting a popular program requires a certain level of expertise which is unlikely to be used to compromise you through your website unless you are high profile, or very unlucky. There are easier ways to be compromised through an exploit that via GnuPG messages (for example, hyperlinks to compromise your browser, images to compromise image parsers, etc). Even so, there are a few things you can do to reduce this risk with regards to GnuPG:

Decrypt messages using an unprivileged, or better yet dedicated, user.
Strip control codes from decrypted output. Never view raw output with vim, less, etc.
Keep GnuPG up to date at all times so known vulnerabilities will be patched on your system.
Use the virtual terminal and not a terminal emulator. Never use xterm or related forks.
Use AppArmor or similar on GnuPG. Do not run it under a user with X11 access.


Is cell phone number based verification secure? Websites often send a code to a cell phone number for verification. Is this secure? If it is not secure, are there any better alternatives?

If it is not secure, are there any better alternatives?

It's secure for certain threat models, and the best tradeoff for accessibility vs attack surface. To intercept an SMS, you have to have some control over the routing of the messages or the device receiving it.
Without privileged information / insight provided at the carrier level, SMS is the best authentication method available despite its flaws including convincing users to send a 3rd party the code when they receive it.
If you need a stronger confirmation of some kind of connection between identity and a user online, you probably require something that's not a phone to be involved. Mailing a hardware token that is paired with a code displayed to the user is more secure, but it's also more costly and slower. Fido2 stands to prevent replay, but doesn't permit a sense of scarcity that phone numbers do as most people won't pay the money to be able to register lots of phone numbers unless you're getting into attestation signatures and that opens a whole new can of worms...
Each of these "stronger" solutions address different problems and raise additional cost and complexity burdens put upon either the company, the end user, or both. SMS remains the most attainable target for the general public.


Is it possible to decrypt symmetric key encryption without the key? I have an document encrypted with a symmetric key. The only information I have is that the key is shorter than 64 bits.

Is there any way I can decrypt it? If yes, how?

To decrypt the message, you have to know more than the key; you must also know the encryption scheme, encryption mode, initialization vector, etc. None of this is supposed to be secret; the key and the plaintext message are the only two secrets in most symmetric-key cryptography (and as was stated in the comments, due to protocol requirements and other formatting inherent in most data, the plaintext is not entirely secret).

Those two secrets are enough: according to the Wikipedia docs for AES, the most successful brute-force attack against any symmetric algorithm was against a 64-bit RC5 implementation, which basically required a "white-hat" botnet run by the nonprofit Distributed.net to provide sufficient CPU time to try all of the 18,446,744,073,709,551,616 possible keys in the 64-bit keyspace (that's 18.4 quadrillion keys; putting that in context, the estimated total economic output of the human race in recorded history is only about 2.4 quadrillion US dollars). Using about 2,700 "willing" computers in the botnet, it took five years to crack the cipher. And most of the common symmetric algorithms nowadays (Rijndael/AES, Blowfish/Twofish, Serpent, Triple-DES) use keys at least twice that long, producing a keyspace of approximately 3.4x1038 (340 undecillion) possibilities. The feasibility of a brute-force quickly becomes infeasible; given one more size doubling to a 256-bit key (which is used in some schemes), assuming we could, starting right now, build a Dyson's sphere around our Sun and trap every photon of the plane of the ecliptic (our planet's own orbit) with perfect efficiency, and then build a computer at the electron level with perfect thermal efficiency powered by this Dyson's sphere and set it to try brute-forcing the key, the Sun would go dark before the computer finished trying every key (the Sun would fail at somewhere around 2218 keys).

Even if the cipher they used were vulnerable, most known cryptanalytic attacks against ciphers that aren't completely broken require what's known as a "known-plaintext" or "chosen-plaintext" attack, where you as the attacker can see or even choose the plaintext messages to be fed into the cipher. Most of these attacks still only reduce the complexity of breaking the cipher by a small number of powers of two; for instance, a 64-bit cipher, which would require 2^64 tries to brute-force, might be crackable if you could see, perhaps, 2^44 64-bit blocks being fed into the algorithm using the same key, and see the ciphertext output. Technically, that's an "attack" because it is more efficient than a brute-force. But, it requires you to feed 128 terabytes of data through the algorithm, without knowing the key (which probably means you're feeding it through the one actual machine performing the encryption for someone else, which would eventually arouse suspicion).

In summary, with one ciphertext, no plaintext, and no key, you stand no chance.

Virtually all successful hackers nowadays find the weakest link in the chain (the human, the unsecured computer that human is using, or the flawed implementation of the encryption algorithm on the computer the human is using), and exploit that instead, through keyloggers, social engineering, etc.

So, should this game ever commence for real, I would suggest discretely installing a program on the computer your friend will use to generate the key and encrypt the plaintext, which will transmit the plaintext and/or key to you as it is typed in by your friend. MUCH easier, and faster, than breaking the cipher. Or, if the key is based on an ASCII string, you could kidnap your friend, lock him in your basement, and use some sort of painful but non-damaging interrogation technique until he gives it up.


Can TLSv1.0 ciphers be used with SSLv3? Can TLS cipher, such as TLS_RSA_WITH_AES_256_CBC_SHA, suites be used within an SSLv3 connection?

For example, say the client and server both support TLS but the connection is downgraded to an SSLv3 implementation.  Would they be able to negotiate a cipher suite using a cipher defined for TLSv1.0?  Or, what if the client and/or server only supports SSLv3, and has no support for TLSv1.0?

Would they be able to negotiate a cipher suite using a cipher defined for TLSv1.0?

Yes.
RFC 7568 Deprecating Secure Sockets Layer Version 3.0 was just published (2015-06-26).
(The draft to this RFC was affectionately known as draft-ietf-tls-sslv3-diediedie.)
Quote from RFC 7568's Section 5: Limited Capabilities:

Though SSLv3 can benefit from new cipher suites, it cannot benefit from new cryptographic modes and features

So, yeah, technically. But I don't know if you'll find any implementation to actually do this.


How to crack a password given its hash and its possibilities I am trying to crack a number of passwords that have been hashed using SHA-256.

I have the hashes available and I also have the possibilities in which the password can be. Some of these possibilities include;

a lower case English word
a simple lower case name such as bob or alice.
a combination of 4 alphanumerical values with special characters e.g ro@!, f6&h

So for example I have hash

9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08

and I want to get the password using an algorithm (one which I will code in Java) to get the password:

test

I am asking to see where to start in how I can complete this task.

I first thought to calculate all the hashes for the password possibilities and cross-reference with the hashes given to me but this does not seem to be the right answer as it would take too long.

Is there any other way to go about cracking these passwords?

Hashcat is used to crack specific hashes such as MD5, SHA-256, bcrypt, and a whole lot more. Hashcat has specific rules it can include if it cannot crack the has with the word directory. Hashcat requires a password directory so it can bruteforce the hash. As an example, I did -1 ?l ?1?1?1?1?1?1 to show the custom character set with -1 (you can have 4 i think) ?l is my charset (all lowers) it also allows ?u ?d ?s ?a for uppercase, numbers, special chars, and all ?1?1?1?1?1?1 is a mask.


Best practices to manage password for embedded Linux devices Should we generate a strong password offline, keep it closely guarded secret, and use the same one across all copies of the device? The boot drive is eMMC flash soldered on the PCB, hard to read bypassing the OS. Or should I write code that on the first boot changes the password to salted hash of the device serial number? Or is there other well-known practices?

The device has networking, but Internet connectivity is optional and we’d like to keep it that way, it should work without internet, not even connected to any networks at all.

Currently, we don’t know if we ever need to ssh into the device, but I expect it would be useful to fix things. While developing the embedded software, I use ssh and scp all the time, to deploy new builds, read logs, and more. The device is heavy and expensive, replacing gonna cost us too much. I’d like ssh access, or something similar, as an escape latch to manually fix the software if it breaks after it’s delivered to users.

Should we generate a strong password offline, keep it closely guarded secret, and use the same one across all copies of the device?

Absolutely not. There are two primary problems which make the risk (likelihood x impact) of an attack high:

The first is that you are likely underestimating likelihood: It is very hard to keep something a secret in your own company. It is nearly impossible to do so in the field. For example, it is simple enough to dump the contents of eMMC using physical means. See 1.
The second relates to the impact. If you used a different secret per device, an attacker would have to do an eMMC dump (for example) for each device, which is extraordinarily hard to scale. However, if only one secret is used, then every device can be compromised with no extra effort (i.e. the work effort for the attacker is constant, rather than linear w.r.t targets).

  should I write code that on the first boot changes the password to salted hash of the device serial number

This makes things slightly better, but not by much.

If the salt is shared across all devices, you have a problem very similar to what I previously described: an attacker simply needs to do a memory dump one time and all devices become vulnerable (a serial number is obviously not cryptographically strong) so best practice is to assume an attacker will be able to take the (shared) password and the (shared) salt, guess the serial number and compute the correct password per target device with little effort.

Using a unique salt per device is a definite improvement assuming you don't store the actual password anywhere (only store the salted hash). This means you shouldn't "change the password [on first boot]" as suggested. Doing so provides some window of opportunity for an attacker to dump memory and get the password before first boot. At which point, every device is again vulnerable.

  is there other well-known practices?

You can mitigate most of the above issues by relying on public-key cryptography. Generate a private/public key pair in your back office for each device, place the public key on the device file system and the private key in some back office "key management system".

To login, you essentially "sign" some piece of data (using the private key) and send this to the device. The device verifies it using the stored (unique) public key. SSH already supports this, see 2.

Analysis

Now let's look at the likelihood and impact of an attack:

Goal: Prevent malicious attacker from logging into to device over SSH.

Likelihood: An attacker can not log in without presenting a proper private certificate (which amounts to guessing a sufficiently long key: impractical) OR by tampering with the device's memory to replace the public certificate OR due to a software implementation bug in the login procedure.

Option 1 is impractical. Option 2 is possible, albeit somewhat time consuming and not scalable. Option 3 is perhaps the most likely, but hard to avoid unless disabling SSH is allowable.

Impact: The analysis here is easy. Since we have a unique key pair assigned to each device, an attacker who does any amount of work to crack or change the key pair for a target device will NOT be able to reuse the work on other targets. Let's call the impact of this "low"

Given this our risk is likelihood x impact = low/medium x low = ~ low risk

Of course, you really need to tune your risk model / tolerance to your organization and application. If, for example, these devices are used to control a safety-critical feature of an airplane or car, you may not tolerate even one-time, physical attacks.

Extra resources

It may be helpful to also review NIST's many guidelines for key management: https://csrc.nist.gov/Projects/Key-Management/Key-Management-Guidelines

Specifically, Chapter 10 of part 3.

References

1: https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader-wp.pdf

2: https://www.ssh.com/ssh/key/

3: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf