Is allowing users to sign out of all other sessions good or bad? I'm not really sure if this feature is a good security idea, but would it be good to allow a user to sign out of all other sessions? Or would this be a bad idea, because I see a good amount of pros, but there is one con that bothers me.

Pros:

Sign out of all other sessions to make sure your account hasn't been brute forced or pged.
Sign out of all other sessions because you left yourself logged in on a public computer.

Con:

Somebody gets into the account and signs out of all other sessions.

Having the ability to terminate all sessions that exist for a certain account is a good idea, just as it is a good idea to have 'forget me everywhere' functionality.

A user's account should be associated with a single user. If this user wants to sign in on multiple devices, they should be able to do so. Just the same, they should be able log themselves out on any and all devices they previously logged in, if they choose to do so.

The benefit is of this is that it would log out any sessions that still exist because the user forgot to log out (which is a real possibility, mainly with shared devices).

The idea that this functionality should not be implemented because it could be misused when an account is compromised, is a non-argument: if a person gains unauthorized access to an account, they can do a whole lot of bad things. Logging out any active sessions would be one of the least damaging ones, while at the same time having a fair chance of alerting the account owner of the fact that something is wrong (which is a good thing).

(The strength of the authentication scheme (1-factor vs multi-factor, as mentioned by some other answer to this question) has little to with this.)


Group Instant Messaging: How to securely store messages on the backend while supporting cross-device message history in a group chat? I want to build a group chat app where messages are transmitted and stored as securely as they can be, but where the message history is still visible after you or others in the group have changed devices. From my understanding, PFS isn't possible here.
It seems that WhatsApp has implemented PFS, which makes sense because its experience is such that, if you change devices, the previous history is gone/not decryptable. But, after researching Messenger and Discord, seems that they store everything in cleartext? Messenger has a "secret messages" mode, which appears to use PFS, however.
Anyway, my first thought here is to have two public/private key pairs for the user (account, and device), and one symmetric key for the group to decrypt messages. For the sake of simplicity, this example assumes that a user can only be in one group chat. My thought is that it would work this way:

A user has a public/private key pair generated when they sign up (we will refer to this as the account encryption key pair). This will be used for direct user-to-user messaging where history needs to be kept.
When a user logs into a device, they generate a public/private key pair for the device. The public key from this pair is sent to the server. The server then sends the user the account key pair and the group chat's symmetric key, and both are encrypted with the device's public key.
If the user changes devices, a new device key pair is generated.

This obviously adds a level of safety, but I'm still uncomfortable with this approach, because nothing prevents someone from getting around the server permissions (though there will be IAM) and grabbing all these keys. I also am not sure the best way to store the group chats' symmetric keys.
Another constraint is that I may not be able to store duplicate messages that are encrypted with everyone's public keys because of storage costs. Please also assume that a key management service like Keysafe or KMS is available, though they obviously come with limits.
What do you guys think? Am I being stupid? I looked at some other similar posts, but saw answers that didn't include tangible solutions.

As long as you're keeping the private keys in a server there will always be a risk for someone to access the messages content, either external or internal.
The only way around that would be for the private keys to never touch the server.
I'm currently working on a messaging app that has that history constraint while also wanting for the server to be unable to open any message. Currently we're exploring the use of BIP39 (Bitcoin Mnemonic Code) for the generation of the root keys, from which we then derive sub-keys for each chat room. It's a pain for the UX, since the users will have to store their mnemonic code somewhere and input it again when they login in a new device, but it's the only solution we found that guarantees zero knowledge in the backend. And from what I can gather, I don't think there's any easy solution for this problem.
The approach you've written certainly seems to be valid but I wonder if the added complexity is translated into added security (the private keys are also stored in the server).
EDIT: Take into consideration that I'm not a security expert.


Doesn't imposing a minimum password length make the password weaker by reducing the number of possible combinations? I thought the strength of a password depended on the total number of possible combinations. Therefore, allowing longer passwords should be safer because you then have more possibilities. But why do some systems set a minimum number? Doesn't this simply reduce the number of possible combinations?

Doesn't this simply reduce the number of possible combinations?

yes, but not significantly.

As an analogy, consider passwords that are combinations of uppercase letters A-Z only, with max length of 8. Total # of possibilities = 268 + 267 + ... + 26 + 1 = 217.2 billion. If you restrict this to a minimum length of 6, that eliminates passwords of length 5 or less, which have a total # of possibilities of 265 + 264 + ... + 26 + 1 = 12.4 million, a tiny fraction of the larger password space.


How secure is BitLocker without TPM? My laptop doesn't have TPM. If I enable BL PIN and someone steals my laptop and remove the drive, will they be able to read it's content on another computer? How am I vulnerable without TPM?

With just a PIN and no TPM (or removable key storage such as a USB drive or a smartcard that you need to insert to boot), it's impossible to have any meaningful security against an adversary who can access the encrypted drive. It's only a protection against someone casually walking to your desk, inserting a USB stick and rebooting your computer from the stick.

The adversary can just try all possible PIN, since all the information needed to decrypt the drive has to be present on the drive apart from the PIN. There are too few possible values for a PIN for it to be more than a moderate barrier to attack. For example, if unlocking takes 1 second of CPU time (which is an overapproximation), then a 6-digit PIN will resist for less than 12 days. A 4-digit PIN would fall in less than 1 hour and even an 8-digit PIN is manageable in 3 years of cumulated CPU time.

A strong password is a different deal because there are far more candidates for the attacker to try. A “correct horse battery staple”-type password (4 randomly generated words) would resist for around 300,000 years of cumulated CPU time.

A TPM changes the deal because when it's available, the encryption key is not derived from the PIN, but stored in the TPM. The TPM adds an additional protection: if there are too many failed attempts at guessing the PIN, it locks itself against further attempts. For the adversary to have a meaningful chance of decrypting your data, they would need to attack the TPM itself and extract the key from it, which is a lot harder than plugging the hard disk into a PC and making its CPU churn.


Is it possible to bypass HTML character reference encoding to inject SQL in this context? I was poking around with the "reset password" page of a website (security testing and bug hunting is allowed on it.)

When you put in your email address, it uses HTML character reference encoding to encode your address. For example:

Email: example@example.com >> example&#x40;example.com

Is it possible to inject SQL commands even through it's been encoded like this?

Thanks in advance

SQL injection works by skipping out from the "value" part of SQL syntax into the "command" part.

