Why not send a plaintext recovery password?

If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same.

Based on all of the posts there I've looked at, I think the problem is with "and changes it". None of the emails there I've seen give any indication that the password is temporary and will need to be changed. Without wanting to bother creating a bunch of accounts myself, I would be conservative and assume that, if the email doesn't say you'll need to change the password, the site won't force you to change it after logging in.

You are correct that there is no real difference between a temporary password and a reset link as long as the password has enough entropy. As mentioned in the comments, if the password is too short and the user waits a while before logging in, it could be susceptible to brute force. Since password fields should allow pasting anyway, a 20 character alphanumeric temporary password would be perfectly fine. Both the reset link and the temporary password could be implemented nearly identically, it's really just the difference between a POST and a GET.


What's an attack's 'computational complexity'?

"Computational complexity" is a measure of the CPU / RAM effort involved in the execution of an algorithm. In the case of an attack over a cryptographic algorithm (e.g. MD5), complexity is measured relatively to the attacked algorithm. MD5 processes data by 512-bit chunks, so it has an "elementary cost" which is the amount of CPU it takes to hash a small message (of 0 to 447 bits, to be precise). Since MD5 offers a 128-bit output, so, for a preimage attack (finding m such that MD5(m) = x, where x is given), the generic "get lucky" attack has average cost 2128 times the cost of hashing a small message. Indeed, the "get lucky" attack is about choosing random m until a match is found, which, for a "perfect" hash function (a random oracle) works with probability 2-128 for each try.

Therefore, we express "CPU effort" as the number of times the attacked function could be evaluated with that many invested clock cycles. This measuring unit has the nice property of easily showing whether a function is "academically broken" or not. The "get lucky" attack is generic: it works for every hash function, regardless of its perfection. The average cost of that attack is 2n for a hash function with a n-bit output. So any attack which does better, even slightly, counts as a "break". In the case of MD5, the presented attack has cost 2123.4, which means that it is about 20 times faster than the "get lucky" attack. But it still completely infeasible in practice. Realistic limit for a powerful attacker (say, someone with the budget of Google) is around 280 invocations of MD5.


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

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

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


All that is necessary is that the values are random and unique. It is perfectly acceptable to pull them from your operating system's cryptographic random API or from a crypto library like OpenSSL that contains its own internal cryptographically secure random number generator (CSPRNG).


Proving authenticity of a message from a message app in case of deletion

A screenshot is just an image file.
It can be copied without any limitations. Thus having a screenshot does not prove anything.
Everyone can create or edit any file in editor. Having an image file does not prove anything.
Only of you use a messenger that uses digital signature of the sender or uses encryption, you could prove that you received the message. But for this you would need a copy of your message, not the displayed text, but the binary data package that your messenger received from another one. Then:

If you present this message ...
If this message was encrypted by your public key ...
If this message was signed or encrypted by some other sender, not by you, i.e. the sender key used is known to belong to somebody else ...
If the message contains a timestamp signed by trusted time server (in case of digital signature such time stamp is a part of signature) ...
If you prove that you own your key ...

... Then you can prove that you received that message at that time from that person.


Threat modeling for visitor access control

I think you're mixing a couple of different sorts of things into your question.  You want to threat model the office, which has a set of entry points, and some stuff* you want to protect.  That stuff includes laptops, which you've identified, and probably other things, like confidential printouts, the hard drives in desktops, those fancy Apple monitor stands, the scotch in the company bar, the employees and their sense of well being... We don't have to be exhaustive.

You have two types of problems you've informally identified: one is the visitor, the other is the laptop walking away.  You have two controls: badges and RFID tags.  Let me now take this, and re-frame it a little.

I advocate for a four-question framework as central to threat modeling:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

So what you're working on is the security system for an office.  What can go wrong, we can approach in a few ways. We could expand the attacker list to include other types of person. That has a failure mode of excluding people, say, kids or drunk employees, and so I tend to avoid it, and focus on the threats (" future problems").  Here we might look at theft, damage, disclosure as a list of threats to worry about. In software, we'd look at STRIDE or a kill chain as a model of the threats.

We'd use that list to come up with a list of countermeasures or controls. You've listed two, we might add turnstiles or other physical controls, conference rooms near the entryway, a second set of doors, etc.  These are the answers to what we're going to do about it.

*I'm carefully not using the jargon 'asset,' because it has too many meanings. Also, 'entry point' is a term of art that lots of people used to use, from a physical protection analogy and so I bring it back here. More commonly, in software-focused threat modeling today, we'd talk about trust boundaries or attack surfaces.


Database compromised and some passwords cracked

Generating random passwords and sending them to users is fine. But the most important thing to do, if not already done, is to warn ALL users that their passwords have been compromised and if they are using the same on whatever other website/app they absolutely have to change it.


Perhaps it goes against your current projects intentions - however - you should try and avoid selling products to clients which are bundled in this way and where they have direct and absolute control over the source. (I assume they would be hosting your application on a local server? They would need some kind of technician and would they have to know your code in order to fix problems etc...)

The best solution is:
Host the application on your own server and have individual clients subscribe to your server. Distributing a licence to them is essentially granting them authentication rights. You have technical control over their version/authentication/support and are able to amass logs of usage to improve performance etc...

Is there a reason you can't do it this way?


Given Diceware, why does the requirement to contain uppercase, numerics & punctuation in passwords still stand?

First of all, there are different criteria on what is a good password.

Facebook will happily let you in using a password with reversed case. Others will frown at that. A few years ago, Outlook.com wouldn't have let you use a password with more than 16 characters. Each site may have different password policy, which leads to different implementations. Some sites require symbols, other consider that a long-enough password is enough.

The main problem, however, is that the site doesn't know how the password was generated. A diceware-generated "widow stout harvey crest zomba zloty butyl" has about 90 bits of entropy. Whereas "this is my password for stack exchange" would have much less (specially if I know you used ""this is my password for outloo.com" at outlook!).

Thus, password meters (such as the validations embedded in those sites) resort to estimating the entroppy of the passwords. Generally, adding capital letters or symbols increases the password space, so it was commonly recommended (or required) that lowercase, uppercase and symbols were present in the password as a proxy to "the password will be hard to crack". This is reinforced by common suggestions to do that.

You will find that usually, when the system can generate a password for you (such as access tokens), it doesn't require all that). Since the password is generated by the server it knows how it is generating it and thet it has enough entropy.

Finally, note that in some systems there may be actual reasons for requiring certain length or types of characters. Mainly because they are used (copied) into systems that require it, or because of regulatory reasons, they need to require that, even if it is not that important.


Can all the (other) recepients of a PGP encrypted message be identified?

To a large extent, yes. See RFC 4880, section 5.1: for each recipient, there is a "Public-Key Encrypted Session Key Packet" which contains the recipient key ID. This key ID is a 32-bit value which is used as index in key servers; there are key ID collisions, so this is not an absolute, totally accurate indication of the recipient, but it still gives a lot of information.

Theoretically, an all-zero key ID can be used as a way to discourage traffic analysis, but this is not a complete solution. For instance, with RSA keys, the packet still contains an integer between 0 and n-1, with n being the RSA modulus, with a fairly uniform distribution. Thus, observing many messages can yield, statistically, the first (most significant) few bytes of that modulus, which can be used to discriminate recipients from each other.


The example hash digest you gave is wayyyyyyy too short (20 bits, or about a million possibilities), so you'd get collisions far too often and, worse, anybody who decompiled your program could trivially produce the correct strings (or, at least, strings that are acceptable due to hash collisions) just by brute-forcing the likely input space.

"That's a silly objection. It's just an example..." you might say, but it really isn't. I've found, and exploited, this exact type of weakness before. For example, there was a mobile app that used a 32-bit hash function on user inputs to try and hide what inputs would produce what outputs. It took under an hour to write, and run, a program that brute-forced the search space and found inputs that mapped to every hash digest the app was looking for.

In essence, this is much like trying to store passwords securely. There are definitely differences - passwords are rarely very long, while hardcoded strings in a program can be, and if you're performing the string equality test frequently then you can't afford for it to be as slow as a good password verify function would be - but a lot of the same parallels hold. Use a strong hash function, not just resilient to collisions and reversal but also ideally one that isn't so fast its possible to brute-force the whole search space. For short strings, use a salt so that people can't just look up the value in a rainbow table.

Now, as for actual obfuscation: this technique is one (of a great many) that obfuscation can use. It's usually not very effective, especially when implemented weakly (see my second paragraph), and has enough performance impact that it isn't usually used except selectively in places where the slowdown isn't a big deal. Obfuscation in general is a non-solution; at best it slows down reverse engineering enough that by the time the RE is complete the codebase is old enough nobody cares, without causing undue performance or program logic bugs in the meantime. In practice, though, it's usually not that good.


Using different GPG keys for encrypting emails and encrypting personal files?

This depends on your threat model. From a purely cryptographic perspective, there is no downside to encrypting different types of data with the same key. GnuPG creates a master key which is used only for signing, and then creates, by default, a single subkey for encryption. I take it you are asking whether or not you should use that single subkey or you should create an additional subkey?

The main reason to create a new subkey is to facilitate key management. You have increased control and can, for example, revoke one subkey without revoking the other. You can also use different passwords for each key, or even keep them on different media (such as smart cards), reducing the risk of compromise. Compartmentalizing each subkey and assigning it to a particular task is often good practice reasons like this, even if there is no specific security risk in terms of cryptography to using the same key for two distinct purposes.