String values (as in your example) are surrounded by quotes - to break out you would need to include a similar quote in your value (like ' WHERE 1; DROP TABLE ... or whatever the actual syntax would be).  HTML encoding doesn't allow quotes, so that won't work.

I did wonder a bit about unquoted fields - e.g. if it's expecting a number (from a dropdown) but you give it a command (like 5 WHERE 1; DROP TABLE ... or whatever).  However, I'm not aware of any single-word SQL statements - i.e. you can't do anything without something to separate the tokens (e.g. a space  or punctuation ( etc.).  So even if you were looking at an unquoted field like a number then you could screw up the statement and produce an error, but not actually execute anything.


Can a rootkit hide processes from "Volatility" or other memory forensics tools? I know that a rootkit can hide processes from the OS by fooling around in the userspace. But can a rootkit also modify a processes metadata in a way that it won't even be recognized by a RAM forensic tool like volatility?

Im asking this because even volatility has to search by a specific pattern or method for the processes executed by the system the RAM dump came from.

But can a rootkit also modify a processes metadata in a way that it won't even be recognized by a RAM forensic tool like volatility?

The short answer is, not really.

Rootkits routinely change process metadata.  Cosmetic changes are made to bits that aren't vital to the process running, and significant changes are made to the bits that make the process run.  But if you make changes "in a way that it won't even be recognized" to a forensic tool, most likely you'll have made changes in a way that it won't be recognized as a process by the operating system.

In other words, the rootkit is constrained to make the process follow the rules enough to allow it to run - and by the same token, it will always follow the rules enough to allow Volatility to explore it.

In fact, a lot of what Volatility does is look for inconsistencies that are unusual in a normal process but are exactly the sort of tampering a rootkit would do.  Oh, look, the pointer for a given system call points off to userspace, not kernelspace like it should!  That's a giveaway.

Now, I said "not really..."  Volatility has a number of predefined plugins that follow rules to find things that are out of place.  Is it possible to write a new rootkit that isn't immediately obvious to these plugins?  Sure.  Clever people come up with new tricks all the time.  But then the clever, clever developers and users of Volatility find these things - you can walk through memory manually with Volatility, you aren't constrained by what existing plugins think you should look for - and they write new plugins that recognize the new evasion.

SANS forensic training uses the tagline "Malware can hide, but it must run."  For it to run, it's got to follow some of the OS's rules.  And when it does that, it puts itself on the map for Volatility to identify and explore.

(minor exception: I have heard horror stories about hardware that visited China and came back with tampering that left it beaconing home with no evidence in system memory.  If you let the enemy make changes to your hardware, then they can move beyond memory analysis.  But that's a pretty rare and exclusive club.)


How secure is L2TP+IPSEC? I understand PPTP is widely used still, but insecure. A convenient alternative is: L2TP+IPSEC.

How secure is it?

What steps in the server setup can I take to maintain a high degree of compatibility with Windows 7+ and OSX clients and still maintain strong security? For example, defining what encryption algorithms are available such as blowfish, aes-256 and 3des, DH-Group options etc.

PPTP is incredibly insecure as you've stated and provides next to no security whatsoever, there are tons of vulnerabilities in it and should be avoided at all costs. You can read more about those vulnerabilities here if you scroll down to Security

L2TP should always obviously be used with IPSec because L2TP doesn't actually feature any encryption if you run it as a standalone, which is why you will mostly see it paired with IPSec.

IPSec tends to be pretty secure. Below is a list of the Cryptographic algorithms it uses:

Authenticity & Integrity Protection: HMAC-SHA1/SHA2
Confidentiality: 3DES-CBC it can also use AES-CBC and AES-GCM. It is worth noting that AES-GCM will also perform authentication, so that could be a reason for choosing it.

IPSec will also perform a Diffie Hellman exchange before data is ever sent across a link.
You can refer to RFC7321 to learn more about IPSec, here is a very, exceptional article on the Cisco forums on how it works, I'd highly recommend reading it as it goes into a lot more detail than my post.


Is there a guide of general/common IT vulnerabilities? I'm looking for an updated and comprehensive guide of general/common IT vulnerabilities (general information).

I do not want you to do the job for me, I just want to point me in the right direction: a book or website recommendation would be great.

There is a wealth of information available from the Google search engine, but I can not recognize what information is valuable.

It's not exactly a guide, but I believe CWE - Common Weakness Enumeration is excellent source of common software vulnerabilities (not just web) and it is up to date. And of course for web application, the OWASP site contains a lot of useful information about web application vulnerabilities.


Will a browser exploit also work after I have downloaded the website? When I visit a website which exploits a vulnerability in my browser and I save this website to my computer and open later the offline version can my browser be hacked again?

Yes, but not always.

It depends on how the exploit works. Many exploits contain a second stage payload which the first stage (contained on the website) downloads and then executes. This is done for multiple reasons. For example, the first stage may test to see which second stage is appropriate for that individual browser version, operating system, etc. It may also serve to make it possible to easily update the second stage payload without needing to modify the first stage. Of course, it's also entirely possible for the entire exploit to be contained on the malicious webpage, making it dangerous to open it later.


Is there an access-control model defined in terms of application structure? I'm working on the access control component of a complex web application. One of the goals is to have a strictly defined model for who can do what, but I can't find an existing model that meets our needs.

The problem is to define a system I can query with pairs of objects (typically a user and something else, but not necessarily) to find the appropriate level of access according to the application's structure. These 'objects' are - in my case - 'models' in an MVC-style webapp. Say one of the models is a blog, and another is an interest group of some sort; a blog can belong to a group, a user can belong to a blog or a group and group can belong to another group. A example of the sort of rules I want to use: 'a user can post comments on a blog if the user is a member of a group to which that blog belongs'; 'a user can view a blog if the user is a member of a group which itself is a member of a group to which the blog belongs', and so on.

These cases are easy enough to implement explicitly in code, but I'd like a formal model like RBAC and friends. Does such a thing exist? If not, is there a good reason why?

(Edited for - hopefully! - clarity)

Further edits for more clarity:

Courtesy of Dennis' link, a definition of RBAC:

Unlike ACLs, access to a resource is determined based on the relationship
between the requester and the organization or owner in control of the
resource; in other words, the requester’s role or function will determine
whether access will be granted or denied.

In these terms, I'm interested in more complex 'relationship[s] between the requester and the organization ...', along with similar relationships between the organizations and resources of the system: rather than each resource having a list, set by its owner, saying 'such-and-such a role has such-and-such a level of access', I want the level of access to be determined by the (possibly complex) relationship between the user and the 'owner' and between the owner and the resource.

Conceptually I have a graph that includes users, organizations and resources, and I want the access control rules to be determined (in part) by the structure of that graph.

Edit: the sort of thing I'm talking about is quite similar to the 'policy predicates' in S4.2 of http://dspace.ucalgary.ca/bitstream/1880/47933/1/2010-959-08.pdf.

There is generally not a single formal model you can just adopt -- and for a good reason.  The right access control structure needs to depend upon the specifics of your application, so there is no one-size-fits-all answer.

In general, figuring out how to define access control involves looking at a few questions:

What are the resources I need to protect? What are the resources that are most security-critical?  This will depend upon your application, but it might be things like individual blog posts, the comments on a blog post, or the theme/layout for a particular blog.
What are the actions one can perform on those resources? Next, define the operations or actions someone might want to perform on those resources.  Often these are the basics like view (read), edit (write), create, and delete.
Who are the individuals who might want to perform such an action on such a resource? In access control parlance, these are sometimes called the "principals".  For instance, this might be the set of users with accounts on your site (each user is a principal).  You might also define groups (e.g., all administrators; all users associated with a particular blog), or you might allow users of your site to define groups.
What limits do I want to put on these actions? You can define a security policy.  One way to define a security policy is to determine, for each resource, what actions each principal can perform on that resource.  This might be described more concisely in terms of groups (e.g., any administrator can edit any blog post).  You can decide whether a single, fixed security policy is more appropriate for your application, or whether it is more useful to allow the users to determine the security policy.  Often it is way too much to expect users to write down all allowed combinations of (principal, action, resource), so you'll need to think about what are some common policies that might make sense for your application, to make it easier for users.

A few other comments.

I would suggest you look at some other example applications that are similar to the one you want to build, to see how they do access control.  There are many blogging platforms; why don't you take a look to see how they allow blog administrators and bloggers to control access to the blog?  See what you like and what you don't, and what seems like it works well for users and what doesn't, and learn from that.

Also, I want to introduce you to the concept of user-driven access control, where instead of you (the software developer/administrator) trying to set a security policy for your site, you allow users to determine their own security policy through their own actions.  For instance, each blog post might come with its own "view" link that users can share with others; if you share this link with Alice, then Alice will be able to view the blog post.  You can include a random unguessable token in this link, and then knowledge of the URL is all that is needed to view the blog post.  As another example, each blog post might come with an "edit" link that the blog owner can share with someone else to let them edit the blog post collaboratively -- think how you can share a Google Docs document with someone else, for instance.  In this model, each of these links is a capability that grants authorization to perform a certain action on a particular resource or collection of resources.  In some circumstances, this approach can be useful, because it provides users with the flexibility to determine their own secure sharing patterns.


How to access directories disallowed in robots.txt? While scanning my website with uniscan it found my robots.txt file which disallows access to /cgi-bin/ and other directories, but they are not accessible in browser. Is there a way to access the directories or files which are Disallowed?

The robots.txt does not disallow you to access directories. It tells Google and Bing not to index certain folders. If you put secret folders in there, Google and Bing will ignore them, but other malicious scanners will probably do the opposite. In effect you're giving away what you want to keep secret. To disallow folders you should set this in Apache vhost or .htaccess. You can set a login on the folder if you want.


Is forensics possible with FDEs like LUKS or Veracrypt? Is forensics possible with full disk encrypted drives?

I know that because we don't zero-fill our drives when we delete a file or the file system leaves a trace of a file usually forensics like recovering a deleted file or finding out that the file existed is possible.

Does that also apply to full disk encrypted drives?

If the attacker manages to obtain multiple disk image of an FDE encrypted drives over time, FDE may leak the location and sizes of the sectors that changed between the images.

Depending on what other information that the attacker already have available about you, they may be able to infer what kind of information is was changed.

Also, XTS which is the cipher mode most commonly used for full disk encryption leaks the penguin over time because of the way the tweaking works. Writing the same data to the same block will write the same encrypted block. If a certain block flips between two possible values, they may be able to infer when that flip happens and possibly which value turns into what. More information on this.

Finally, this is probably not relevant for the forensic scenario, but since XTS is not authenticated, a sophisticated attacker may also fiddle with the encrypted disk to modify the data in it.


Why block network ports? There was another good question here on why you should block outgoing traffic: Why block outgoing network traffic with a firewall?

But I was hoping to get an answer on why it is a good idea to block incoming ports or ports in general.

In particular I was thinking what difference there is between managing which applications are listening for traffic on a port on your machine, and blocking that port in your firewall.

On the surface, it's pretty silly: if you don't want traffic inbound on a given port, then just don't listen on that port. As such, host-based firewalls have traditionally been largely ingored. But recently (as in, last 20 years) the practice has picked up quite a bit. Here are a few common reasons:

Because you can't control what's listening on your computer
Host-based firewalls have been the traditional mechanism for controlling the behavior of Microsoft core services, such as port 135 and 445. In the interest of simplicity and ease-of-use, Microsoft traditionally did not allow those services to be at all controlled, which meant that a firewall was the only way to control access.

Because you want to restrict but not prevent access
Firewalls allow you to filter traffic based on more than just the listening port number, which means that you can do fancy things like allowing access only from a given range of IPs or other criteria. While not a foolproof security measure, it does eliminate the vast majority of malicious traffic, allowing you to focus your attention on the more advanced attackers.

Because you might already be compromised
This is probably the most commonly-cited reason, but also probably not the most valuable. The idea is that if you block access to additional ports beyond what you're already expected, then it's more difficult for an attacker to leverage an initial compromise to gain more complete access to the server (e.g. by binding a remote shell to an additional port). While it's true that this does make it more difficult, any average-skilled attacker can work around this restriction, so the incremental security it provides is minor.

To enforce policy
The idea here is you have a specific set of applications that are allowed to listen on the network according to your security policy, and you don't want an admin to add to that list. In the unlikely scenario that the rogue admin knows how to install software but doesn't know how to reconfigure the firewall, this would stop him.

Looking at this list, it's clear that all of these scenarios (except perhaps the first) are best met using an edge firewall as opposed to a host firewall, since filtering at the gateway cannot easily be changed by someone with admin rights on the host.

Still, just because it's better to do at the edge doesn't mean you shouldn't also do it on the host. Remember that a truly secure network is one that remains secure even without perimeter protection. Layering your defense will help keep you protected even when parts of that defense fail.


Is there a way to make sure my government does not swap out SSL certificates? I was recently wondering whether there exists a way to make sure my government is not swapping out SSL certificates in order to intercept the traffic.

I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?

One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.

If that is not a possible case, what mechanism is preventing them from doing it?

If your adversary is a powerful nation-state threat actor, web PKI will not protect you.

Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:

Government of France
Government of Hong Kong (SAR), Hongkong Post
Government of Japan, Ministry of Internal Affairs and Communications
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
Government of Spain (CAV), Izenpe S.A.
Government of The Netherlands, PKIoverheid
Government of Taiwan, Government Root Certification Authority (GRCA)
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)

While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities, including the US FPKI. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.

While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.

Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.

A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.


Can government authorities retrieve data from LUKS volume when it's accessed while turned on? I've heard that there are attacks that can get passwords out of RAM while turned on.

If a server, CentOS 7.5 and LUKS enabled, it's tty1 locked, which is on a VMWare hypervisor that is locked with a password, is gained access by government agencies while functioning/turned on, can government agencies unlock this server's virtual hard drive and read contents out of it?

Absolutely. LUKS (and other disk encryption utilities) only provide data-at-rest security. That is, the only way to access the raw data itself when the system is powered off is by knowing the encryption password. When the system is on, however, there are a number of ways to retrieve the disk encryption keys. These do not require government-level resources to pull off:

Cold boot - A cold boot attack involves shutting the machine off suddenly and putting the memory chips into another motherboard, then reading out their contents. This works because data in memory persists for a short period after the power has been cut (a longer period if they are chilled to a very low temperature). The encryption keys, or at least data that can be used to reconstruct the encryption keys, will be present in RAM. This attack is more effective for older DDR2 memory, but is absolutely possible with the newer DDR3 and DDR4.
DMA - A DMA (Direct Memory Access) attack is one where a device is plugged into the computer that can become bus master. This includes Firewire and Thunderbolt connections, as well as PCIe cards. When these are plugged in, the operating system will often grant them full access to memory, allowing them to directly read from and write to memory without the CPU's further involvement. While newer systems with IOMMU hardware may not be quite as vulnerable to this, it is still a favorite technique of law enforcement.
JTAG - There is a debugging protocol that can be used to take complete control of a CPU called JTAG. When you plug in a JTAG probe to a special header on the motherboard, you can halt processor state, read and write to registers and memory addresses, initiate IO, and more. Essentially all x86 processors support JTAG, and there is no way to disable it in software. The only reason this technique is not used more is because the above are usually more effective and a lot cheaper, but it can still be used as a tool of last resort.
IPMI - Some servers will have IPMI enabled, which allows remote access to anyone with a password. When IPMI is active in a datacenter, the password is typically known to the datacenter, and law enforcement can trivially demand access. Unless you are using a colocated server that you have physical control over, IPMI is likely supported and in use.


search CA for someone's public key do CAs offer service wherein an application can request someone's public key?

i am trying to do this but i am unsure if it is correct (suggestions of better ways to do it will be most appreciated):

someone with a certificate from a CA and is an authorized user in my application enters data to a web page (in a form)
his input data are saved to mysql fields
application (thru php and openssl) hashes and signs that data into a signed message digest
*edited:
3: application allows submitting user to hash and sign that data into a signed message digest
*
signed message digest is also saved into same mysql table row of #2 (?into a binary field?)
application viewers need to be assured that this row of data came from same person in #1
application (thru php and openssl) re-hashes data using the same hashing algorithm used in #3 and #1's public key
if hashes don't match, something got tampered and viewer is alerted

questions:
should i have another field to accept #1's public key and save it with the data and the signed message digest as well?
or can i just ask the CA for the public key of person in #1? (by passing to the CA the certificate serial number which application saved earlier with the data and signed digest)

or should i just save the whole certificate itself (from which the public key can be extracted anyway) even if the data storage requirement will be larger than if the public key alone was saved)?  in that case, should i save the certificate to a blob mysql field?

thanks for any feedback or leads.

matsakaw

@thomas: thanks for the clarification on role of CA and on certificate-based-authentication. sorry for my step #3 wording that wrongly implied it will be the application that will sign the data.

@kiBytes and @el viejo: i edited my question.

i was thinking the application will allow the submitting user to hash and sign the data he is submitting into a signed message digest.

i was thinking of the application allowing the execution of these (client-side) commands:
to allow logged-user to sign:
$ openssl dgst -sha256 -sign logged-user.key -out in.txt.sha256 in.txt

to allow any viewer to verify:
$ openssl dgst -sha256 -verify signer-pub.pem -signature in.txt.sha256 in.txt

@el viejo: thanks, i will read on time stamp servers as suggested.

thanks also to everyone else replying.  your replies are very much appreciated.

As a general case, no, CA don't let people search for certificates by public key. In fact, they don't let people search for certificates at all, because the point of certificates is precisely to avoid any kind of searching. The CA has been designed to be, possibly, completely offline, thus unreachable by anybody.

When viewers verify a signature, they use the public key, and then gain confidence that the owner of the corresponding private key signed the message. Who is that owner ? That's the job of the certificate to tell that. The certificate is a verifiable assertion that a name and a public key live together.

In your case, from clients' point of view, there is no signature, no hash, nothing; there is only your server which says "this is good" or "this is not good" on a data element which is also provided by your server. How you manage things internally is completely opaque. In that sense, as long as you want things to be that way, then signatures are completely useless. Signatures make sense only if you can, at least potentially, show them to third parties (say, to a judge in case of litigation). And since a signature only proves things with regards to the public key, not anything else, you need to keep the certificates around, because certificates then link public keys to the useful concept of identities (when you sue, you sue somebody, not a public key).

Furthermore, in your description, your server appears to be the one who signs, not the actual certificate owner. So even if you keep a signature around, it would be your signature, not that of the initial user who wrote the data in step 1.

The important concept here is that when your server authenticates a client "with a certificate", this is authentication only. It does not prove to third parties that the said client really wrote the data you store. In fact, even if you keep a complete copy of all involved IP packets, this proves only that at some unspecified past date, that client connected once to your server, but it says nothing about the data which was sent through that connection. Authentication is proof only for who is doing the authentication, i.e. the server, but is not verifiable afterwards. If that point seems unclear to you, then you must read it again, and again, until you grasp it; you cannot do any useful work with certificates if this does not seem obvious to you.


Can Heartbleed be used to obtain memory from other processes? According to http://heartbleed.com/, memory contents can be leaked from the server to the client and vice versa.

Say that I have been banking in a separate browser profile (but under the same user). If another browser profile happened to be targeted by the Heartbleed attack, does this mean that my banking session was possibly compromised? Does it matter whether Linux, Windows or something else is used?

There is a well-written analysis at http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html complete with code samples.

The author, Sean Cassidy, notes that (emphasis mine):

  What if the requester didn't actually supply payload bytes, like she
  said she did? What if pl really is only one byte? Then the read from
  memcpy is going to read whatever memory was near the SSLv3 record.

  And apparently, there's a lot of stuff nearby.

  To be honest, I am a little surprised at the claims of the people who
  found the Heartbleed vulnerability. When I heard about it, I figured
  that 64KB wasn't enough to look for things like secret keys. The heap,
  on x86 at least, grows up, so I figured that pl would simply read into
  newly allocated memory, such as bp. Keys and the like would be
  allocated earlier, so you wouldn't be able to read them. Of course,
  with modern malloc implementations, this isn't always true.

  And further, you won't be able to read the memory of any other process, so those "business critical documents" would need to be in
  memory of the process, less than 64KB, and be nearby pl.

An alternative viewpoint from Erik Cabetas of Include Security, commenting on Reddit:

  Was having some discussions w/ my friend about this bug. He thinks
  it's exploitable by using a variety of specifically sized allocations
  across the heap to read the 64k chunks all around the heap fragments,
  not in a linear type of fashion that Sean in OP's link is implying.
  After thinking about the way ptmalloc/linux allocates, I think this is
  possible for sure. The .fi guys from codenomicron are sharp dudes, I
  bet they were able to get the allocations just right in a lab
  environment.