I think I should point out that you may not want to encrypt personal documents with asymmetric cryptography. If you are the only one who will be encrypting and decrypting the files, you should instead use a symmetric cipher, such as AES. GnuPG supports pure symmetric encryption without using an RSA keypair. This has the benefit of being more efficient, as well as not being vulnerable to advances in quantum computing or breakthroughs in integer factorization.


What are the possible exploits over a debuggable APK?

Shipping application with debug means that anyone with physical access to the device can execute arbitrary code under that application's permission. If the application holds sensitive data, it will be fairly straightforward to extract that sensitive data from the application. Doing the same on nondebuggable application would require the attacker to first obtain root privilege or find an exploit in the application itself.

Shipping without debug shouldn't be considered as a protection against the user themselves though. The legitimate user of a device have all the time they need to root their own device, and so can gain any secret stored by any applications running in their device with or without debuggable application.


Does software based file recovey solutions have the same results on real physical device vs dd image file?

Yes!

It's standard forensic procedure to work from a "Physical Copy", which is what a dd bit-for-bit image is. It will have the same results as working from the drive. In fact the hash checks verify that they are the same.

This assumes of course that the dd image was done appropriately. An example of an inappropriate dd image would be one done against a multisession DVD as DVDs are not actually block devices and only the last session would be extracted.

A flash drive is a block device and would image as expected via a dd.

Wear leveling is a bugaboo that's often thrown around but it's not a factor here.

The one extremely unlikely difference with an SSD (Solid State Drive) is a massively delayed TRIM function. If the TRIM runs delayed by many minutes, a dd image may actually extract data before the TRIM runs quicker that performing the analysis directly against the SDD, in which case the image would be better but the hashes would not match causing problems. I've never seen this occur!


It may not have to be included in the scope definition. However, it would be difficult to have information security management system (ISMS) without user authentication (see section A.9 on access control). The boundaries of the ISMS (scope) need to be established after considering the needs and expectations of the interested parties.


Is there an alternative to TCP/IP that encrypts end-to-end?

If there was a communication protocol that encrypts at the very
  low-level,

There is: IPSec

  this would solve the problem of wiretapping entirely and for all.

It doesn't.


How can I check the integrity of the downloaded files?

Integrity is defined only relatively to an authoritative source which tells what the "correct" sequence of byte is. Hash functions don't create integrity, they transport it. Basically, if you have:

a file;
a hash value, presumed correct;

then you can recompute the hash function over the file and see if you get the same hash value.

You still have to start somewhere. Some software distributors provide, along with the software, a "checksum" (or "md5sum" or "sha1sum") file, which contains the hash values. Assuming you got the correct checksum file, this allows you to verify whether you downloaded the right file, down to the last bit; and this works regardless of how you downloaded the possibly big file (even if it came over some shady peer-to-peer network or whatever; you cannot cheat hash functions).

Now this does not solve the integrity problem; it just reduces it to the problem of making sure that you got the right hash value. Hash values are small (32 bytes for SHA-256) so this opens a lot of possibilities. In the context of downloading files from P2P systems, you could obtain the hash value from a HTTPS Web site (HTTPS uses SSL which ensures server authentication -- you have the guarantee that you talk to the server you intend -- and transport integrity -- what you receive is guaranteed to be what the server sent). In the context of exchanging PGP public keys with people, hash values (often called "fingerprints" or "thumbprints") are short enough to be transferred manually (printed on a business card, spelled over phone...).

Digital signatures expand on the concept, but they too begin with hash functions. All digital signature algorithms sign not the message itself, but the hash of the message (which is equally good as long as the hash function is secure, i.e. resistant to collisions and preimages).


Sun ILOM / Out of band management security concerns

One assumes that you want to actually use the ILO capability, so "don't plug it into the network" isn't a useful answer.  However, this is one of the few areas where it may make sense to have a separate "management" network.  Put all the ILO interfaces onto a single network and limit that network's access, either via routing, firewall, or ACLs, so that only those trusted administrators machines can access the ILO.  You should rarely need the ILO addresses to be able to go generally outbound, as the whole purpose of an ILO card is just to allow you to get "in front of the machine" without running down to the server room (which can be hours away in many cases).

As far as the firmware goes, it is reasonable for you to update all the firmware yourself.  This not only guarantees an outsider can't slip malicious firmware past you, but it also may ensure that any security updates that apply to that hardware are in place.  As illustration, the following link shows how to update and/or reset various ILO firmware:

http://download.oracle.com/docs/cd/E19569-01/820-1188-12/core_ilom_firmware.html