Edit: Sean has updated:

  And apparently, there's a lot of stuff nearby.

  There are two ways memory is dynamically allocated with malloc (at
  least on Linux): using sbrk and using mmap. If the memory is
  allocated with sbrk, then it uses the old heap-grows-up rules and
  limits what can be found with this, although multiple requests
  (especially simultaneously) could still find some fun stuff.

  However, if mmap is used, all bets are off. Any memory not in use
  could be allocated for mmap. This is what the most of the attacks
  against Heartbleed will target.

  And the best part: the bigger your requested block, the more likley it
  is to be served by mmap rather than sbrk.


Strategies to protect SANs in branch offices in risky places A company has several remote branch offices located in relatively dangerous places, such as Iraq, and I'm looking into strategies to secure the SAN in the event of theft or looting. The data is commercially sensitive and contains intellectual property. Some of these offices are mobile, moving locations every couple of months.

Basically, the goals are:

Prevent data from the SAN falling into the hands of others
Prevent the destruction of data

Each site has:

A VPN, providing access to a central data centre in the USA (over a satellite link, sometimes as low as 4MB/s)
A local, highly-available ESXi cluster (note the vCentre server is located in a central data centre in Europe)
Virtual SAN storage (using StorMagic)
No local backups; backups are done remotely to a central data centre in Europe. The satellite links are often slow, and sites can sometimes be without access for several hours

At present, no data is encrypted - for this question, that's what I want to focus on.

Do you have any suggestions? Should we encrypt at the SAN level, the vSphere level, the OS level? How should keys be managed?

1 - Prevent data from the SAN falling into the hands of others

Full Disk Encryption (FDE) with large, secure passwords, unique for each server. If the SAN is stolen, all data is encrypted. Unique passwords limits the damage if some passwords leaks.

I would recommend FDE for everything (even OS files, public website data, everything), because it uses only one key for the entire computer, does not forces the user to classify the data as confidential or public. It's less problematic to protect something that could be public than publishing something secret.

  2 - Prevent the destruction of data

Backups. That's the only way.

If you have any infrastructure (even more if on a place where physical security is not always granted), you must have offsite backups. And tested backups.

Data destruction can always occur, and mitigate the results is the only thing you can do. You cannot prevent the data destruction (intentional or accidental), but you can (and must) prevent irrecoverable data loss.


why do they call packet filter firewall a PACKET filter firewall Why do we call packet filter firewalls .... packet filter firewalls?

  A firewall operating as a packet filter passes or blocks traffic to specific addresses based
  on the type of application. The packet filter doesn’t analyze the data of a packet; it decides
  whether to pass it based on the packet’s addressing information. For instance, a packet
  filter may allow web traffic on port 80 and block Telnet traffic on port 23. This type of
  filtering is included in many routers. If a received packet request asks for a port that isn’t
  authorized, the filter may reject the request or simply ignore it.

I was always told and taught that ports belong to the Transport Layer, which is Layer 4, and what's in L4 is called a segment not a packet. Why do they call it packet firewall?

You are correct in that ports are part of layer 4, but packet filtering firewalls, even though they operate mostly on layer 3, also inspect the port numbers.

Even the simplest firewalls will do this, but because they do not make decisions based on the rest of the layer 4 data, "packet filtering" is appropriate. You could think of it as "enhanced packet" filtering.


How to alert webmaster if he does not put contact address i found a session cookie that contains user status with two parameters NO for standard users when altering this to YES you become a Premium user and you can download content restricted to premium users? the problem there is no contact address to send him a message?
any idea ?

If you're looking to get in touch with a website owner then there's a couple of possibilities.

Some domains might map standard names (e.g. webmaster@[domain], contact@[domain], info@[domain])
DNS records may well contain a contact name/address.  So running 'whois' will return that info.
Also IP address whois can return contact information.  So running 'dig [web server addresss]' and then running 'whois' on that IP address might provide more info.

One thing to watch is that some people don't like their security flaws being pointed out to them so you might want to use an e-mail account that doesn't directly tie back to you, in case they decide to get awkward..


What happens when an Intermediate CA is revoked? Currently I’m working on a certificate manager that allows our product to securely connect to remote web services (over TLS/SSL). For security, we use Certificate Revocation List checking (or CRL-checking) to find out whether a certain certificate has been revoked. Still, some issues are unclear to me:

Must/should I fetch all CRLs of the complete chain to check the certificate’s validity?
What should I do when an Intermediate CA is revoked? Will all its certificates be added to the CRL as well? Can the certificate be replaced by a new (uncompromised) version?

Must/should I fetch all CRLs of the complete chain to check the certificates validity?

Absolutely.  A CA builds a CRL only for the certificates it issues.  Status of the CA itself must be checked via the CRL of the issuing CA.  Note:  This is a recursive search. When writing code, or testing systems, remember that there can be more than one "generation" of issuing CAs and check all certificates except the self signed root.  A root CA will not have an associated CRL - if the root is compromised, that root must be manually removed from any trust stores.

What should I do when an Intermediate CA is revoked?

Do not trust anything signed by the CA.  A certificate is only as good as the CA that issued it.  If the CA is becomes untrustworthy, the certificates issued by that CA are no longer trustworthy.

Do not expect to get a CRL from the revoked CA saying that all certificates issued by the CA are not valid.  If the CA is active, this will create a prohibitively large CRL that will be extremely painful to transport, parse, and generally do anything with.  Also - if the CA's key has been lost - it may not be possible to create this CRL.

In practice, the smart thing would be to remove the CA from any trust stores.  Removing the CA from trust stores will cause any application that builds it's CA chain from trust stores to fail the certificate verification quickly.  Building the certificate chain is usually done prior to any OCSP/CRL checking, so you save your application from extra steps and potentially bandwidth by trimming the revoked CA from your stores.

An intermediate CA being revoked is also a fairly major event - honestly, I've never experienced it in the real world.  If I was working on a highly secure system, I'd also publish as far and wide as I could that the CA was revoked.  Particularly any systems that may be working off CRLs that are cached for a long time.

And if I held certificates signed by this CA, I'd start formulating my re-certification strategy ASAP.

Will all it's certificates be added to the CRL as well?

No.  Note, there are two different CRLs in play:
- the issuing CA's CA (either a root CA or another CA in the chain) - issues a CRL which verifies the status of the issuing CA's cert
- the issuing CA - issues a CRL which verifies the status of the certs this CA has issued.

If you have a CA chain that is n certificates from root to end entity, you will have n-1 CRLs involved.

Can the certificate be replaced by a new (uncompromised) version?

Yes... sort of.  The compromise reflects the untrustworthiness of the private key of the CA.  The CA will need a new private key, which essentially makes it a new CA.

It is, technically, possible to rename the CA with the same Distinguished Name - if there is an operational value to that.  But in practice, my temptation would be to standup a new CA, with a new DN, just so that all humans were clear on the difference.

This will be a major pain in the rear end.  The users of the new CA will need to:
- remove the compromised cert, and replace it with the new CA cert
- recertify all End Entity certificates with certificates that are signed by the new CA.

Note that it's a matter of security policy as whether you recertify or rekey your end entities.  If the compromised system did not have access to the private keys of any end-entities, you can re-sign the same private key with a new CA key.  If you kept a store of certificate requests on file, you could resubmit them to the new CA and save yourself a whole bunch of key generation.

However, in some cases, the CA system may put some private keys in escrow - this means that in some central location (usually near the CA system), the private keys are stored securely in case the users loose their keys and need an update.  This is particularly prevalent in the case of encryption certificates, since you may need to retrieve encrypted data even after an encryption key has been revoked.

In these cases, if the CA is compromised, there's a decent chance the key escrow has been compromised.  That means that all users of keys in the escrows should generate new key pairs and request a new certificate.

Past that - its a matter of policy as to whether re-certification is allowed.  Since a new certificate will have a new validity period, it may be that the security powers that be say "no renew/recertification" because they can't limit the validity period sufficiently.


Creat IIS USER in SQL from different machine I am trying to create a IIS APPPOOL\poolName security login in SQL but getting this error "Windows NT user or group 'IIS APPPOOL\poolName' not found." I am doing this to run elmah.
doing this from different machine please post any solution stuck here.

The app pool identity allows you to access network resources using the machine account, so instead of granting the app pool access to the SQL Server by name, you simply need to grant access to the web server machine account, which looks like this:  DOMAIN\web-server-name$' Note the$` at the end, which is always there to denote a machine account.


Difference between socks5 and socks4 proxy? I know what is socks proxy and how does it differ from http proxy. I want to know what is the main difference between socks5 and socks4 proxy.

From wikipedia:

  The SOCKS5 protocol is defined in RFC 1928. It is an extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups.

And compared to plain SOCKS4 it also has the main feature from SOCKS4a:

  SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host's domain name to an IP address.


If I accept a root Cert what am I opening myself up to? If I connect to a WIFI AP and it wants to install a root cert. They read my HTTPS traffic, Right?

Does using OpenSSH on my cell phone to my home router help protect me? Or can this traffic be decrypted as well?