(Illustration only, I don't doubt that there are 17 proper locations describing how to handle 9 different Sun ILO platforms.  And of course other vendors have their own ILO equivalents which would be handled differently in each case!)

P.S. ILO was originally HP's designation for lights out management, I could have sworn Sun used a different nomenclature, but I can't pull it up at the moment.  However, like many people, I long ago began to use "ILO" to refer to "Whatever the vendor's called their remote access card thingy," so I'll just call it all ILO here.


Does `ssh-keyscan` verify the legitimacy of the host(s) it scans?

Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans?

No. How could it? You are using it to build the known_hosts file that would be used for verification.

  If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification?

In the example you've shown, it indeed does.

Although the problem isn't that ssh-keyscan is being used, but rather when and how it is used. Overall, it isn't any different from getting the regular "Verify unknown host" SSH prompt and blindly typing yes without looking at the fingerprint.

If you do it once and keep the resulting known_hosts file around, then you still get the same Trust-on-first-use behavior that we all expect from SSH. But if you throw away and regenerate known_hosts every time, with no verification against previous runs, then it's going to be a problem whether you use ssh-keyscan or not.

In short, deploying a static known_hosts file would be much more secure – GitHub's SSH hostkeys certainly don't change often, so there is really no need to re-keyscan them every time.


Can my ISP see documents I print trough my wireless network printer that is connected to ISP-provided router?

Any device on your network may be able to monitor unencrypted traffic traveling over your local network, whether passively or actively. A router is no exception to this.
I do not imagine that this is something ISPs normally do, as it is likely to raise quite a few eyebrows. However, if your ISP is compromised or malicious, it is possible that they could install new firmware on the router that does some of these things.
So, while possible, it's unlikely. But if this is a risk you cannot afford to take, it's yet another reason to consider providing your own hardware that only you control.


Setting the network adapter to host-only does not truly isolate the malware. The malware could spread to your host over the host-only network, and then it can spread from your host to the rest of the network or to the internet. (This assumes that your host has regular network connectivity, as is often the case.) This is not recommended, and I'm surprised they suggested it in the first place.

You should avoid giving the malware any means of spreading to your regular internal network or the internet.

The creation of a custom network (or VLAN) is ideal. Most hypervisors will allow you to map directories/folders between your host and a guest, so you can transfer files in and out that way. You create two VMs: one "test" VM to execute to the payload, and one "tools" VM to run analysis tools and transfer data.

The "test" VM can be as insecure as you like---and it may need to be fairly insecure for some payloads to work. The "tools" VM should be relatively hardened; some people prefer it to be a different OS than the "test" VM as well.


Is it fundamentally possible to validate that an unmodified version of your client connects to your server?

It is fundamentally impossible to validate a client on a system you don't control.

That doesn't mean it can't be done to a sufficient degree.  eBook readers, for example, generally try to ensure the client is authentic.  They (seem to) do so in a manner that is secure enough to defend against their threat.  Good enough to protect nuclear secrets?  No.  But good enough for their threat environment.

Figure out how important that control is for your application, and determine the compensating controls you'll put in place to limit the damage when someone goes through the trouble of ripping apart and then mimicking your application.  Don't think in terms of black/white, possible/impossible; think in terms of acceptable and achievable security.


How to get access token programatically when we try to authorize by grand_type auth-code in the OAuth 2.0 like a user?

You can try to use Selenium WebDriver to automate the flow.

I recently did exactly that - automated integration tests calling bank API protected by OAuth and it took me only few hours to get it to work.

Basically You run a real browser and drive interaction with web page from Java code replicating manual interaction.


Liam Dennehy's answer shows that luks doesn't use CBC by default anymore. As for why it used it instead of CTR before, that's because, under the usual adversary model for disk encryption, CTR isn't secure for disk encryption (as you can see on Wikipedia).

Unless you change the IV on every change, which would require encrypting the entire disk for every change, if your adversary has at some point had the plain text and cipher text for a block, he can decrypt that block until you change the IV, as CTR encryption simply produces a stream of random bytes for a given block which is xored with the plain text. The only way to make it secure without requiring reencrypting the whole disk for each change would be to store an IV per block (which would change for each update), which would be either quite costly in terms of disk space, or would require big blocks and thus reencrypting a lot for each update.

Note that in CBC mode, each 512 byte block has its own IV generated from the key and block number, so two identical blocks will not be the same after encryption.


Why isn't a standard for encrypted but open WiFi developed?

There is at least one proposal for this: Opportunistic Wireless Encryption.

In this proposal, the WPA2 password is the same as the SSID, and automatically used by the connecting software.


error in running snoopy in kali linux 2016.2

Missing libmproxy, errors are pretty verbose. I've run into similar with other hacking tools, so here's my debugging steps.

Try searching and installing via a package manager

apt-cache policy libmproxy
sudo apt-get install libmproxy

Then try rerunning, rinse & repeat till errors (or dander) is gone.


Challenge, Authentication and session key

Your protocol is quite underspecified, but some remarks can still be made:

In the first step, either the "salt" is chosen randomly by the client and sent along with the hash value, in which case this step appears completely useless; or the salt is not sent by the client, but is a pre-shared secret value between client and server, in which case it is not a salt but a key, and the rest of the protocol is completely useless.
In the second step, the client sends his login and "hashed password" where the hash uses some salt. If the client always sends the same hash value, then presenting that hash value grants access: it is password-equivalent. Any attacker observing a connection (purely passively) then learns enough to fake the authentication, so the protocol would be utterly weak.

If your protocol has to have any value, then we must assume that things go that way:

Client connects; server sends a random value N (technical term is a nonce).
Client sends another random value N' to the server (and also sends a hash value computed over the public values N and N'; that hash value serves no useful purpose).
Client sends the user name L and the value h(N+N',P) where N and N' are exchanged nonces, P is the user password, and h is a "hash function" which somehow combines N and P (there are a lot of methods to do this combination, many of them being weak in more or less subtle ways).
The server has a copy of P and thus can recompute the value h(N+N',P) and see if it matches what the client sent.
Client and server use another function h' to compute h'(N,P) and use that value as a shared key to do some symmetric encryption for the rest of the data.

Assuming that you did everything properly and used hash functions in a proper way and did not forget to add integrity checks and took care of the gazillions of implementation details which can plague the best designed protocols, then you will have obtained, at best, TLS-PSK. There are two inherent and unavoidable weaknesses in that protocol:

The server must store a password-equivalent secret. If an attacker gains a read-only view of the server data (a usual consequence of SQL injection attacks or stolen backups), then he learns enough to authenticate as any of the registered users. This is considered bad. See this blog post for a discussion on that subject.
A passive attacker learns enough to run an offline dictionary attack: the attacker just has to observe one authentication, and then he can "try passwords" on his own machines; he just enumerates possible passwords until he finds one which matches the hash values he observed. This, again, is bad, because passwords tend to be vulnerable to such an exhaustive search. Online dictionary attacks, where the attacker must talk to the genuine server or the genuine client for each password try, are much less a concern, because the server can enforce strict limitations on the number of tries per second; whereas an offline attack is limited only by the computational power that the attacker can muster.

The proper way to do a client-server password-based mutual authentication is to use a password-authenticated key agreement, which results in a shared secret suitable for symmetric encryption with integrity checks. This basically means TLS-SRP. 15 years of implementations and attacks and fixes have demonstrated that designing and implementing a secure protocol of that kind is not easy at all.


Encrypting a Database's Primary Key when sent to the browser

I'm going to agree with what AviD is saying in the comments.

To the original question, I don't think there are benefits to encrypting key values that are exposed by the application.   To me, it sounds like an odd (and expensive, from a perf perspective) form of security by obscurity.

Security and integrity of non-secret data should be provided by solid application logic.  I.E., does the current user have permission to modify the data that they're trying change? Or, does the current user have permission to add a student to this class, and is the class still open for registration?

Encrypting keys doesn't solve these problems, but in fact, can cause additional problems, like, what if a link with a valid encrypted parameter is emailed to somebody who shouldn't have access to it?

For the other example, the emailed password reset, I'm struggling to see why the encrypted key would have any significant advantages over a GUID that aren't going to be offset by the performance impact of the encryption and decryption operations.

Just my two cents of course, but I really don't see much, if any security advantage at all.  I think it's just additional cost with no real benefits because most, if not all of the underlying security problems will remain and have to be solved another way regardless.

I hope this helps,

-Xander


What are Non-linear/backward overwrites?

First of all, a "linear overwrite" is the most common type of buffer overflow.  This is the example given in the slide.   Where by starting at some base address you write in a linear fashion and eventually you overwrite the return address:

void function(LPCSTR input){
    char buffer[256];
    strcpy(buffer, input);
}

An example of a non-linear overwrite is this GroupWise ActiveX control exploit written by rGod.  This ActiveX component has a method call where one of the parameters is a memory address, which allows an attacker to write to an arbitrary location in memory.  If the return address was protected by a canary the attacker could just point directly to the return address and overwrite it without corrupting the canary. Dangling pointers can also produce a condition where by the attacker can control a specific address in which to  read, write, or execute in a non-linear fashion.


How accurate the recent activities location provided by Microsoft emails

Using a strong password and 2FA should be sufficient to prevent those who knew your password from succeeding again.

Yes, it is very possible that an attacker would have access to servers around the world to try and log into your account, so that's not surprising at all. It is also possible that your account credentials were sold, posted on a public forum. There are sites that try to determine if accounts are made public.

I know that its unnerving to have someone constantly try to break in, but we are all exposed to the same thing all the time. Good account practices protect us all from these types of threats.


SSL Certificates Management and Tracking

1. You must know where a cert is located because it is related to a private key. A leakage of such cert/key could be a step to attack whole infrastructure, just imagine leakage of a shared cert/key which is used for LDAP and equally for an unimportant HTTPS service. Wildcards certs are bad.
2. Copying that manually is not good solution.
For first issue you must have a management. For the latter you must have an automation which depends on the management.
The management depends on how you want to work. Do you run mostly containers? Is your workload static or dynamic?
The automation depends on a decision if you would implement "push" model, ie. one pushes changes to targets, or a kind of "pull" mode when targets update themselves from a trusted source.
There are products covering all of this. For example HashiCorp Vault is able to generate short-live TLS keys/certs via HTTP API. An update procedure could be initiated from a trusted management node or from the machines using these keys/certs via a scheduled job (cron job in UNIX world). Or you could have consul agent running on all managed nodes which would look for changes in consul's K/D database, and when a value (base64 encoded key/cert) changes, consul agent would react - save update key/cert, restart a TLS service.


OpenID Connect with user bound roles and M2M access

OpenId connect is used to provide an authorization framework. Specific permissions are out of the scope of Oidc. Your problem is strictly a permission problem, and there isn't any absolute rule provided by oidc for that.
Of course, everybody is using the scopes to solve that, when required, but basically it really depends on your overall architecture and requirements. Basically there's 3 philosophies here:

The Oidc IP will only be used to define which user has access to which ressource (RP), with very limited access. The permission logic will be handled at each RP level. It usually means that on the first login, the user is cloned in the RP with no access and an admin grant him specific permissions when needed. Admin of the IP is simple because you only have to say user X has access to app Y, but admin of each app can be painful.
The Oidc IP will be used to handle permissions using scopes/roles. The permission logic is thus completely handled at the IP level. Hopefully the IP will provide realms logic to handle this otherwise it will become a nightmare.
A mixed logic, for example, in your use case the type of user (business or government) could be stored int he IP and provide basic permission for each type of user on creation. That means that permission is still handled by each RP, but, when the user is cloned, specific permissions are granted on creation depending on the type of user. More flexible, but rules on what permissions are handled at the IP level and what permissions are handled at the RP level should be very cleared defined, otherwise you'll most likely have a ton of problems, and potential vulnerabilities.

In my company we choose the third solution. Basically the IP always provide the user type (normal, admin, superuser) for each user/RP, and the user is created with limited rights (except for superuser) in the RP. Then we can fine tune the user permissions in the RP admin when needed. We also get have a "company" scope allowing us to link the user to its company and define its permissions depending on the company. On each connection we also check if the user type should be updated. Of course we use nonce/state and pkce flow with a private key signed token.


Cracking passwords via hashcat or rainbow tables. Which is faster?

I can't speak to the precise time needed to generate a rainbow table. But I can address your question more generally.

If:

it's a single hash
it's an unsalted hash format
the password is known to be of sufficiently limited complexity and length, such that an equivalent rainbow table is available
the password is of sufficient time-dependent value to the attacker ("we gotta crack this hash in 20 minutes or the bad guy gets away" scenarios)

... then a rainbow table can be of specific limited value (and even then, it's a gamble).

Otherwise, as soon as either A) you have more than one password to crack, or B) the complexity of the password is not known, the usefulness of rainbow tables drops off rapidly. With a rainbow table, you can only look up one hash at a time, and that lookup takes a significant amount of time. In that amount of time, you can test trillions of potential passwords against millions of hashes with hashcat.

The modern, efficient option is to build an attack plan with hashcat that supplants (and goes far beyond) the equivalent rainbow table - because most unsalted hashes are so fast that you're much better off just using hashcat. Most passwords will fall to an attack using straight dictionaries, dict+rules, combinator/hybrid attacks, masks, etc.

tl;dr: hashcat is much more efficient for most of the common use cases.


Why use 256-bit symmetric encryption in TLS when 2048-bit RSA doesn't even offer 128-bit strength?

People use 256-bit encryption because they can, and, given the choice, people tend to go for the biggest numbers, because they feel that they "deserve it".

Scientifically, it does not indeed make sense to use AES-256 when the key exchange relies on 2048-bit RSA. This is just wasted CPU cycles; AES-128 would have been equally fine. But "256" can woo auditors into submission. Such are the intricacies of the human psychology.


What is auth_results are DKIM and SPF results, uninterpreted with respect to DMARC.

What is in the policy_evaluated are the results of applying DMARC. disposition is the policy action specified in DMARC record. dkim and spf are DMARC-aligned authentications results.

Hope it helps.


SSL/TLS compression attacks on mail servers (smtp)

Compression attacks like CRIME and BREACH work by triggering repeated transmission of almost the same message with only slight modifications, with these modifications controlled by the attacker. By watching the compressed size of the message the attacker can then reason if the attacker controlled string is contained in the message or not. This is used to guess the value of sensitive data, like the session cookie or CSRF tokens in case of HTTP.

With HTTP these attacks work against cases where the response from the server reflects input from the client (to guess CSRF token in response) or by making the client submit the same request with slight variants of the URL or body data to guess the cookie in the HTTP request. Attacker controlled input is possible since HTTP allows cross-site requests, i.e. the attacker can cause the client to do a specific request and then watch the encrypted request and response.

But SMTP works different. There is usually no way for the attacker to make the client send a specific mail again and again with only slight and attacker controlled modifications. Although one might construct scenarios where almost the same mail gets sent in an automatic way with some attacker controlled input in (see answer from @Giles) in my opinion in all practically relevant cases such compression attacks will not work with SMTP.

Still, it is better to not use TLS level compression (used by CRIME) which is hopefully the default in modern crypto libraries anyway. As for the application level compression used by BREACH: while it is common to use such compression in HTTP (declared by Content-Encoding header) there is no application level compression defined in SMTP or MIME (which is the encapsulation format for mails). While there is an proposed x-gzip64 I've never seen it used in practice or supported by actual mail clients.


What is the "PGP Global Directory Verification Key"?

PGP Global Directory

The PGP Global Directory is a certification authority that validates that you have access to the mail address if you want it signed (but doesn't validate anything further than that).

In the end, it is a kind of yellow pages for mail addresses, you can look up keys in there, and with a given chance key owner and mail address owner actually are the same person, but do not trust in it (for example, man in the middle attacks on unencrypted server to server mail transmission would still be possible).

Expired Certifications

Alongside being listed on their key server, certifications are issued. These expire after a very brief period of two weeks, but new ones are added after you validated the respective mail addresses again. As keys are removed after half a year and they send you a reminder e-mail to reverify your key, you will often find these certifications being issued twice a year.


What is the difference between Anti - APT (Advanced Persistent Threat) and ATP (Advanced Threat Protection)?

Advanced Persistent Threats (APT) describes actual threats.  Depending on who you talk to and the context these are sophisticated and targeted attacks by advanced actors with lots of money like states or criminal organisations  - or simply anything which is more complex than what basic firewalls and antivirus products could detect (like in "it wasn't our fault since it was an APT attack" when you did not care enough to secure the network). Thus "Anti-APT" likely refers to defending against these specific advanced threats.

Advanced Threat Protection (ATP) describes protections against threats.
It is a marketing term like "Next Generation firewall" which should highlight the ability of an analysis system to be somehow better (i.e. "advanced") in detecting and preventing threats than "traditional" systems. Expectations are that it will not detect just the "average" attacks but "more". What exactly this "more" and "better" consists of is not clearly defined but it often involves some more buzzwords like using artificial intelligence to detect threats or cloud based threat intelligence.

The similarity in the abbreviation between APT und ATP might be accidental but the association it creates in the consumer is probably welcome by the marketing department of the vendor. But only few vendors explicitly claim that ATP is actually able to detect APT. But it is likely that if you want to actually detect ATP (i.e. "Anti-APT") that "traditional" network security like simple stateful firewalls and antivirus is not sufficient. Solutions claiming to be ATP are probably more useful but might not be sufficient too - depending on what these solutions actually do (instead of how they are marketed) and how you interpret the term APT for yourself.


Is there any downside to always declaring some default bad chars when generating exploits?

For shellcode the only potential issue is size constraints. But assuming null bytes are bad is a bad habit. You might mistakenly think a crash is not exploitable because the only viable pop pop ret/ROP addresses start with a null byte.

Determining exact bad bytes isn't too time consuming and I always recommend doing it as it can save time if you need to troubleshoot your shellcode.


Does re-hashing a part of the password hash increase security?

Only the code would know how many characters were being used to re-encrypt the first hash code.

And this is where the problem is. Right at the start, only one with access to the code knows this. But how long can you keep this a secret?
You may inadvertently publish your code on GitHub, or talk about it with friends and be overheard... as soon as the secret is out, the extra value goes away. And you need to use a different method - which implies having to ask all users to once again enter their password.

It's called Kerckhoff's Principle:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

The only things that should need secrecy, are the things you can change quickly. So you can adequately respond when the secret leaks.

That being said, MD5 is outdated; consider using bcrypt for hashing instead.


Is a local account on windows more secure than a microsoft account

Microsoft's stated reasons are centered strictly around convenience, not security.  They make no claims one way or another whether one type of account is "more secure" than another.

I think you need to be more clear what sort of vulnerabilities and threats you are concerned about.  If it's Microsoft having a backdoor, then you would be closing that loop by changing to a local account.  If you fear losing your data if your computer is stolen, then you might appreciate the continual backups of their OneDrive service; you might also be concerned about the ability of an offline attacker having the opportunity to try to crack your password.  Both are security issues and vulnerabilities, and both are valid concerns from differing points of view.  You have to decide what's right for you.


Are DLLs in URLs executed on users local machine or on the remove machine?

It is not even clear that there is a DLL involved at all or that no DLL is involved if the URL does not contain the .dll suffix. The (remote) webserver just interprets  the URL like it wants and you can not make any definite assumptions on the underlying technology just based on the URL. It would be perfectly possible (but uncommon) to have a URL like http://example.com/foo.php/bar.dll/foobar.exe/barfoot.gif which is neither a GIF image, nor is a PHP script, nor a DLL or some executable file but it is instead HTML created by a Perl script. In any case: the server provides the content based on the URL and the browser then renders the content, independent from the text of the URL (the might be cases where the URL text has local affects, like with reflected XSS attacks etc).


Since these are backend calls, there are a few options you can do:

Certificates : SSL/TLS allows mutual authentication whereby you have both end to end encryption and authentication at once.  If you enable client certificates on API A (and check it on B), and vice versa - you have a strong tunnel.  Furthermore, you can use certificate pinning - in which case it may be okay to use self signed certificates.  As long as Api B can verify that A's private key was used to sign the traffic sent, you have this trust.
Shared secret : You can encrypt the traffic with a shared secret between both parties (A and B), this would of course require that you have strong secrets and a healthy key rotation policy.  The shared secret will act as authentication (ie: if you know the secret, you're the right party).  This could be seen as an API key or anything that's known to both parties, but no one else.
Token based : You can get bearer tokens from a general Identity provider (IdP); which Api A will get with a appID / Secret combination.  The (trusted) IdP will create a signed token which APi B can validate and henceforth, trust that the request came from 'A', as verified by a trusted 3rd party, namely the IdP.

Needless to say, Api B should be accessible over an HTTPS connection, and as defense in dept you could ACL network devices in between.


How do I protect myself from the aftermath of the OPM hack?

OPM has released statements offering credit protection and advice on how to respond. Phishing e-mails were listed as one of their concerns. Their recommendation was to use anti-phishing plugins to your web browser to help identify phishing e-mails and keep your systems patched. For the layman, that's probably the best you can do.

I believe it's important to understand what the perpetrator would want to do with this kind of personal information.

Note that this isn't the first compromise of clearance information. Two contractors, USIS and KeyPoint have been compromised over the last few years. I've found little written about why they were targeted.

Regarding the motivations behind the OPM compromise, I've seen two trends in the media. One concern is about blackmail and another about social engineering.

Wired has a nice write up on why someone would go after this information. They claim the information could be used by foreign intelligence services to blackmail people in to turning over secrets. Remain vigilant regarding that risk and report it to authorities should you think you're being targeted.

The data that was taken is a treasure of social connections. Your neighbors, parents, co-workers -- all people you trust and would expect to receive messages from. If you are concerned you are being targeted, contact the FBI Internet Crime Complaint Center (IC3) listed in the OPM statement You can also take extra precaution to validate all e-mail attachments you get (especially Office and PDF documents) with the receiver.

One last thing to consider -- this might not actually be about you and I. It may be about identifying and punishing those who are talking to the US government without permission. The Wired article talks to that a bit.


They're not really directly comparable. The number commonly bandied about is 2048-bit RSA is about equivalent to 128-bit AES. But that number shouldn't be relied on without understanding the caveats.

Currently the most effective way of breaking AES crypto (and any other unbroken symmetric cipher, for that matter) is brute-force. You simply try every possibility until you reach the correct result.

This means that it is possible, and well within today's technology, to encrypt data that (assuming no better attack is ever found--not a horrible assumption), can never be broken, ever, by anyone. Simply use enough bits in your key such that there isn't enough energy in the universe to try enough candidate keys. The numbers are smaller than you'd think:

Indeed, with AES, 128-bit is secure against modern technology, 256 is secure against any likely future technology, and 512 is probably secure against even never-imagined hypothetical alien technology.

Symmetric encryption, if not broken, doesn't leave you with a math problem to solve. The numbers are truly and literally scrambled, and the system is devised such the brute-force is by far the most efficient solution.

Breaking RSA, on the other hand, is not so hard. Instead of brute-forcing the keys, you factor the modulus into primes and derive the keys yourself. This is dramatically simpler to do. It's a math problem, and we can do math.

Specifically, the speed at which primes can be factored is increasing FASTER than the speed at which symmetric keys can be brute-forced. And that's with today's technology.

But going forward, assuming quantum computers can be improved such that qbit operations are a cheap as bit operations (which many people thinks is fairly close; this century at most, possibly decades), then no matter how large you make your RSA key, breaking the key is as fast as encrypting.

So the moral of the story is this:

The "equivalent security" of RSA key length versus AES key length changes over time. Every so often, you have to increase your RSA key size relative to your AES key size to account for technological advances. And even then, it's an estimate at best.

And while a 256-bit symmetric key should be secure for hundreds, thousands, or perhaps hundreds of thousands of years, no RSA key of any length should be assumed to be secure more than a few dozen years out, since RSA is expected to be completely and utterly broken by Shor's algorithm.


Handling CSRF tokens on pages longer than the PHP session limit

Given that the page is before login and is low risk I have taken the advice of @sliverlighFox and removed the CSRF from the form which resolves the issue.


If I leave SPF not set on my domain, is that a factor for email servers to mark emails from this domain as spam?

An absence of SPF isn't supposed to hurt you, but some anti-spam systems are set up to be rather aggressive and I'd worry about your luck given a system using a best-guess record (v=spf1 a/24 mx/24 ptr ?all) and then penalyzing a netural result (I don't know how common that is).
Side note: PTR in SPF is extremely ill advised (it lets any network owner forge mail as you). I also highly advise against over-permissive records like v=spf1 +all, as that's a spam indicator.
My recommendation is to at least give yourself v=spf1 a mx ?all if you self-host. Add your mail provider if you have one, e.g. v=spf1 a mx include:_spf.google.com ?all if you use gmail (you should be fine with include:gmail.com, but run it through a checker like this one). Also consider using DMARC reporting to figure out what you've missed.
If all of your mail is DKIM-signed by your domain and therefore passes DMARC, you should add an SPF record like v=spf1 ?all to make it clear that nothing passes SPF and that best-guess records should not be applied.


That's the problem with hardcoding return adddresses in your payload - the controllable memory region would normally contain zeros due to the way memory management works. Given that null bytes ('\x00') are considered as string terminators, anything that comes after will be ignored.
A cleaner way is to find the address of an instruction in the vulnerable program's code that contains some kind of jump instruction to a memory location you are successfully overwriting with your buffer. In stack-based buffer overflows, you would likely need to find a JMP ESP instruction that would take the execution flow to the top of the stack, which would execute your shellcode. Therefore, you need to overwrite the return address with the memory address of any JMP ESP within the program's instruction set (this is assuming you are not dealing with ASLR protection).


Is there a risk involved in befriending fake accounts on Facebook?

They can take information on your page and use it for targeting you for phishing.

They can also use it to generate phishing emails to others based on info on your profile.


How to timestamp a document without electronic signature under eIDAS

Let's start with full disclosure:

I work as a software developer for Disig a.s. -  Trust Service Provider from Slovakia - and I'll use our products and services to demonstrate the technology I'll describe in this post. I've written several server-side and client-side products for time-stamping over the years so my perception of legislation/standards/reality may be biased. You've been warned :)

Let's answer your question:

  What is the preferred way to timestamp a document under eIDAS without an electronic signature?

IMO the preferred way is to use RFC 3161 based qualified time-stamping service and store the received time-stamp token in ASiC-S container.

Let's look at related legislation:

Regulation (EU) No 910/2014 also known as eIDAS does not define technical details itself but rather says:

In Article 27(5) that the Commission may, by means of implementing acts, establish reference numbers of standards for advanced electronic signatures.
In Article 37(5) that the Commission may, by means of implementing acts, establish reference numbers of standards for advanced electronic seals.
In Article 41(2) that the Commission may, by means of implementing acts, establish reference numbers of standards for the binding of date and time to data and for accurate time sources (IMO this refers to time stamps).

I am not aware of any implementing act directly covering the third Article 41(2) but the first two - Article 27(5) and Article 37(5) - are covered by Commission Implementing Decision (EU) 2015/1506 of 8 September 2015 which IMO indirectly covers also the third because it refers to the following technical standards:

XAdES Baseline Profile defined by ETSI TS 103 171 v.2.1.1
CAdES Baseline Profile defined by ETSI TS 103 173 v.2.2.1
PAdES Baseline Profile defined by ETSI TS 103 172 v.2.2.2
Associated Signature Container Baseline Profile defined by ETSI TS 103 174 v.2.2.1

First three are signature related but the fourth one defines also ASiC-S and ASiC-E container types that can store RFC 3161 time-stamp tokens along with the timestamped document.

Let's look at practical example:

In the first step I am using open source application TimeStampClient to timestamp plain text file hello.txt with eIDAS compliant qualified time-stamping service:

TimeStampClient produces ASiC-S TST container and saves it as hello.txt.asics. If you change .asics extension to .zip extension you can open this container and explore its contents in almost any reasonably current operating system. Please note that file timestamp.tst stored in META-INF folder is raw time-stamp token received from time-stamping service and you can extract it and use it directly whenever needed (for example when you want to use it or validate it in application that does not support ASiC-S TST).

In the second step I am using validation service zep.disig.sk to verify the validity of timestamp:

As you can see this service supports ASiC-S TST and correctly verifies timestamp validity.

In the third step I am using validation service DSS Demo to verify the validity of timestamp:

As you can see this service supports ASiC-S containers but fails to detect the timestamp. I guess it does not support ASiC-S TST yet.


Is ssh with public key authentication, no passwords secure enough?

If you are using public key authentication for SSH, no one can log in to the server without having the corresponding private key. This is as secure, and usually more secure, than password authentication. The encryption OpenSSH provides is state of the art; there is no known way to break it. You can further improve security on the Tor side by using authorized hidden services. This will make the domain inaccessible to all but your client. Note that this only works with v2 hidden services, not the latest v3.

The only remaining attack would be a man-in-the-middle attack. You can copy over the host key from the server to your client, just like you copied a key to make public key authentication possible. This will completely mitigate man-in-the-middle attacks and the client will warn you if an attempt is detected.

See also What is the difference between authorized_keys and known_hosts file for SSH?


What is the difference between JWT and encrypting some json manually with AES?

JSON Web Tokens (= JWTs) are based on the RFC 7519 and all differences will be extensively described there. If you take a look at this, you will see, that they are much more than what you seem to have in mind.
Among other things, these tokens:

are used to assert claims (for instance "logged in as admin")
are signed with a message authentication code (e.g. HMAC-SHA256) (the algorithm is specified in the header of the JWT)
have a payload that contains the claim(s) (equipped with a timestamp)

The signature is base64url encoded. This is described in section 3.1 and Appendix A.1 of the RFC.

You could do all this with an elaborate homegrown implementation of sharing claims, but why would you?
There are standards, norms and RFCs for a reason. They have been tested by experts, they are trusted and people use them for a reason. It's a good thing that (nearly) everybody weighs their fruit in kilos and travels their distance in kilometres. Standardized systems make it easier to share information and are easily usable for a lot of people.

The conclusion to your point behind this: Do not build overly complicated solutions for problems that have tested and trusted solutions.

Also: take a look at this for another "What's the difference..?" question: What's the difference between SHA and AES encryption?


Repair Truecrypt NTFS-partition with undetectable filesystem

TrueCrypt provides a volume: a big sequence of bytes. TrueCrypt puts itself between these bytes and the physical storage medium, by applying encryption whenever the data is to be written to the disk, and decryption when it is read. TrueCrypt stops there. The meaning of these bytes is none of TrueCrypt business.

An operating system like Windows will take this bunch of bytes and organize it into an abstract set of directories and files. This requires dedicating some of the bytes to "administrative tasks", to encode the structures which tell where the file data physically is, and what are the file names, access rights, modification dates and so on. These structures are called a filesystem. NTFS is a filesystem.

In your case, Windows says: in these bytes, I see no filesystem. The TC repair tools comes to the same conclusion: there is no recognizable structure usable as a NTFS filesystem. GetDataBack can recognize shreds of a NTFS filesystem and scavenge some of the files, but GetDataBack does not pretend to repair the filesystem (in the same way that extracting reusable parts from a wrecked car is not the same as making the car functional again). All these tools work on the "big sequence of bytes" that TrueCrypt can show by decrypting that which is stored on the disk. In other words, TrueCrypt is not relevant to your situation (except maybe as the culprit).

For some reason, which is not yet elucidated, the filesystem structures are damaged, and are gone. Since TrueCrypt has no idea whatsoever about what a filesystem may be, it can be considered as a sort of extension of the hard disk, storing whole sectors, not files. It so happens that the OS, at some point, asked TrueCrypt to write down some bytes which appeared to be garbage, and to destroy the filesystem structure. TrueCrypt merely complied.

The best you can do, at that point, is salvage what you can with GetDataBack (as you say, "nearly all data") and/or exhume your last backup, then start over with a fresh format.

There are many possible reasons why this sort of problem may occur. A bug in TrueCrypt could explain it; but also a failure in the hard disk itself, including the electronic part of the disk. I also once (actually, three times) had a problem with a PCI network card which, under high load, would begin to put random noise on the PCI bus. This triggered an OS "panic" and the kernel would then do a quick unmount of the filesystems, thus writing a "clean" superblock (the top of the filesystem structure). Unfortunately, that write call would travel over the PCI bus, and the data reaching the hard disk would then be utterly mangled. This was leading to the same symptoms as what you presently observe.

A bug in the OS itself (Windows) could also be a plausible explanation. Even more probable, bad RAM: the OS works by following structures in RAM, which tell it what to do. A bad bit at the wrong value can wreck havoc to these structures and induce the kernel to write out garbage data on its disks.

The possibilities are endless. Therefore, make regular backups.


Laws on computer surveillance are derived from laws regarding telephone surveillance and wiretapping.  Those laws don't always fit the current situation, and the laws have not kept up with rapidly changing technology.  So there are lots of holes in regulation and privacy law.

One important concept is the "expectation of privacy," where a reasonable person would expect a conversation to be private -- say inside one's home as opposed to a busy street corner. If you don't have the expectation of privacy, you can't argue that your conversation (data, web history, etc) is private. This concept governs most computer privacy laws.

To answer your questions:

In the organizations I've worked at (in the US), there are no limitations, other than most IT shops are too busy to bother with weeding through collected data unless something very bad is going on.  As storage gets cheaper and cheaper, the tendency is to collect everything -- just in case (the NSA is a perfect example).
There are laws regarding privacy, but they vary from state to state (and apparently from provence to provence).  How much security one needs is up to the organization to determine themselves, so guidelines aren't much help.  I've never seen anything commonly used.
The idea is that in the workplace, the company owns the computers, circuits, storage, etc, so any information you create on them belongs to the company, especially since you are being paid to be there.  Again, there's also the expectation of privacy thing -- you normally don't expect your conversations at work to be private.
A lot depends on what kind of surveillance, and what state it is taking place in.

Just for the record, IANAL.


Hack to change the webpage of a website?

Given the fact that the hackers had access to the servers and their data, then they had direct access to the HTML files.

Protection against such an attack is very broad in scope, because you have to protect yourself against all forms of intrusion into your network.


How can I protect my home/office computer against row hammer?

The only reliable hardware mitigation that does not involve downgrading to a motherboard with DDR2 is to use memory that supports TRR (Target Row Refresh), which is optional for LPDDR4 (not the same as DDR4). Unfortunately, many DDR4 modules do not support TRR, and there is often no easy way to tell if it is supported without digging deep. Furthermore, it seems that most modern TRR implementations are ineffective and actually make the situation worse. There is also pTRR  (Pseudo-TRR) for DDR3 which some Ivy Bridge processors have. It requires using pTRR-compatible DIMMs. I do not know how effective or reliable this is as there is little information available on its implementation or specifications available online. Other than that, there are a few techniques to reduce susceptibility:

Use ECC and panic on MCE - While ECC does not fully mitigate the attack, if you configure the computer to panic on any violations (called Machine Check Exceptions, or MCEs), it can go a long way. An attacker will have a much harder time successfully exploiting the system if the first detected error results in the system halting. High scrub rates improve detection.

Increase refresh rates* - By default, memory is refreshed at 64ms intervals. Some BIOSes allow you to specify the refresh interval. Reducing this to 32ms makes rowhammer more difficult to exploit, at the expense of performance and energy usage. Reducing it even further helps more, but with an even higher performance impact. Some BIOS vendors that claim to have a rowhammer mitigation setting (either optional or enabled by default) simply reduce the refresh interval to 32ms.

Reduce clock speed* - Reducing the maximum clock speed of every core makes it more difficult to access rows of memory at a high rate, as memory access is naturally bounded by clock speed. This mitigation only works for memory that is borderline vulnerable, and at a high price (significantly reduced performance). You can also disable Hyper Threading or other forms of SMT and switch to using a single core, again resulting in a significant performance impact.

Set CPU and RAM resource limits* - Rowhammer requires hammering memory which uses up a lot of CPU time. Some privesc attacks additionally work more quickly if the malicious process can allocate a lot of memory. Setting strict resource limits to kill a process that uses too much CPU or memory can slow down attacks when using memory modules that are borderline vulnerable.

Disable JIT in web browsers - JIT, or Just-in-Time compilation, is an optimization feature used by browsers which compiles JavaScript into executable code. This greatly speeds up heavy scripts on webpages. However, it also makes rowhammer from the browser possible. Disabling JIT reduces JavaScript performance enough that this attack becomes infeasible. Note that this mitigation only reduces susceptibility of the browser, not any other local processes!

Use memory with a high MAC - The Maximum Activation Count, or MAC, is a measure for DRAM that counts how many accesses can occur to a row within a single refresh interval before instability results. A higher MAC is better, and an unlimited MAC is ideal. Modules with an unlimited MAC are, in theory, not vulnerable to rowhammer. You will need to search the datasheets in order to find out the MAC for that particular model, or obtain the data via SPD. It would also be necessary to test the modules to make sure they are safe, as the reported MAC value is not always accurate.

Blacklist vulnerable addresses - A special feature of x86 CPUs is e820, which contains a list of physical memory addresses that the CPU will hide and refuse to map to virtual memory. Combine this with the fact that rowhammer typically affects the same rows over and over (i.e. there are susceptible rows and there are insusceptible rows in any given module), it makes sense to find these vulnerable addresses and blacklist them. This is the approach taken by B-CATT.

Physically partition memory - If you can partition your memory such that processes of different security levels are never mapped to adjacent rows, you can isolate rowhammer-based corruption. This can be useful when allocating memory for virtual machines, or when segmenting memory so there is a split between user and kernel physical memory regions (not just the "upper" kernel).

Many rowhammer-related questions and discussions are present on rowhammer-discuss.
* On their own, these mitigations can do very little and only slightly reduce the rate of bitflips in many circumstances.


Windows Servers in DMZ - managed via AD or standalone?

Your reasoning is exactly right.

Your DMZ servers being joined to your internal domain is a risk that should be avoided. Usually a separated Active Directory domain for your DMZ, or running each server standalone is the best option.

A small environment might be fine with standalone, but beyond a dozen or so servers, or with a larger team of staff, a separate domain might be easier to manage. You might have a trust existing between your DMZ domain, and internal domain, but it should be managed with care.

You'll always have a need to connect parts of your DMZ to your internal network (proxy servers for example), but it should always be on a strictly as-needed basis. Plus, if your DMZ does become compromised, and someone can steal the credentials of a DMZ Administrator, they won't automatically have access to your internal domain.


Why can hackers get in network using tunneling?

Tunnelling to bypass firewall filtering means that an attacker uses a "trusted" protocol in order to exfiltrate data from the victim machine.

For example, an attacker can inject exfiltrated data into a lookup DNS requests sent to a fake dns server controlled by him.

Victim machine--->DNS REQUEST--->FIREWALL--->Attacker FAKE DNS Server

You can reach the same goal with different protocols, think about maleware with a gmail account as C&C.


With an IPS in place, do we really need firewalls?

The terms "Firewall" and "IPS" do not describe specific technical implementations and capabilities. While traditionally the term "Firewall" is mostly used to describe a stateless and then later a stateful packet filter (like Checkpoint Firewall-1) they are also used to describe proxy based technologies (like the FWTK - firewall toolkit). And what was formerly was called IPS is today (more or less enhanced) marketed as Next Generation Firewall (NGFW). Note that the article you refer to seems to be from 2009 when the term NGFW was still uncommon.

If you look at the underlying technologies: a traditional IPS was commonly implemented with deep packet inspection (DPI) but additionally a packet filter was used (i.e. one of the traditional meanings of the term "firewall") to reduce load on the DPI in that  obviously unwanted or wanted connections were handled by the packet filter firewall in a cheap way instead of dealing with these in the way more resource-hungry and slower DPI.


Rate my idea: NodeJS as root behind Apache as a proxy with password

You might want to think about running the web server with the normal level of permissions, then setting up the application to store the commands in a text file on the server.  Then, a script running on the server with root permissions (either a cron job, or a daemon) can read the commands from the text file and execute them.

This way, you'll achieve your goal of providing your user with a web interface for executing these commands, without running a web server as root.  Of course, you'll also want to think carefully about authenticating your user securely.  As a second layer of security, you'll probably also want to not allow the user to run arbitrary commands, and restrict the commands that can be run to only those on a whitelist that you specify, and protect against command line injection attacks.


Configure SSL Mutual (Two-way) Authentication

There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using:

# apt-file search CA.sh
openssl: /usr/lib/ssl/misc/CA.sh

And RedHat and derivatives the (approximate) equivalent is:

# yum provides */CA
1:openssl-1.0.1e-4.fc18.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
Repo        : @updates
Matched from:
Filename    : /etc/pki/tls/misc/CA

This is a very simple bash script that eases the creation of the directory structure needed to manage a CA (this is described in the [ CA_default ] section of openssl.cnf). I recommend you to use it and look at the code to learn what it is actually doing.

# ./CA.sh -help
usage: ./CA.sh -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify

This script will use the defaults provided in openssl.cnf, and/or you can provide one configuration file as an argument to the openssl $command using the -config switch if not using CA.sh.
The location of the openssl.cnf file is also distribution specific, and you can use the same commands above to find it. The one you want is the one provided by the openssl package.

You probably want to modify the following sections:

[ CA_default ]
default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL

[ req ]
default_bits            = 2048

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = AU
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Some-State
localityName                    = Locality Name (eg, city)
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Internet Widgits Pty Ltd
#1.organizationName             = Second Organization Name (eg, company)
#1.organizationName_default     = World Wide Web Pty Ltd
organizationalUnitName          = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName                      = Common Name (e.g. server FQDN or YOUR name)
commonName_max                  = 64
emailAddress                    = Email Address
emailAddress_max                = 64

Generate the CA

Once you have edited openssl.cnf to match your needs, you can generate a CA certificate. Depending on whether you need this CA signed by an recognized third-party CA or not, you can generate a self-signed CA or a CSR to be submitted for signing.

./CA.sh -newca

You will be interactively prompted to ask some questions, the defaults will appear between square brackets. You will recognize the options you modified in openssl.cnf here.

Generate a certificate for the server

You can create a certificate request for the server using the same script:

./CA.sh -newreq

Again, you will be prompted to ask several questions, the most important is the Common Name of the certificate, which must match the DNS resolvable name for the IP of the server (or you can use other means, like /etc/hosts, not recommended, hard to maintain and scale)

What you will obtain is a Certificate Signing Request (CSR for short). This will be signed by the Certificate Authority (CA) you created before.

./CA.sh -sign

Generate certificates for the clients

Repeat the steps of creating a CSR and getting it signed by the CA. When doing so, pay close attention to how you fill in the Common Name, Organization and Organizational Unit fields, as those will be required afterwards in order to configure the server.

A neat way to distribute the client certificates alongside their respective private keys and the CA certificate is using p12 bundles:

openssl pkcs12 -export -in Certificates/client.pem -inkey client.key -certfile CA.pem
-out clientcert.p12

Configure the server

Let's suppose the server you are referring to is an Apache web server. Once you have the server certificate, you configure the appropriate VHOST to serve whatever content is going to be protected by mutual SSL authentication. An example could be this phpmyadmin virtual hosts. This is working in an Apache 2.4 server, so please don't use it as-is and carefully review and test it to adapt it to your needs.

Listen                   443 https

<VirtualHost 120.120.120.120:443>
  DocumentRoot           "/srv/www/html"
  ServerAdmin            admin@company.com
  SSLCACertificateFile   /etc/pki/CA/cacert.pem
  SSLCertificateFile     /etc/pki/tls/private/phpmyadmin.company.com/newcert.pem
  SSLCertificateKeyFile  /etc/pki/tls/private/phpmyadmin.company.com/newkey.pem
  SSLCARevocationCheck   chain
  SSLCARevocationFile    /etc/pki/CA/crl/crl.pem
  SSLEngine              on
  SSLStrictSNIVHostCheck on
  SSLVerifyClient        require
  SSLVerifyDepth         5
  ServerName             phpmyadmin.company.com
  RewriteEngine          on
  RewriteCond            %{REMOTE_ADDR} !^127\.0\.0\.1$
  RewriteCond            %{HTTPS} !=on
  RewriteRule            . - [F]
  Alias                  /console /usr/share/phpMyAdmin
  ErrorLog               "|/usr/sbin/rotatelogs -L /var/log/httpd/phpmyadmin/error.log -f /var/log/httpd/phpmyadmin/error.log.%Y%m%d 86400"
  CustomLog              "|/usr/sbin/rotatelogs -L /var/log/httpd/phpmyadmin/access.log -f /var/log/httpd/phpmyadmin/access.log.%Y%m%d 86400" logstash_json
  <Directory /usr/share/phpMyAdmin/>
    Require              ssl
    Require              ssl-verify-client
    SSLRequireSSL
    SSLOptions           +FakeBasicAuth +StrictRequire
    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 256
    SSLRequire           %{SSL_CLIENT_S_DN_O} eq "Awesome Company" \
                     and %{SSL_CLIENT_S_DN_OU} eq "Development" \
                     and %{SSL_CLIENT_S_DN_CN} in {"John Doe", "Jane Doe"}
    SSLRenegBufferSize   131072
  </Directory>
</VirtualHost>

You can use as many per-directory access control as you need, the important part is that the client certificates shown must comply with the restrictions imposed by the SSLRequire directives, i.e., they must match the Organization, Organizational Unit and Common Name conditions (or other fields of the certificate as you see fit). These fields are taken from the client certificates.

Generate a Certificate Revocation List

In order to be able to revoke access to a client certificate, you need to generate a CRL.
The command to do it (provided you in the top of the CA directory structure):

openssl ca -config /path/to/openssl.cnf -gencrl -out crl/crl.pem

Afterwards, you revoke client certs as needed using:

openssl ca -config /path/to/openssl.cnf -revoke clientcert.pem

References:

OpenSSL online documentation and Apache online documentation.


In practice, does crypto software accept a *.com or or even a *. certificate?

From RFC-2818 - HTTP Over TLS:

  Matching is performed using the matching rules specified by
     [RFC2459].  If more than one identity of a given type is present in
     the certificate (e.g., more than one dNSName name, a match in any one
     of the set is considered acceptable.) Names may contain the wildcard
     character * which is considered to match any single domain name
     component or component fragment. E.g., *.a.com matches foo.a.com but
     not bar.foo.a.com. f*.com matches foo.com but not bar.com.

So I believe it would be possible to do something like have a certificate that matches a very wide variety of URLS: *.com, www.*.com, and ssl.*.com.  You may want to try double-wildcard certificates (e.g., match *.*.com), but most browsers will not (and should not) accept them.

I also would not be the least bit surprised if modern browsers disallowed wild cards in the next level down from top level domain (e.g., *.com).


How to deal with possibility of viruses on Dropbox, Google Drive, external hard drive, etc?

Is this your own home machine? If it's a work network I would just block Google drive, Dropbox etc. People tend to take things home and work on them but means you have no control over the company data.

With that said I looked around a bit and it really depends on the provider some scan some don't and leave it to you to have a scanner installed. So I would just do some research on a provider before you use their services, at least that way you'll know where you stand.

I found the following in the security section about Google Drive.

  Virus scanning: Google Drive scans a file for viruses before the file
  is downloaded or shared. If a virus is detected, users can't share the
  file with others, send the infected file via email, or convert it to a
  Google Doc, Sheet, or Slide, and they'll receive a warning if they
  attempt these operations. The owner can download the virus-infected
  file, but only after acknowledging the risk of doing so.

  Only files smaller than 25 MB can be scanned for viruses. For larger
  files, a warning is displayed saying that the file can't be scanned.

I didn't find much on Dropbox except the Dropbox help page.

  Dropbox will sync any files added to it, so if someone syncs a virus or malware file, it will be synced to any computers linked to the account. Other users' accounts and computers may also be affected if the virus or malware is in a shared folder. Malware files are generally not activated unless you click on them to open them. For this reason, just as with files from any other source, we recommend that you follow good security practices, such as running anti-virus software and exercising due caution when running unknown files from other computers.

I also found another question related to this Does Dropbox offer any protection against infected files?


Security Assessment v/s Security Engagement Breakdown

There are plenty of risk assessment methodologies. You first question should be "why building yet another one"?

The ones which exist are either generic (COBIT-based, NIST SP 800-30, Mehari, ...) or specific to an area (the EU Critical Infrastructure Protection for instance).
By using an established methodology you build credit in what you will deliver.


Just because user-entered text is reflected into a page doesn't automatically mean there is an XSS vulnerability; a lot of websites require this type of functionality.

From what I see, it looks like the website is properly HTML-encoding your input, so characters are returned in a safe format that render correctly but do not affect the surrounding HTML. However, you have to be careful when putting user input into an attribute, and there could be mistakes with the filtering/encoding. See the OWASP XSS prevention cheat sheet:

  Except for alphanumeric characters, escape all characters with ASCII
  values less than 256 with the &#xHH; format (or a named entity if
  available) to prevent switching out of the attribute.

So, you could keep trying other characters until it breaks.

That's the main reason it's probably not going to work, but there could be other preventions in place as well (e.g. Content Security Policy).


For the certificate it does not matter if it is a CNAME or a direct (A or AAAA) DNS record, all what matters is the domain as shown in the URL. The certificate must include this domain as subject or subject alternative name, it is irrelevant if this behind the scenes points via CNAME to some other domain.

From your description I assume that abc.example is your domain. And the third party wants to provide its own content under the sub-domain portal.abc.example, served from their own servers. To provide HTTPS for this the third party would need to have a certificate for portal.abc.example and also own the private key for this certificate. This could be achieved by making portal.abc.example a DNS CNAME for third-party.example. When this is done the third party could prove that it has full control over the content of portal.abc.example and could thus get a DV (domain validated) certificate for this domain.


Rogue TCP packets and SSL implict sequence numbers

I don't know what you consider a "rouge" TCP packet. But, there are two major attack vectors to consider:

Modification of an existing packet or insertion of a bogus packet: this is detected by validating the MAC of the record.
Replay of a previous packet: the recipient knows which sequence number to expect. This sequence number is when computing the MAC. When replaying an older packet the sequence number used in the MAC of the older packet will not match the one used to compute the MAC of the new packet and thus the MAC will differ.


Cracking diffie-hellman public key to obtain shared key

A "hard problem" in cryptography does not simply mean that the problem is difficult to understand or complicated to implement, but that there is no known way to efficiently solve the problem in all cases. The discrete logarithm problem, which is the difficulty of finding x given gx mod p, is a hard problem. The Number Field Sieve is the asymptotically fastest known method to compute discrete logarithms. If x is large and random, p is a non-smooth prime number, and g is an appropriate generator (like 2 or 5), then even this fast algorithm will not be able to find x before the sun burns out.
See also Can you give me a summary of cryptographic hardness assumptions?


What are the possible solution for blocking VPN connection on a home network?

This is a classical mistake: solving a policy problem with technology.

Your case is exact the same as every systems administrator trying to protect his corporate network from users using VPN and tunnels to avoid the corporate proxy. No matter how many tools and techniques you implement, there's always one obscure way to avoid the locks.

The foolproof solution is policy. You (and the sysadmin) must create and enforce a rule stating that VPN use is forbidden, users caught will be punished, and what is the punishment. In your case, losing physical access to a cellphone/tablet/console is enough.


A workaround for external website's HTTP registration page

tl/dr: This company has no idea what they are doing.  If you want to protect your data, the only option is to refuse to do business with them.

Privacy and HTTP
The first question is whether or not it is possible to communicate privately over HTTP.  The answer is generally a solid "NO!".  HTTP is a plain text protocol, which means that every server in between your machine and the destination server has an opportunity to read, log, and do whatever it wants with any data transmitted over HTTP.  This is not a theoretical problem - there can easily be dozens of servers and switches between you and the destination.
Now technically it is possible for a website to perform its own encryption before transmitting data over HTTP, thus providing privacy anyway.  In practice though it is safe to assume that this is not happening.  The reason is because doing this (and more importantly, doing it well) is quite difficult.  Using an SSL certificate over HTTPS is a much simpler, quicker, and cheaper way of providing privacy over the internet.  It would be absolutely crazy to forgo HTTPS and instead attempt your own encryption over HTTP, especially since there are large parts of the HTTP request that you still wouldn't be able to encrypt anyway.  It wouldn't be a private solution even if you tried.
HTTPS
So to reiterate, HTTPS is the simplest and most effective way to communicate privately over the internet.  Especially since the advent of Let's Encrypt, it's also incredibly easy to implement and free.  There is literally no good reason for a website operator to skip HTTPS on any website that collects sensitive data.  It's really as simple as that.
The company response
So what about this company?  They don't have HTTPS.  They are transmitting your data over HTTP.  I can guarantee you that they aren't trying to encrypt it otherwise, and that really wouldn't work well even if they tried.  That means that your private data is being sent across the internet for everyone to see.  However, they say:

appropriate security measures have been provided to guarantee the
personal data security

Quite simply, this is complete B.S.  All this means is that they believe that their security measures are appropriate.  The lack of HTTPS conclusively demonstrates otherwise.  They dig the hole further on the next line:

we will provide [an SSL certificate] as soon as possible.

As we've already discussed, SSL certificates are free and easy to install.  "As soon as possible" happened literally 4 years ago.  This is nothing but an excuse for incompetence, which leaves your data at risk.
Finally you ask:

is there a way that I can package and send the data to them securely
by alternative means

Unfortunately you are asking the wrong question.  Imagine that you do come up with some way to securely send them data.  When a company has failed so completely with the basics of data security, can you really expect them to store and use your data in a secure and private manner?
You should simply assume that whatever information you send to them, regardless of how it gets there, will eventually be leaked publicly.  Because it probably will.
Next steps?
In the end you have to decide which you care about more: the possibility of getting a job from them or the possibility of having your private data leaked.  Only you can make that call.
They mentioned GDPR, so presumably they are in a region where the GDPR is in force.  Presumably they are violating GDPR, despite their claims otherwise.  This suggests that an obvious next step is to file a complaint with the proper government organization.  I'm in the USA so I have no idea what that entails (and it is more of a legal matter anyway, so not really on-topic here).  Regardless, that is unlikely to make change happen on a timescale you need it to happen, so once again you will have to decide between using them and risking your data, or ignoring them and risking the loss of a job opportunity.


Main factors that influence information security effectiveness?

That's  not what the examiner expects, but one can say that the main factors that influence information security effectiveness are apathy, incompetence and boredom.

The "right" answer for the exam, though, is whatever is in the corresponding guide book. Unfortunately, anything which talks about "main" or "most important" factors is an arbitrary judgement, and there are several schools of thought which have come up with distinct answers, while simultaneously declaring that all other schools are deluded heretics who should be burnt at the stake insofar as their existence is acknowledged at all.

In practical terms, information security will be effective if everybody understands what is going on, and practices map to what is really needed. Employees shall be made aware of the importance of security, enlisted in its implementation, and should be happily cooperating to its realization. This requires that whatever security goals and strategies and policies and systems are used really benefit to the organization as a whole; in corporative terms, what matters is business. If a security system does something which is actually beneficial to business, and employees who must cope with that system understand this causal relation, then they are much more likely to comply to the formal security system usage rules, and will not try to work around it.

An example of an ineffective policy is a system which forces users to change their password every 42 days. This is irksome, and nobody knows how it promotes the organization goals(*), so users will resist it in creative ways (passwords written down on stcik-up notes concealed under the keyboard, "smart" passwords generated as an easy sequence,...).

(*) It is quite probable that nobody knows what good password renewal makes because, in fact, it does not make any good at all.


Is it possible to make a different encryption for a phone communication?

As the encryption is between terminal and MSC (mobile switching center) you can't by self change the encryption method because MSC will not understand it and will not be able to provide voice to your partner in conversation.

Of course you can use data channels (data trafic) and creating own application to implement desired encryption method. But to establish communication with your partner you will need a lot of infrastructure

P.S. You can't establish own radio communication as this will involved usage of specific radio bandwidths which are (usually) under government control

P.P.S. Some frequencies are free for personal usage (2.4GHz for example) but you are limited by law (usually maximim of 100 mW) so you will have relatively small coverage for calls


New social engineering tactic that uses printer serial numbers?

As written in @Rob's comment, the scammer is trying to get the S/N of your printers (information gathering, the first step in a social engineering attack) so later on will place the real scam:

either call and pretend he's your legitimate printer supplier (after all, he knows the S/N of your printers) and persuade you to order cheap paper and toner supplies for an exorbitant price;
or just send the supplies to your office. The invoice will show the S/N so it will look like a legitimate placed order.

It is worth noting that if you need to print on a specific printer you'd need to know either its network name or its IP address; knowing its S/N won't tell you anything, so "Debbie"'s request is bogus.


Why is passing the session id as url parameter insecure?

Is passing the session id as url parameter really insecure?

While it's not inherently insecure, it can be a problem unless the code is very well-designed.

Let's say I visit my favorite forum.  It logs me in and appends my session ID to the URL in every request.  I find a particularly interesting topic, and copy & paste the URL into an instant message to my friend.

Unless the application has taken steps to ensure that there's some form of validation on the session ID, the friend that clicked that link may inherit my session, and then would be able to do anything I can do, as me.

By storing session identifiers in cookies, you completely eliminate the link sharing problem.

There's a variation on this theme called session fixation, which involves an intentional sharing of a session identifier for malicious purposes.  The linked Wikipedia article goes into depth about how this attack works and how it differs from unintentional sharing of the session identifier.

  Why are cookies more secure?

Cookies can be more secure here, because they aren't something that normal users can copy & paste, or even view and modify.  They're a much safer default.

  What possibilities does an attacker have for both options?

Neither of these methods is secure from man-in-the-middle attacks over unencrypted communication.  Browser addons, spyware and other client-side nasties can also spy on both methods of storing session identifiers.

In both cases, server-side validation that the client that claims to own a session ID is best practice.  What this validation is composed of is up for debate.  Keep in mind that users behind corporate proxies may hop between IP addresses between requests, so locking a session to an IP address may accidentally alienate people.  The session fixation article mentions a few other helpful alternatives.


How does CVE-2020-0601 (ChainOfFools/CurveBall) work to undermine ECC?

To answer the second part of your question (What can be done with it?): The curveball vulnerability essentially undermines the trust of a certificate (which is crucial in PKI). This allows an attacker to sign content with a spoofed certificate. The content will appear as trustworthy to a user, even though it is not.

Basically everything that uses the Crypt32.dll for verification is affected. Arguably this is most problematic in HTTPS connections (an attacker could perform a Man-in-the-Middle attack that goes unnoticed by the user) and code-signing (an attacker could bring a user to execute code that the user believes to be from a different source).


Why are end-to-end encrypted messaging systems limited to one device per user?

It is just application developer's choice. Their idea of end2end encryption consist on an assumption that at some time two devices generate some symmetric key and encrypt the data. Keys are stored on particular device and is kept in secret. This model is pretty simple and easy to maintain.

In order to support more devices you own, there is a need to share keys between all your deivices from which you want to access the data. It is not wise to allow end user to manage keys, because users of such applications (for example, Telegram messenger) may not be enough educated to keep the secret in privacy. It would require programming ways to exchange key between devices. This immediately raise a lot of questions. For example, source device is ready to move the key to another device you own:

is the target device your device?
do you possess required permissions to retrieve the key?
is there a secure channel between devices to prevent from MiTM?
...

and others.

Of course, it is certainly doable, but would require assymetric cryptography along with complete, working and reliable public key infrastructure (PKI). Each application user (not device) recieves its own public key certificate (private key is held by the user) from a certification authority (CA) and user installs this certificate to all devices he/she owns. And this certificate would solve all question regarding user/device authentication, key transfer privacy and the rest.

This procedure is similar to common S/MIME, when you insert a smart card with S/MIME certificate to the reader on each system where you want to access encrypted emails. When done, the card is removed and email access is blocked.

The problem with this solution is that it is relatively expensive, requires reasonable investments, requires too much efforts from application vendor on implementing and maintaining the PKI infrastructure.