If I connect to a WIFI AP and it wants to install a root cert. They read my HTTPS traffic, Right?

Yes, they can read all of your HTTPS traffic including all of your passwords to any sites you log in to, all of your emails if you load your email, your credit card number if you buy something, etc. And it isn't read-only - it can tamper with them too, basically impersonating you to do anything they want, such as doing a bank transfer of your life's savings to their offshore account, if you log in to your bank.

  Does using OpenSSH on my cell phone to my home router help protect me? Or can this traffic be decrypted as well?

SSH doesn't need certificates, and the normal use case for it doesn't use them. It just compares keys directly, so a root CA won't compromise it. However, in practice, this won't be helpful, as any network that insists on a root CA will almost certainly not let you use SSH (or they may even try to MITM attack it too, but since the key would be different, you'd notice).

Note that accepting a certificate for a WPA-Enterprise connection is different than installing a root certificate for everything your device does. The former is safe and doesn't cause the above problems; only the latter is dangerous.


Penetration testing - full consistent overview I need a relevant text (scientific paper, book chapter etc.) that provides a full overview (big picture) about penetration testing.
It should include as much complete, consistent and up-to-date as possible lists of:

types of tests, what can all be pen tested (networks, web apps, wireless...)
the most common attacks for every category above
the most popular tools for some type of testing.

I don't need another text about white, gray and black box testing. Because of them I can't find what I'm looking for.

On Infosec I have found this classification:

Network Services
Web Application
Client Side
Wireless
Social Engineering.

On some other sites, I have found different classification and every book I've found has it's own classification.
I understand that maybe there is no single classification, but I need some good enough that the rest of that text (or book) is consistent with it's own classification.
I have found many books that covers some random mix of attacks that falls in different categories and now I'm confused.

I will link you some good resources at the end of this answer. But I think what you need to understand is that to fully learn something, I don't think you should be focused on trying to learn from one resource. There are tens of thousands of GOOD resources for learning in InfoSec (and in anything in-fact)

Your question seems to point to the fact you want ONE resource, I'm sorry but you won't get that. Learning is about taking stuff in, understanding it and then being able to execute it to learn from one resource is honestly... Impossible. I'd say impossible. Especially when there is so much to learn in this field.

https://www.amazon.co.uk/Penetration-Testing-Hands-Introduction-Hacking/dp/1593275641 - This book is fantastic for foundation knowledge, teaches you all kinds of attacks, how to setup a lab (for learning) and its a good foundation book which I believe a lot of people would recommend.

Heres a question here on InfoSec with resources for web vulnerabilities - Best resources to learn web security attacks?

You can also use this site - https://www.owasp.org/index.php/Main_Page

I would also look at reading this - https://www.amazon.co.uk/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441

Other than that just explore the Internet there are plenty of GREAT resources but the best advice - don't learn from one place.

EDIT This might be a good post to look at as well Penetration testing methodologies


How to check if iCloud password popup is legitimate? I was away from the computer when this popup appeared and I've no idea what triggered it. How do I know if it's legitimate popup from App Store or a phishing attempt by some malware?

Back in my WindowsNT days I would be prompted to press CTRL+ALT+DEL which is intercepted in the kernel and always opens system password prompt, so it's more secure.

The safest thing to do would be to cancel that popup and then select app store from the main menu and if it prompts for your ID, you can enter it. OSX will then cache this information. Unless your system has been so compromised that the app store app has been hacked, this should be safe.

More than likely, the reason this popup has occurred is because your OSX has detected there are updates to be applied. However, you have not signed in and therefore it cannot connect to the app store to download the update. One way you could verify this is to cancel the popup and then select updates from the app store and see if there are some updates waiting to be applied.


John the Ripper exclude incremental mode from another incremental mode I want to crack an 8 characters password. First, I tried the incremental mode digits, but I did not find the password. So now I know it's not all digits password. I want to use lowernum incremental mode instead.

Is it possible to tell John the Ripper to exclude all digits passwords?

You could use something like crunch to generate wordlists that contain at least one lowercase letter.

Then feed this wordlist into John use the --wordlist option:

john hashes.txt --wordlist=generated_from_crunch.txt


Is it safe to use a stateless authorization mechanism where the clear password is stored on the keychain? Is it safe to use the following stateless authorization mechanism between a client (iOS & Android) and server?

Sign up

The client provides an email and password and saves the clear password on the Keychain of iOS and using some alternative for Android.
The server checks the password strength if it's deemed strong enough the user is created on DB.
The server generates a JWT token and returns it to the client. The token has an expiration time of 15 minutes.
The client stores the token (maybe on the Keychain itself) and includes it for each following request on the Authorization header.
For each request, the server checks the token provided (checks the signature and the expiration time). If it's ok the request is processed, otherwise, an HTTP 401 is returned.

Sign in

When the client receives an HTTP 401 from the server it means a login is required. So the app accesses to the Keychain and gets the email & password and sends it to the server (no user intervention needed).
The server validates the credentials provided and if they're valid it will repeat the Sign Up steps from 3 to 5.

Thanks to expiration time on the token, if a token is compromised it will be valid during a short time period.

If a user is logged on multiple devices and she changes her password from one device, the other devices will keep logged only for a short time period, but the clear password stored on the Keychain will not be longer valid. So a new manual login will be required, which I think it's fine.

Which drawbacks do you see?

I've been thinking on using refresh token procedure to avoid store the clear password but this adds complexity and other drawbacks (for example: how to guarantee the refresh token is only used once). And as far as I've seen, storing the clear password on the KeyChain is secure enough:

KeyChain Services Documentation

What is the best way to maintain the login credentials in iOS?

But I also have seen other questions that do not recommend storing passwords on the device.

So I would like to hear opinions from others on this.

This is a well-asked question, and as the question itself lays out, even experts will have different opinions in the context of absolute/abstract framings of safety.

The nuanced reality of course is that there is no "absolutely safe," only varying degrees of unsafe, ranges of which may be more or less appropriate in any given specific situation.

In the absence of additional information, some starting point questions to help brainstorming/threat modeling:

What data do these credentials protect?

At one end of the spectrum, the app could be a game, the credentials protecting non-sensitive game state. On the other end, credentials could be protecting sensitive medical information.
Who are your users?

Are your users unsophisticated folks who may use the same password across many services, including your own?

Might your users be members of an identifiable group that may be more or less subject to having their devices compromised/searched/cloned (e.g. journalists, high level corporate staffers)?
What might happen to individual users and your community as a result of a compromise?

Can an actor who compromises one user's account under this app compromise other users, or steal money, or perform some other permanent, expensive damage?

You get the idea.

The one additional thought is that a password is fundamentally an especially powerful credential that is expected to work anywhere from any device at any time.

One alternative to storing the password on the device is to generate a long term, device-specific token, to be saved on the device instead of the password, and used to re-authenticate only from that device. This token doesn't have to be a single use "refresh" token- sometimes applications hash the password some large number of times and use that.

Certainly support for any additional authentication scheme requires additional complexity. Circumstances can help determine whether it's worth it. In more sophisticated situations, compromise scenarios can have likelihood estimations, and loss estimates, along with development, maintenance and support cost ranges, and Monte Carlo methods can be used to help improve the intuition on whether individual bits of complexity offer protections- by reducing risk and loss- that may be worth the long term costs.

Good luck!


Why http request signatures are useful? Please provide pros of signing http api requests.
For instance, Amazon requires requests to their web APIs be signed.

If traffic is not encrypted, then a signature can prove your identity as a secret key holder and prevent tampering with request. But what about https?
Why use request payload in this case?

You've kind of answered it in your question: HTTPS provides encryption, which prevents tampering with the request in a lot of cases, but doesn't prove anything about the identity of the person making the request in the first place (unless client certificate authentication is used, which isn't particularly common).

By getting the user to sign requests, they can be more confident that the user is who they claim to be (or, at least, someone who has stolen their secret key data).


How reliable is rpm --verify when auditing package integrity and what alternatives are there? Currently to verify package integrity, the command rpm --verify is run. In reading the rpm manual (http://ftp.rpm.org/max-rpm/s1-rpm-verify-output.html), there is no indication as to the veracity of the verification process.

It is my understanding solutions such as AIDE and Tripwire expect a known good state and are unable to attest integrity when packages have been updated and/or upgraded.

What alternatives are there to assure the integrity of packages post
installation as well as subsequent updates and upgrades?
How can corruptions by omission or commission be detected and identified?
What options are there if a known good state is unknown?

In my experience, rpm --verify is accurate enough for a first pass. I have not tried to remove a file and see if rpm --verify catches it. It does identify files that have changed.
rpm --verify is only ONE of the tools I use. I also use an intrusion detection system (AIDE) to identify files that have been added, removed or modified.
If there are specific files that I want to ensure their integrity, I use Puppet to control them. In short, Puppet uses a checksum to verify the integrity of the file. If it does not match, it can either send an alert, or replace the file with a correct version.


E-Mail signature examination If I download a signed e-mail from thunderbird, it looks like this:

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms030600030501030208070703"

This is a cryptographically signed message in MIME format.

--------------ms030600030501030208070703
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Test

--------------ms030600030501030208070703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCqGSIb3QEHAqCAMIACAQExDANBglghkgBZQMEAgEFADCABkqhkiG9w0BBwEAAKCC
...
jwa1TlS4tKAFqYZWuiJj8YTDWFLakrAyA8DAgoZrBx44gbQlq4yap+s7cLF6T6Fh27zf
E2ft5vmKsXepKPLeddVtRnbMsFnnEEY4l+4s1L6xfSp1vHLRysR33jbv1tkjSeV7bu+q
VjyyMN4AAAAAAAA=

My goal is to verify the signature of the actual message manually via openssl without the smime option. The actual signature must be in this large base64 code:

$ openssl enc -base64 -d -in smime.p7s

But this gives me a lot of unreadable code mixed with some readable informations about my CA and so on.
How can I convert this to something readable, so that I can check the actual signature of the message-text. (After that, I want to verify it using openssl dgst -sha256 -verify ...)

You can save the decoded base64-code to a new file with

$ openssl enc -base64 -d < signature > signature.dec

and use der-ascii

$ ./der2ascii -i signature.dec

to get the desired output.

You can also check the plaintext-message-digest by hand.


OpenSSL: Enable cipher suites per protocol version Is there a way to explicitly configure OpenSSL to allow AES (or in general, block ciphers) only for clients that use a TLS version >= 1.1?

This would protect against the BEAST attack, while still allowing the use of ciphers more secure than the ancient RC4.

The suggested workaround for OpenSSL (enforce the server's cipher preference order; prefer AES-GCM over RC4 over AES-CBC) excludes all clients that don't support the GCM cipher suites, even though they are perfectly capable of securely using AES-CBC due to the fixes in TLS 1.1.

It seems that many popular sites have opted to just use RC4 for everything, which doesn't seem like a really good idea (RC4 has many known weaknesses, and many TLS implementations have workarounds even for TLS <= 1.1). I wonder if a server-side "use AES, but only if it's safe"-flag could improve the situation.

From a cursory look in OpenSSL's source code, no, the library is not up to what you want. The cipher suite selection appears to be done in ssl3_choose_cipher() (in ssl/s3_lib.c) and that function works with a list of "supported cipher suites". The list is pruned depending on the negotiated version (OpenSSL won't select a cipher suite which is not supported for the version which will be used), but the list does not contain version-specific preferences.

Programmatically, it would be possible to make an input filter on incoming data, which recognizes a ClientHello message, and dynamically adjusts OpenSSL settings based on the maximum version announced in that message. This would be a rather terrifying hack, which would "just work". However, you won't have that with configuration only.

At least the protocol supports what you wish to obtain. This would not be true in the opposite direction: since the client announces in one message the maximum version it accepts and the list of cipher suites it supports, there is no way for the client to say "AES-CBC, but only for TLS 1.1+".


Should CVE be assigned to an application even if the vulnerability is in a vulnerable 3rd-party library? I found a vulnerability in a library of vendor A, I reported it, they fixed it and I received a CVE.
We noticed that some application (let's call it vendor B), contained the library of vendor A, we reported it, he updated the application with the fixed library and release it with a new version.
Should vendor B also assign a CVE to its application?
He told me that he will write in the change log of the fix, that it addresses the CVE of vendor A.
Both applications are open-source.
What is usually the process in such thing?
I thought that any program that has a vulnerability, even if they contained a vulnerable library, should assign a CVE when they fix and release a new version of their application. In such case, if the vulnerable library affects 1000 applications, should all the 1000 application report the CVE? I suppose not but I don't know.

From the CVE Numbering Authority (CNA) Rules:
2.1.2

2.1.2 If a CVE ID is being assigned to a vulnerability, the CNA MUST make a reasonable effort to notify the maintainer of the code in which that vulnerability exists.
For example, if an operating system vendor discovers a vulnerability in a library from an upstream supplier, in addition to assigning the CVE ID to the vulnerability, the operating system vendor should attempt to contact the upstream supplier. This will help avoid duplicate CVE ID assignments and ensure that others affected by the vulnerability will be made aware of it.

7.3

CNAs are restricted to assigning CVE IDs to vulnerabilities within their scope. Sometimes, a CNA’s scope overlaps with another CNA’s. Examples include researcher CNAs who discover the same vulnerability at the same time and maintainer CNAs whose products are dependent on the same vulnerable library. In cases like these, CNAs are expected to negotiate between themselves to determine who should assign the CVE ID. If an agreement cannot be achieved, then the issue should be escalated to the appropriate Root CNA.

So vendor B must not assign a CVE to its application.


Chrome is storing login POST requests in its memory I am logging in to my site using Chrome (on Ubuntu). Even if I logout and close my browser I can see the login POST request content (containing username and Password) using "Hexedit".

I have seen a similar question asked for IE, but I am not convinced with the answers provided. Most of them sounds like precautions only. I searched online for solutions. Someone suggested to use encryption on the client side, but that isn't a solution I can easily go for.

Gmail and Facbook login are not using any client side encryption (I can see my username and password sent in POST request without encryption); But I can't see any POST request saved for Gmail and Facebook using "Hexedit". So I suppose there is something that can be done?

How do I stop browsers (not just Chrome, but in general) from saving the content of POST requests sent to my site?

You don't really have to worry about this.  You aren't responsible for managing the virtual memory of a client's browser.

Think through what you're concerned about.  The only way for this to be exploited is for an attacker to be on a client's machine, and to dump the memory of the process.  If this is the case, they already have multiple easier methods of harvesting credentials (keylogging, browser Man-in-the-middle, etc...).

If you really wanted to get crazy about it, I suppose you could do something like this:

Separate the 'password' field into multiple different form elements spread around the page
Assign each character to a different variable in the POST request
Send all the characters in different order and reassemble on your side

I don't 100% know if that'll work, but I don't think it'll be easily readable in memory without some manual extraction.


Standard for securing web server to client connections via HTTPS on the local area network I am trying to set up some kind of secure client to web server connection that takes place entirely on local area networks, but I'm having trouble understanding what the recommended best practice is.

Here is my situation: I have many web servers that are each running on their own LAN, and clients will access the web server from within that same LAN. I want to secure all the client-server connections (via HTTPS or anything else) on every LAN that has my web server running on it. The web server does not need to be reachable from the public internet. There will be a backend API running on the same machines that needs to be reachable from public internet, but I do not necessarily have to use HTTPS to secure this (however, would be nice if I can solve both problems with the same solution). I cannot distribute trusted certificates to clients, but I can control DNS and DHCP on the LANs (although I want to avoid this as much as possible). I also own a domain name that I can obtain a trusted certificate for.

I have identified several options, but I'm not sure which ones are even possible and I'm certain that there must be a recommended best practice for this kind of set up. I need someone to tell me what the best practice is and why.

Option 1: Every web server gets the same certificate for the same domain name, and the DNS servers on each LAN resolve the domain name to the appropriate local address.

Option 2: Every web server gets a different certificate for a slightly different domain name (aaa.yyy.com, bbb.yyy.com, ccc.yyy.com, etc.), but they are all handled under the same wildcard certificate. The DNS servers on each LAN resolve the domain name to the appropriate local address as in Option 1. Not sure if this works any differently than Option 1.

Option 3: Every web server gets a different certificate for an entirely different domain name (www.aaa.com, www.bbb.com, www.ccc.com, etc.). This domain name would be specified by the user, and the web server would be able to go ask a CA for a certificate on the fly. Not sure if this works any differently than Options 1 or 2.

Option 4: I create a CA on every LAN, and distribute the CA root certificate to every client. This is not really an option in my set up, but I'd still like to know if it's the recommended best practice.

Option 5: Each web server self signs its own certificate and browser warnings are produced in the clients. Also not really an option in my set up.

Option 6: Use some other type of encryption on top of HTTP. This avoids the DNS configuration hassle, but doesn't prevent man in the middle attacks. Is this standardly used for connections to obfuscate plaintext passwords and whatnot before HTTPS is enabled by a user on the web server GUI?

The security is security, no matter the network zone. Yes, there are not so much potential attacckers for LAN-only server, but it's not just leveraged, but hightened by the network speed : one lan attacker on strong/stable/guaranteed 1Gbps speed can try as many passwords, as 100 attackers from the WAN/WWW/Web with unstable connection speed, for example. Use exactly the same techniques and criteria as for a public web server and you will be just fine. I'm using the next checklist working with web servers:

Only 256 bit strong ciphers
Explicitly disable old, weak and export ciphers
Make a DH params at least 4096 bit long and specify them by pointing to a file
Make your cert with 16384 key, SHA512 hash. You can use it as a single-domain-name certificate, and you can optionally make it signed by a trusted CA.

The way when you use one cert and routing clients via DNS seems to be proper one for you, but option4 with your own CA seems to be a way more secure(and laborious, sadly) because you will be able to get a client certificate to every client in your network: it will prevent a lot of "my-pass-stolen" cases. But if you'll be implementing Option4, make a single CA for all of your lan's - it will reduce a work amount not touching the security it provides.


Guidelines for secure iPhone application development Are there any security guidelines for development and assessment of (native) iPhone applications?

Here are five suggested guidelines for iPhone application development and security considerations. In general you'll find them to be the same as security for any application development.
http://intrepidusgroup.com/insight/2010/05/top-5-iphone-application-development-security-issues/


How to stop or restrict Web attack on apache? and how to know which type of web attack it is? Today Symantec antivirus has blocked web attack which is as follows

Web Attack: Malicious Scan Request attack blocked. Traffic has been blocked for this application: \DEVICE\HARDDISKVOLUME4\APACHE2.2\BIN\HTTPD.EXE

Web Attack: Malicious Scan Request

what is the hacker trying to do with my apache httpd.exe file? can anyone elaborate?

The information you are giving is insufficient, however you may Harden your Server, by filtering ports or closing the ports that are not in use. Additionally, you may add a Network Based Intrusion Detection System to get information regarding any intrusion occurs in your network.
Also, you may update the services running on ports since, using the older versions of services lead to un-authorized access to the Server by exploiting their vulnerability or a Denial of Service attack might be possible in order to crash your server.


Sharing account verification tokens to third parties This is a brief sanity check for myself to confirm whether or not the premise of the title is a good idea or not.
Suppose we have an internal system for password reset or account verification.  When a user performs an action, they are provided with a token identifying them through some external source (typically email).  That token is then exchanged in some way to identify them and properly inform an API to perform some action.
Now, we have received some requests to allow for this token to be provided somewhere else programmatically instead of through that email.  So instead of sending it via email, we would send it over HTTP to some pre-configured destination.  That destination is managed by a third party that is not us and we have no visibility into what they are doing with said token, although, presumably, they would be simply forwarding that token to the customer for us using some medium we don't support (like snail-mail, or telephone call).
This raises some red flags because we're no longer interacting directly with the end-user, but I'm not sure if I'm being overly cautious.
Can anyone weigh in on things I should be aware of to support such a system? Any caveats or security holes that we would need to watch out for, or if this is just a terrible idea and I should be ashamed for even entertaining it.
The third party is a contracted-out development team responsible for building alternative methods for users to "verify" their account or reset their password.
For example, assuming we only have the ability to send these verification tokens via email, but our client using our service wants users to be able to send these verification tokens to users through Whatsapp.
The workflow would look something like this:

user navigates to third-party.com and follows their onboarding flow.
we create account and send verification token to https://api.third-party.com
third-party captures the above request and sends the token to the user via whats app message
user receives token via whatsapp, and enters token into third-party.com
third-party.com sends an API request to us using that token, and we "verify" the account

Your requirement to provide verification codes through other channels than just email is quite sensible – but so is your concern about security. Unless you take extra steps, everyone who can intercept such a token can take over accounts. This holds for email as well as any other channel. In this case, routing verification codes through another company's service means that people who have access to the systems of that company could take over accounts. This could be malicious employees, but also attackers who have taken over the other company's systems. Of course, all of this applies to your organization as well.
So the question is what reasonable security measures can be implemented.
A lot of such reasonable measures will happen on an organizational or contractual level. For example, that other company might provide contractual guarantees to implement certain security measures, and might submit to regular audits. What would be appropriate depends on the sensitivity of these accounts: email, financial or health stuff usually but not necessarily more sensitive than an online game. This also depends on other regulatory requirements, e.g. GDPR.
You may also be able to implement some technical measures to increase security. However, in your scenario the other company mediates between you and the user so they could spoof any security measures if they wanted to.
Notably, any verification tokens you create are entirely useless.
The other company could just send the token back directly without performing verification.
Equivalently, your API with them could simply contain a boolean isValid field, which would have the same level of security from your perspective: none.
Maybe, changing the viewpoint could constitute a solution:
these are the other company's users, you merely implement white-labelled services for them.
Then, you should be providing security guarantees to the other company, not the other way around.
Whether this viewpoint is appropriate depends a lot on the specific services you provide.
Alternatively, strongly reconsider the flow where the third party performs the entire user interaction. If you can interact directly with the user but only outsource delivery of the token via the third party, that could significantly increase the security. For example, you could then ensure that the token was generated and consumed in the same browser session.


How can apps deal with phone number recycling/reassignment when sending password resets? Instagram lets users sign up with their phone number (verified by a pin sent via text), a username and password. Should you forget your password, you can request a link sent via text to your phone, to reset your password.

It hit me today that phone numbers can be reassigned to new people if they are no longer being used - so consider the following:

I make an instagram account with my phone number. I then get a new number, and don't bother updating/removing the details.
Someone who got reassigned my old number then requests a password change, and voila - they have access to my instagram account?

Seems like lyft has actually experienced something like this:
https://arstechnica.com/security/2016/02/when-phone-verification-and-recycled-numbers-collide-lyft-leaks-user-data/

So what can be done by companies using phone numbers for verification to avoid this (in my opinion) security issue?

These days, phone number reassignment isn't even the largest security concern for apps that use SMS as any part of the authentication process.  This is relatively rare and cannot be used (or at least is very difficult to use) to target a particular victim.  In essence, when it happens it does so accidentally and not maliciously.  While still not good, it could be worse.  In contrast even just using SMS is increasingly being recognized as an insecure security solution even if you don't change your phone number.  There have been an increasing number of high profile attacks that have happened due to weaknesses (of all sorts) around SMS itself.  The short of it is that SMS itself was never really designed with security in mind, and phone companies are very slow to pick up on this fact and more proactively protect their users.  Here are some good reads for examples:

https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/

What can you do about this?  Not a whole lot, unfortunately.  Many services come with text-messaging as the default (or even only option) for both 2 factor authentication and password recovery.  When this is the case, there unfortunately isn't much you can do short of complaining or using a different service.

If you're building your own service, and there is anything in the least bit valuable in it (which includes virtually any personal information) then make sure and get up-to-date on best practices for modern security, and make those the default.


What methods can be used to prevent mistyped usernames? I wanted to log on to my account on my bank's website. The account is protected by a number of security checks. The first one is what really amounts to a username, a confidential one. It's an 8-digit numeric passcode (given to me by the bank), after entering which I need also to enter some personal data and a password. Today, I was notified by the system that my passcode was locked out and that I had to contact the bank by phone. I did, and I was informed, after giving a fair amount of personal data to the person on the phone in order to verify my identity, that my account was now all good and I could log on. They also told me that was probably because someone used my passcode by mistake and, being unable to enter the correct information later on, locked my passcode out. I'm quite confident that that was indeed the case -- it seems rather plausible, though my first reaction was, "Someone just tried to steal my money!"

If that's what happened, it was an inconvenience for all parties involved: the person who was mistaken about their passcode was not, obviously, informed that they were entering a wrong passcode, and they wasted their time trying to enter the correct information later on; the bank had to use their human resources on helping me out; I had to waste my time and money on calling the bank at 00:05 AM on a Monday.

Is anything being done by banks or other entities in order to prevent such situations? What is being done? It's them who provide the codes, and I see no reason not to make them dissimilar among the users. I've not tried to do any calculating, but it doesn't seem very complicated to make sure certain common mistakes are not going to happen.

EDIT: Thank you for all the answers given so far. The answers stress the fact that the inconvenience was minor and I should be happy that was all that happened. I'm certainly not unhappy my money didn't get stolen. :) However, could you please address the question of dissimilarity? Is there a good reason not to make sure the randomly generated passcodes are immune to transpositions of adjacent digits for example?

Banks that issue numeric usernames are rather annoying. And while I am more paranoid that most, you're probably right that someone just fat fingered their ID and didn't realize it until they locked you out.

To answer the question, some banks do help ensure you are attempting to login with the correct user account. Those "Security Images" you see on some bank login pages, yes the banks tell you that those pictures help you ensure you're logging into their website. But the real benefit is to help users realize they're attempting to log into someone else's account. Sites that use this process will ask for your username on the main login page, then take you to a new page with your 'security image' and the password field. They may also ask for another form of authentication (security question, etc) before asking for the password if you are logging in from a computer they haven't seen you login from before.

If every time you login you see the image you selected on signup, you're more likely (assuming you use the site often enough) to notice when that image is different. This could mean that you're logging into a phishing site, but more likely, you fat fingered the user account.

EDIT: -- To answer your edit --

When dealing with numeric userids, there are only 10 digits and they're crammed in a very small area on 10-keys and mobile devices. Given many tens (or hundreds) of thousands users, the scarcity of digits and how close they are in two of the three common layouts, there is really no way to adequately ensure that any one ID is dissimilar enough from another to prevent common mistyping errors.

Also, if you think about it from a performance standpoint, detecting if a new ID is uniq is a very efficient and quick process in most well designed systems. However, detecting if a new ID is dissimilar from others would require iterating over every other user ID and comparing the two with whatever your algorithm is. This would be a (relatively) slow and painful process. With enough time and effort, you could cache ngrams and any other comparison points to help speed it up, but still, it's going to be slow.

In short, I'm not aware of any company doing this on user ids, certainly not on numeric ones.  (But I'd happily read a whitepaper or engineering blog about someone doing it)

A couple of other users (including Philipp) have mentioned checksum digits, which I didn't discuss since it I initially focused on the system side and the dissimilar usernames focus of the question. But in further thought it does have a place in this conversation. Checksums are often used to augment account numbers i.e. Credit Card numbers, which any first semester programming student can write a validation tool for. This all but eliminates mistyping and can be checked client side without posting to the entry form. It's impossible to say (without inside knowledge) if anyone is using this on numeric user accounts... I would venture that someone is, but I haven't seen it and since it wouldn't make for interesting discussion (or documentation) within the community, haven't heard of anyone doing it. I think we can all agree, your bank isn't. :)


Can a random person find me if my location services are turned off? I was recently asked by a friend if it's possible for someone to find someone else's location if they didn't have the location services on, on their phone. I told him I'm not sure but I didn't think so. The assumption is that the person your looking for has a phone and you can use that to find them, but if the location services are off does that make them invisible? Is it possible to find them?

Since nobody has bothered to write an actual answer: the phone company can certainly locate you. The precision isn't great, because it's based on how strongly your phone's signal is picked up by nearby cell towers (which will vary depending on things like objects in the way and is going to be a bit fuzzy anyhow because the signal strength measurement isn't designed for precise range measurement). If there are a lot of towers nearby, then you can probably get precision down to something like "that house" or possibly even "that wing of the house", which is probably good enough (it would generally work for police dispatch, certainly). If there's only one tower actually in range - which is uncommon in a city but happens out in the country sometimes - then all they can get is that you're somewhere in the tower's coverage area, and an approximate distance (presenting a rough ring around the tower).

It's worth noting that even when not expressly trying to triangulate you, the phone company will always know approximately where you are by which tower your phone actively communicates with. The system is designed to automatically and near-instantly hand off communication to another tower when you get closer to it, and this can sometimes be used to track people with loose precision. A common example is a phone in a car going down the highway; you can track about where the car is, and how fast it's going, by watching the phone switch from tower to tower as it moves. If there's only one highway along that route (and it's going too fast for any side streets that may parallel the highway), you can be pretty sure the phone is in a car on that highway, and also know roughly where it is (enough to set up a roadblock, not enough to identify the specific vehicle without further work).

Note that while turning off the cellular radio (Airplane Mode) will make it impossible to track you this way, taking out the SIM card will not. The phone presents two identifiers in normal use: the IMSI (subscriber information, which comes from the SIM card and ties the phone to your phone number, account, etc.) and IMEI (equipment information, which is stored in the phone's radios and identifies the phone hardware; it's possible to use it to track or block stolen phones, and enables emergency calls even when there's no SIM present).

In addition to the cell phone company (which will generally cooperate with law enforcement, certainly if they have a warrant), people (including law enforcement) with fake or portable cell phone "towers" could track you if you're close enough to the device for it to pick up your phone's signal. (The one used by law enforcement is known as a "Stingray", but you can build one by hacking the "femtocells" that some carriers will provide to improve signal in your house or whatever.) It's more common to use such things for intercepting phone conversations and data transmissions than for tracking, but at the very least the fact that one of them sees your phone can localize you to a specific area.


my daughter just clicked a link she got on twitter and want to know is it safe and what does it do My daughter received a masked link and clicked it, she knows better but it was masked as google.com/herusername.

https://accounts.youtube.com/accounts/SetSID?ilo=1&ddb159557ad30bff1245309e7fa3945d=30c932f295d35f2397f95d54f32c2695&ils=a27555d5867549c10d9496979e5a7e38&ilc=0&continue=https%3A%2F%2Fhangouts.google.com%2Flinkredirect%3Fdest%3Dhttps%253A%252F%252Fwww.baidu.com%252Flink%253Furl%253DZOyN65KmXpWhscXBcmYgQwhJpNccswVJCR2MabIgwM70i15yjHO7b0BGZfaDgesb%2526wd%253D452729b28a73239092af438a28144e42%2526eqid%253Dce723c0037767e80b3852a78ecce168c

she has 2 step account verification on google but worried as i do internet banking on the same machine

what is this link and what harm can it do?

— removed due to site policies regarding these kind of questions (there off-topic)


Non-validating DNSSEC aware client security implications I understood that Windows 7 and newer Windows clients are DNSSEC aware, but that they are non-validating. That means that they are not performing any DNSSEC validation, but that they can require the DNS server to perform DNSSEC validation.

When the client gets the DNS response, as I understood, it just looks at the AD (Authenticated Data) flag to see if the server performed DNSSEC validation. But wouldn't it be possible for an attacker sitting between the client and the DNS server to just send fake DNS responses to the client with the AD flag set to 1? Would the non-validating DNSSEC aware client blindly trust those responses?

Yes, and yes.

DNSSEC is the first successful attempt to add a security standard to the light-weight DNS infrastructure protocol.  DNS must remain light-weight in order for the Internet infrastructure to operate efficiently and quickly serve requests to users.  DNSSEC is backwards compatible and remains light-weight enough that DNS is efficient.

DNSSEC can be performed by the DNS servers without the knowledge or participation of client computers.  The term DNSSEC aware is a bit redundant since DNSSEC is backwards compatible.  A DNS server that does the DNSSEC validation will deliver trusted responses to DNS queries.  Specifically, the DNSSEC standard means that at the time the response is sent by the DNS server, the DNS server must have cryptographic evidence that the response is correct and trusted, otherwise the DNS server sends nothing.

The main issue at hand is that DNSSEC is not fully implemented on the DNS servers.  Some servers implement it, some do not.  If a client is configured to require that the DNS servers do DNSSEC validation, then the AD flag you mention is redundant, particularily since a DNSSEC server should not sent untrusted information to clients.  Windows computers can be configured to rely only on authenticated DNS responses, and this is what Microsoft means when they discuss 'non-validating DNSSEC-aware computers'.  See their discussion, for details.

As you observe, since the DNS server is doing the authentication, and the client is not, it is possible for attacks to be inserted between the server and client.  Such attacks could include poisoning of the client's local DNS cache and spoofing of server responses.  From a security stand-point, one would want the client to validate the DNS response.  However, there are probably implementation and efficiency obstacles for creating such a system.


Why does Facebook bother comparing old and new passwords? An answer to this question says Facebook generates a bunch of password guesses to see if they hash the same as a previous version of the password.

Why bother?  If a service forces every password to have sufficient length and complexity, why should it care if the changed password is similar to the previous password, since in theory each password is already sufficiently long and complex to meet security requirements?

Does Facebook's policy really prevent some kind of attack where hackers start with long complex password guesses and then try minor variations, or is it just an irritant for users, preventing them from using what are actually sufficiently good new passwords?

Because if Facebook can algorithmically produce similar passwords, then so can a password cracker.

The sequence could go like this:
Password compromised -> user changes it to something similar -> new password compromised algorithmically by trying similar passwords to known previous one.

Also, imagine a scenario where an account is being specifically targeted by an actual human being. The attacker may know previous passwords or have an idea what they roughly could have been (e.g. the account owner's ex romantic partner or something). In this case, a password that was similar to a previous one would be more likely to be guessed.


Are two firewalls better than one? Let's say that our first firewall has some vulnerability and a malicious person is able to exploit it. If there's a second firewall after it, he/she should be able to stop the attack, right?

Also, what will be the side-effects? I mean, would this slow the traffic or not? What are other possible effects like this one?

Here is what I mean for configuration:

Firewall 1 → Firewall 2 → Network
Firewall 1 is different from Firewall 2

As a rule, No.
Firewalls aren't like barricades that an attacker has to "defeat" to proceed. You bypass a firewall by finding some path through that isn't blocked. It's not so much a matter of how many obstacles you put up but rather how many pathways through you allow. As a rule, anything you can do with two firewalls (in the same spot) you can do with one.
Now, if you're putting the firewalls in different places for different reasons, that's another story. We can't all collectively share a single firewall.


PHP execution with special characters in the end I was trying to reproduce this vulnerability:
https://www.exploit-db.com/exploits/49294
According to the explanation, it is possible to bypass a check in a Wordpress plugin by appending a special char after php extension.
I was trying the attack, and the file is uploaded with the name shell.php<special_char> containing a simple php code <?php echo "poc"; ?>.
Then I should navigate the shell in <target>/..../shell.php<special_char> and the source code should be executed.
But how can I exploit this? PHP interpreter observes that the extension is different from php (it is php+special_char), so it does not execute the code, it just prints the source text.
In which cases is it possible to exploit a vulnerability that allows uploading files with php extension containing a special character in the end?

Uploading the file is like loading a gun. You have the conditions for harm, but nothing is harmed yet.
If there was another vulnerability or some other access that would allow you to strip that extra character, then you can trigger the code in the file.
Not all vulnerabilities mean that you instantly have access to everything. Just as technology is a stack, so are vulnerabilities. Weaknesses and vulnerabilities in each layer of the stack must exist for harm to occur.
This vulnerability appears limited to just one small part: being able to upload a "loaded gun". Now you need to figure out how to pull the trigger.