Encrypting session cookies on an Android device One of our clients has an issue with a government security audit on one of their mobile applications.

The finding states that the application stores session cookies on the device in clear text format therefore on a rooted device it is theoretically possible for an attacker to steal the session cookie while it the session is active and perform transactions on behalf of the victim (provided they can also bypass the root detection mechanism in the application itself).

My questions are:

1) Is this a valid finding?

2) If the application encrypts/decrypts the cookie on the device storage does this add more security or not because the application will have to store the key inside it?

3) If the application will encrypt cookies does this mean it will be the same key for all devices obfuscated in the program code or it will be a combination of a key with random data generated on first run to have a unique key for every device and at the same time not have a standalone key stored with the data itself.

1) Is this a valid finding?

Depends on the threat model. Is it allowed to use the application on a rooted device in the first place? Need it to be assumed that the rooted device is insecure so that a remote attacker can run its own malware as root on the device?

  2) If the application encrypts/decrypts the cookie on the device storage does this add more security or not because the application will have to store the key inside it?

It makes it harder but it does not fully solve the problem. The attacker might also change or hijack the application so that he gets access to the decrypted cookie.

  3) If the application will encrypt cookies does this mean it will be the same key for all devices obfuscated in the program code or it will be a combination of a key with random data generated on first run to have a unique key for every device and at the same time not have a standalone key stored with the data itself.

With a device specific secret it needs to be stored somewhere too which adds another attack vector (some devices have secure compartments which might help here). With a common secret more effort can be done to obfuscate it but also more time can be spend off the target device to analyze the application.

In general: the more control a user (or attacker) has over a device the less you can trust anything running on it. Thus you either need to make sure that the device can be trusted enough (like trying to detect root, make sure it has a current patch level, check for uncommon applications, trust only company managed devices ...) or to limit the impact of what can be done with a stolen cookie.


What are the techniques to detect malware call home/beaconing activities? It is very common for active malware to "call home" (or beaconing), either to fetch updates and instructions or to send back stolen information..

In an internal network where web access to the Internet must go through a proxy, the traffic that doesn't pass through the proxy and by default is dropped by the gateway firewall could be valuable to detect malware call-home activities.

What are the techniques to detect malware call home/beaconing activities?

There are a number of ways to do this, largely depending on the logs available, the exact nature of your network and the strain of malware you're infected with.

Malware can and will use your proxy, it can and will use your nameservers, it can and will run under the context of a normal user.

If you're effectively going in blind, with no indicators of concern, you could use the below to pick out potential malware traffic;

Web traffic to a domain no other device is communicating with
Web traffic to domains with known risky TLDs (.top, .gq for example)
Large amounts of DNS traffic originating from a user endpoint
Periodic traffic which calls out with a precise interval
Proxy traffic on odd ports
Proxy traffic which remains out of hours
HTTP traffic with commands within the URI (i.e, a web shell)
Unusual user agent strings


Is SWIFT (banking) Software Architecture Secure? With all the news about hacking banks and stealing money from banks over SWIFT, while the vulnerabilities weren't directly related to SWIFT, some questions arise:

Are software components of the SWIFT network certified by any external organization? Have they undergone rigorous security tests? (I'm worried they'd be available to a narrow audience, and may not be subject to enough scrutiny or security testing.)
Knowing that SWIFT was started many years ago, was the software architecture designed with security in mind?
Is the architecture available for security review?

Among other things, Swift is a cooperative organization of financial institutions who agree to using the same standardized messaging system for financial transactions. As such, they publicly promote the use of ISO 20022 as their primary standard for messaging between financial institutions. That said, each member may implement this standard using a very wide variety of software on different platforms each of which can have its own security vulnerabilities. The standard itself is a bit dated and probably could be improved, but the bigger issue creating vulnerabilities for financial institutions is each entity’s implementation and choice of security controls.

The ISO 20022 standard is accessible for review but each vendor’s implementation of it is probably not. As far as certification goes, these components would most likely be certified for ISO 20022 compatibility if anything, and not for security from an attacker’s perspective; so this is probably not something meaningful from the standpoint of your question.

I think it would be wise for the organization to create a more rigorous set of security standards which members must adhere too, possibly similar to but stronger than PCI-DSS, but I suspect there would be a lot of objections to this from member organizations that do not want the additional requirements. That said, I think you are bringing up very valid points and I think it would be very wise for organizations using Swift to put pressure on their peers to help address the security needs. More importantly, I think a lot of these member organizations are currently stuck using traditional security methods to fight much more high-tech adversaries. Now would be a great time for that organization to put a stronger emphasis on increasing the strength of its network to reduce future expenses related to breaches.

One thing that seems to also have emerged during the recent string of attacks is that SWIFT put out a request to all of the connected banks asking them to report potential breach information and cyber-attacks. As such it appears that SWIFT left a lot of the security responsibility in the hands of the individual banks and did not account for banks which would not perform appropriate security measures to defend the SWIFT network. Aspects of the attacks which have occurred may also imply that there is very little internal monitoring of SWIFT transactions from a purely fraud-detection standpoint. The following Reuters article points out that it appears that the relationships between banks is also fragile and that many of the weaker banks are unlikely to admit their security short-comings and that these short-comings may be somewhat common among all of the smaller banks participating in the network. Likewise the article goes on to talk about the importance of SWIFT participants to also increase their own non-SWIFT verification methods to add security to the less secure SWIFT process as such it would appear to imply that industry insiders don't have a lot of faith in the security of the SWIFT network and that it's a known risk in many ways.

http://www.reuters.com/article/us-cyber-heist-swift-specialreport-idUSKCN0YB0DD

Finally it should be noted that the ISO 20022 standard does not have much in the way of security within the standard itself. This is a very old communication standard without requirements for many modern security controls which would probably be required if a similar network were architected today.

SWIFT
SWIFT Standards
ISO 20022


Are there bruteforce programs that use letters of other languages? Arabic? Greek? I came across a site that had the password strength meter. I tried using 'password' and the meter did not like my password. Then I happened to try 'password' but I used the arabic translation for 'a' for the 'a' in 'password'.(can't post the letter) I noticed the meter said strong/best which is a bad password policy because its just a different letter/symbol. (FYI I was bug hunting)

This got me thinking about it actually being a good password policy because I realized not many bruteforcing include other language symbols/letters.

My question is: Would most bruteforce scripts/programs be able to guess my password?

Yes. In offline attacks, any password-cracking software that either treats inputs as raw bytes or can handle UTF8 natively can handle wordlists and some rules/appending using multibyte characters.

For pure bruteforce attacks, options are a little more limited, but it's still possible. My answer here describes how to use multibyte bruteforce with hashcat. That answer was a German-specific walkthrough of Rurapenthe's method. His post demonstrates an Arabic-specific approach.


How to specify a Snort rule connection duration? Is it even possible to specify into a snort rule the duration of a connection?

For example: in this format Hour, Minute, Second

H, M, S = 0, 2, 1

If a connection that has the duration of 2 minutes and 1 second, then alert.

Or in this sense:

If a connection is longer than 10 seconds, then alert.

How do we implement the idea?

Short answer: no.

Longer answer: If you've got coding chops, you basically need to add a new detection keyword that acts almost exactly like the threshold keyword, except it alerts for any packets after s seconds, rather than c packets within s seconds.  This might be appealing if you're already building your sensors from source in your infrastructure.  Not that hard -- a number of years ago, I rigged up a build for a customer that would actively reset brute force attacks from a given IP once reaching c count in s seconds.


How to get public key of a secure webpage? How can I get the public key of a webpage like verisign , etc. using HTTPS protocol?

This command will show you the certificate (use -showcerts as an extra parameter if you want to see the full chain):

openssl s_client -connect the.host.name:443

This will get the certificate and print out the public key:

openssl s_client -connect the.host.name:443 | openssl x509 -pubkey -noout

If you want to dig further, this question might be of interest.


Fear regarding session tokens I have read recently that sessions work as follows:

Your credentials are checked.
A token is generated and stored on server side, eg UUID, and this token is given to the client where it is stored for the duration of the session.
When the user logs out, their session token is revoked, and no longer valid.

My concern is that with people more and more relying on their browsers remembering their credentials and having sessions that never expire, or expire after a long period of time, this means that somebody might be able to just copy your token and bypass authentication altogether, since usernames and passwords are no longer needed: just the tokens.

Am I misunderstanding something, or is this a real issue and if it is a real issue, what are some means I can avoid this issue in building authentication systems?

First off, I'm not sure I completely follow this statement:

  My concern is that with people more and more relying on their browsers remembering their credentials and having sessions that never expire, or expire after a long period of time, this means that somebody might be able to just copy your token and bypass authentication altogether...

The browser remembering credentials is entirely independent from the website sessions lasting a long time. In fact, having your browser remember your credentials is a convenience so that you don't need to click on the "remember me" option on a website, so one could argue that allowing browsers to store credentials makes you more likely to logout and make your session shorter rather than longer. That being said, I do understand where you're headed with the question, so let's assume you aren't storing credentials in the browser, and instead are clicking on the "remember me" option so you have a session that lasts for a long time (maybe months). How insecure is the "remember me" option?

The remember me option is insecure in either of the following scenarios:

You are on a shared computer where someone else has access to the
same user you use, or someone else has admin access to the computer
you use. In this case another user of the computer can look at your
authentication cookies and copy your token as you suggested.
The site is using http instead of https. In this case someone sniffing the network can capture your session token in transit.

Some things you can do to help prevent from token snatching are:

Use https.
Use a short-lived authentication token in combination with a long-lived refresh token.

If implemented properly the refresh token accomplishes a couple of things. Since the refresh is only passed periodically instead of with every request, it is less likely to be compromised in the first place. When the refresh occurs, all existing authentication tokens that were created with that refresh token are automatically expired, so if the refresh is ever compromised, and two users try to use it simultaneously, there would be a continuous fight over the auth token and multiple refreshes would occur before expiration. The server could easily detect this and expire the refresh token too. Then the user would have to login again and only the real user would be able to do that. More info about this can be found here.


CSRF token generation and validation I am trying to implement XSS best practices on a site I’m making.

I am currently generating a secure token on my server and sending it back to the user as a form hidden field, then validating that token by ensuring that it has not expired and that it matches what is on database.

I was wondering what prevents an attacker from generating his/her own token. So hypothetically, if someone simply had his server generate a new token every time someone were to click on one of his malicious links which would bypass my CSRF validation.

Then I began requiring the clients IP to also be stored and checked during validation. But this would not be secure if our attacker and victim were on the same network such as a public WiFi hotspot.

My attempt at a solution: To place a cookie on every user's browser and to hash their token with the cookie's value so that I can be sure that it is not an XSS attack.

The question: I was wondering what the best practices are in ensuring that the token was originally generated by the intended user, also am I being paranoid about this?

I believe you're mixing up a few different threats and attack vectors here.

Threat: MITM sniffing or setting tokens

Location: Public wifi

How to mitigate: Use HTTPS so the connection is secured over TLS/SSL. Also the cookie Secure Flag is recommended, and an HSTS policy with preload.

Threat: XSS

Location: Over the internet

What it is: An attacker injecting JavaScript code into the page, either by enticing their victim to visit a URL for a "reflected XSS" attack, or by storing script within the system's database that is not correctly encoded on output for a "stored XSS" attack. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Correctly encode output values, implement a Content Security Policy, set X-XSS-Protection and X-Content-Type-Options HTTP headers, set the HttpOnly flag on cookies.

OWASP Secure Headers Project

Threat: CSRF

Location: Over the internet

What it is: At attacker enticing their victim to visit the attacker's site or a site compromised by the attacker that then makes a malicious request to a good site that the victim is also logged into. When the attack payload is executed, it comes from the victim's browser and IP.

How to mitigate: Generate a random token per session which is passed outside of the cookie mechanism (aka Synchronizer Token Pattern).

Your points

  I was wondering what prevents an attacker from generating his/her own
  token

Nothing - however if you have associated the token with the user session, Bob's login cannot use Alice's CSRF token and vice versa. Therefore any attacker will not be able to use their own token in a CSRF attack. A good storage location is the server-side session mechanism many web frameworks provide.

  Then I began requiring the clients IP to also be stored and checked
  during validation. But this would not be secure if our attacker and
  victim were on the same network such as a public WiFi hotspot.

A CSRF attack comes from the victim browser. Therefore, the IP address will be the same as the rest of the victim's session. Reading your paragraph again I now realise you may not have been referencing a Man-In-The-Middle situation as I described above, however I've left it in for completeness.

  My attempt at a solution: To place a cookie on every user's browser
  and to hash their token with the cookie's value so that I can be sure
  that it is not an XSS attack.

XSS is a different type of attack. If you have an XSS vulnerability then most CSRF protection mechanisms are either useless or severely compromised.

The mechanism you describe appears to be the Encrypted Token Pattern which is also a valid way to mitigate CSRF.


Password generator and password limitations I would like suggestions for a good strategy for dealing with web sites that have arcane rules about what must or must not appear in a password.

My ideal are the sites that allow a good range of characters, a relatively long password length, and no special rules. In those cases, my password is chosen by a password generator from e.g. 6820 equally probable possibilities. Nice and easy.

Even if there are rules, with a reasonably long length, I can often get an acceptable password by spinning the generator a few times.

The worst case are short passwords with rules like at least one character from each of two or three classes. My current strategy is to edit a generated password making as few changes as possible to make it acceptable. I don't like this, because it depends on my own ability to make random choices, which is not good.

Is there a better strategy, or even a known best strategy?

The best known strategy for generating a password is to generate it randomly.  The goal is for it to be as unique as possible, so that it's unlikely to be found in a password dictionary, which is often populated with passwords from previous breaches.

This doesn't change when the site has poor password requirements.

Many password managers will let you specify the types of characters that are allowed and required, as well as the password length. If you can't get your generated password to match the site's requirements, it's okay to edit the password by hand.

If you're feeling generous, and would like to help the other users of the site, you can go a step further and complain to customer service over the password requirements, citing best practices and standards, such as the NIST Authentication Guidelines.

When I complain to customer service, and if I don't care for a response, but would want to make sure their customer service department forwards the complaint to their developers -- or I see evidence that passwords are being handled in an absurdly unsafe way like being stored as plaintext -- I rudely question the intelligence of their developers, managers, and company officers while making certain that the best practices are well cited, such as pointing out the specific section and paragraph...

I.e., saying something along the lines of "the first paragraph of Section 5.1.1.2 of NIST Special Publication 800-63b sets 8 character passwords as the absolute minimum, and very strongly recommends going up to 64 characters or more. Only an idiot tells their employees to do the absolute minimum for security, and any developer who graduated grade school would know that the only technical reason to restrict password length is that bcrypt can't handle passwords longer than 72 bytes long!  After all, every password is stored as an unrecoverable hash, so input length doesn't affect output length, right?  RIGHT???"

I don't get responses when I send emails like that, but I do see that the password requirements change within weeks of sending those emails, so...


Is it secure to refesh a JSON Web Token (JWT) auth token using the user credentials? As I understand the answers to this question JWT: Is refresh an expired token is a good strategy?, one should use a refresh token to refresh an expiring auth token.

Since my web app should be stateless and I cannot tell, whether the refresh token was revoked, there is no point in using a refresh token.

Instead I want to refresh the auth token simply by sending the users credentials again to obtain a new auth token. For this to work, the client has to store the credentials in memory, which might be an issue.

Are there any other ways to achieve this, or is the only secure way adding a list of revoked refresh tokens?

The refresh mechanism is precisely built to avoid saving credentials. Credentials give you access to the whole account, whereas the refresh token only gives you access to auth tokens that will work for the designated domain.

You say you app is stateless, but if you can save credentials why can't you save a refresh token?
Besides, your app should handle expiration of the credentials as much as it should handle the expiration of the refresh token. Here are a few ways for credentials to expire:

User changed password
User lost right to run the app
Account was suspended
User changed username

So here is the basic design you should follow:

Try communicate with your resource API using your auth token
If 1. failed, try acquire an auth token with your refresh token
If 2. failed, show login view to acquire a new refresh token

I suspect you are using OAuth. Respect the design pattern you're following, doing anything out of the pattern will put you at risks.

You could also offer your users the possibility to revoke a session (refresh token). That way, they can log out a compromised device without having to change their password. If you save the password, the only way to remotely log out a device is to change the password, hence logging out all you devices.


Can wireless (wifi, blutooth..) be attacked even when not connected? For example, my computer displays a list of wifi network in range, even it doesn't connect to any of them.

I don't know wifi protocol so I don't know whether my computer must actively send information out, e.g. handshake, ack..., in order to get the information of the networks, or it only listens passively?

If it sends information out, can others know about my computer and attack it even if I don't connect to any of those networks?

The question is not only applied to wifi but any other type of wireless connection.

Most modern OSes have services that are responsible for parsing data received by the wireless interfaces, and if the code responsible for that is vulnerable your machine could be compromised.

The only way to be safe is to tell the OS to completely disable the interfaces or at the very least ignore data received by them (on Linux for example you could kill the wpa_supplicant process). This is made more complicated by some OSes as for example Google, in an attempt to violate everyone's privacy even more, has added this "always-on Wi-Fi feature" to Android where the device will scan for networks (and be vulnerable as a result) even when the Wi-Fi is turned off, in an attempt to improve location services.

A fail-safe way to protect your machine no matter what the OS has to say is to disable the wireless interfaces using the hardware switches - that would prevent the radio hardware from working unless it was specifically designed to ignore the hardware switch but we're not there just yet.


Is session-passing safe? I have a php and nodejs server. User logs in on the php backend, and, when entering nodejs, the php SID cookie is being passed through a websocket. I further take the session ID, find the session file in php's directory and deserialize it, where I can access data.

Is that safe? The websocket does not use a TLS connection.
If not(probably) why, and what are the threats?

First off, any kind of sensitive information is supposed to be transmitted via secure channels. In this case it is theoretically possible to capture the session ID using a packet sniffer on your network for the communication is not encrypted, as you say. The Wireshark tool even has a decent filter to make it easier to debug WebSockets communication. However, you say your application accesses data inside PHP's session files. What kind of further attack is conductible depends on your application, e.g. if you print out the file contents or a part of. According to the information you provided, it might be possible to forge other users' data stored in their respective session file by manipulating the session ID if the WebSocket receiver (Node.js in your case) is available not only to your PHP application (e.g. a port is exposed to local network or the Internet). Some more details would help.


Best way to deal with cross-domain authentication in intranet Firstly, I'm not sure if this is valid board to ask this question - maybe it should be asked on StackOverflow?

Overview on use-case, what we trying to achieve:

Two servers, on two different domains; Available only from inside (intranet)

SharePoint 2013, on https://shp.mydomain.com; (Claims-based authentication)
ASP.NET Web Api, on https://api.mydomain.com (? authentication); Enabled CORS for sharepoint origin.

User login into SharePoint, clicks on button - calls CORS Ajax request to the api.mydomain.com.

The problem is, which authentication for Web API should we use? User should not have to fill two login prompts... There are few candidates:

Kerberos - however as far as I know, it will require end users to configure our servers
as 'trusted sites', in Firefox, IE/Chrome and also some regedit modifications in Chrome... Maybe there is a way to avoid such complicated configuration for end-users?
OAuth2 - although I have no idea how to use it with ActiveDirectory
Use Claims-based auth from SharePoint - we could put inside the AJAX token from STS, therefore token will be available from JS - isn't it a security issue?
Custom Auth (would like to avoid this at all costs)
Your idea?

We cannot use ADFS because SharePoint 2013 is having issues with it.

What do you think about it? Which option will be the best for us and end-users?

I've used my custom OAuth2 authorization provider.

Flow:

User access SharePoint
SharePoint calls webApi /token OAuth2 impersonating current user
WebApi returns token
Token is returned to the user, now he can use it for api calls
Only SharePoint calls to /token are allowed (SSL only)

Works pretty well.


how to store key securely I will receive some secret key from server which I will use as an authentication key for a MAC function in the future. But my question is how do I store this key securely on my machine?
Will I have to re encrypt it with some other key and store it like that?

A good idea is to encrypt the key and then store on your system. Using a good  encryption algorithm like AES with a strong key is advisable.TrueCrypt is one such tool which can help you in saving your key securely.


What is the practical difference between MAC and Capabilities Both Mandatory Access Controls and Capabilities allow for fine grained privileges to be assigned to applications irrespective or in place of privileges inherited by the running user.

Is there any practical difference between these two approaches? I understand for example that a capability based operating system can rely on a token being passed while a MAC system such as SELinux can rely on what is essentially an ACL.

In practice however with both techniques an application will be restricted with fine grained privileges. Are there any differences between the approaches from a practical point of view?

The short answer: They are two entirely different kinds of systems.  They're just different.  Comparing them is a bit like comparing apples and oranges.  They are so fundamentally different -- different in so many ways -- that no one-sentence comparison will really do them justice.

Oh, that's not good enough for you?  OK, then, here's the long answer.

Background: mandatory access control.  In my view, the entire notion of "mandatory access control" (as opposed to "discretionary access control") is incoherent.  Access control systems are always mandatory; the whole point of an access control system is to enforce some access policy on subjects.  Compliance is not voluntary; subjects are forced to abide by the policy, whether they like it or not.  So the entire notion is confused; any access control system always include mandatory elements.

That said, many people use the phrase "mandatory access control" to refer to a class of approaches to security, based upon military-style classification and information flow control.  Mandatory access control systems often introduce some hierarchy of labels -- a simple example might be "Public", "Secret", and "Top Secret", or "Low" and "Hi" -- and tag data with these labels.  The system then enforces some rules to ensure that anything that's derived from confidential data will also be treated as confidential; these rules typically enforce how labels are assigned and updated as information propagates throughout the system.  A typical goal would be to ensure that Top Secret-classified information can never leak out over an unclassified channel

(Strictly speaking, this is a "multi-level security" (MLS) systems; while MLS systems are a form of mandatory access control, one could also imagine hypothetical mandatory access control systems that don't use MLS.  However, because MLS systems are the classical example of a mandatory access control system, "multi-level security" often gets conflated in many people's minds with "mandatory access control".  At risk of causing confusion, I'll continue to use the phrase "mandatory access control" to refer both to the general concept as well as to the particular notion of multi-level security, because this is how the term seems to be used in the literature.)

Bell-Lapadula is an example of a theoretical model that is often considered representative of the mandatory access control approach.

SELinux is sometimes classified as a deployed system that implements mandatory access control, but this may be a bit misleading.  SELinux has at least two configurations.  In the strict configuration, SELinux enforces information flow control rules to every process running on your system.  However, this is too strict for general use.  Therefore, this is not how SELinux is deployed in practice.  In practice, the Linux distributions that have adopted SELinux have instead deployed it in so-called "targeted" mode.  For most intents and purposes, targeted mode limits only certain applications (there are a few global rules that apply to all applications but they are very narrow).  Targeted mode consists of a set of ad-hoc rules about what kinds of information flow and accesses those applications can do.  It only places restrictions on a subset of applications, and those restrictions are partial.  It does not try to provide comprehensive security.  It does not try to ensure that, e.g., Top Secret-classified information can never leak.  Therefore, SELinux -- as it tends to be deployed today -- is a watered-down version of mandatory access control that falls short of what the original proponents of mandatory access control envisioned.

Object-capability systems. Object-capability systems are an approach to enforcing authorization policies.  The core precepts are: access to a particular resource is granted to those who hold a corresponding capability (and only if the capability is held); capabilities can be freely passed from one subject to another; and capabilities are the only means by which access can be obtained.

Object-capability systems are designed to solve a particular problem.  The design goal is that the OS should provide a very limited, simple substrate for expressing access control policies.  Thus, the OS provides a few very basic primitives (the ability to use a capability, the ability to pass a capability on to another subject), and nothing more.  What about applications that need to enforce rich access control policies?  Rather than building support into the OS for each individual little thing that some application might want, in an object-capability system the application is empowered to implement its access control needs using the basic primitives provided by the OS.  This keeps the interface exposed by the OS simple, while still preserving flexibility and enabling applications to express and enforce complex access policies.

Beware: "POSIX capabilities" are not capabilities. If you'll allow me to take a tangent, I'd like to inject a note of caution.  You may have heard of POSIX capabilities.  This name is unfortunately and poorly chosen.  They are not, in fact, capabilities at all.  Rather, the OS identifies a set of a dozen or so special privileges that are typically granted to root in a conventional Unix system, and allows processes to be granted a subset of these privileges.  However, they are not held by processes as a capability, and there is no notion of passing them from one process to another.  In other words, despite the unfortunately-chosen name, they aren't capabilities at all.  Therefore, to prevent confusion, I'd like to exclude them from this discussion entirely (unless you tell me that "POSIX capabilities" is actually what you were interested in learning about).

Comparisons. Let me draw some comparisons and contrasts between mandatory access control and capabilities.

Confidentiality?  Traditionally, mandatory access control systems have focused on enforcing confidentiality restrictions: e.g., ensuring that classified-Secret data is never leaked to anyone without a Secret clearance.  In contrast, object-capability systems usually focus more on integrity and access control.

One reason for this is covert channels: no access control system can eliminate covert channels, and covert channels allow two colluding parties to conspire to defeat the purposes of traditional mandatory access control systems.  If Alice has clearance to access the secret data, and Alice is conspiring with Bob, then Alice can arrange to leak the data to Bob, no matter what any access control system tries to say about this.  Object-capability systems recognize this and don't try to prevent it; they subscribe to the slogan "Don't prohibit what you can't prevent".  Mandatory access control systems try to prohibit this, even though they can't prevent it, and published work on mandatory access control is often evasive about covert channels or ignores the problem entirely.
Feasibility?  Unfortunately, traditional mandatory access control policies -- while appealing in their elegance -- have turned out to be not very practical.

The primary challenge is the phenomenom that "eventually everything floats to Top", meaning that eventually almost everything in your system gets labelled with the top-most confidential label: e.g., Top Secret.  Why?  Well, imagine a spreadsheet containing some Public data and some Top Secret data.  It will get labelled Top Secret.  In general, any time you perform any computation that depends upon both secret and non-secret data, mandatory access control systems will label the result as secret.  If Alice sends a non-secret message to Bob, and Bob is labelled secret, and Bob returns an acknowledgement back to Alice saying that he received her message, then mandatory access control systems will often label Alice as secret (this is intended to capture the fact that the acknowledgement might convey secret information from Bob to Alice).  So basically any time that secret data mixes with non-secret data, it all gets labelled secret, and any time that a subject with access to secret data interacts with a subject with only non-secret data, they both get labelled secret.  This acts as a one-way ratchet that causes more and more data/subjects to be labelled as secret.  People have observed that, over time, most or all of the system eventually gets labelled as secret, and then the system becomes useless to non-secret users (you might as well have just said that this system is only intended for Top Secret data).  This renders mandatory access control systems less useful than one might expect.  As a result, traditional-style mandatory access control has seen little deployment.

Modern mandatory access control systems do try to avoid this problematic phenomenom, by introducing various variations to the basic MLS concept listed above.  (For instance, SELinux's targeted mode avoids the "everything floats to Top" phenomenom, by avoiding trying to provide comprehensive information flow protection for all confidential data.)  However, these variations on the traditional mandatory access control concept tend to introduce their own problems:
Complexity?  In principle, both mandatory access control and object-capability systems are built upon a simple and elegant theoretical foundation.  However, in the real world, mandatory access control systems are typical forced to depart from this elegant foundation if they want to avoid the "everything floats to Top" phenomenom.

As a result, deployed mandatory access control systems -- like SELinux -- tend to be extremely complex.  Even in its targeted mode, SELinux's access control policy specification runs to something like a hundred thousand lines of access rules.  This makes the system hard to understand, when something goes wrong.  SELinux is notorious for causing hard-to-debug failures in some use cases, and on Linux distributions that use SELinux, you'll often see people suggesting that users try shutting off SELinux if they run into a hard-to-diagnose system administration problem.

So far, object-capability systems as implemented retain much of the elegance and simplicity of their theoretical foundations, so they don't seem to suffer from this complexity problem as much.  However, we don't have as much practical experience with object-capability systems, so it is hard to know for sure whether this early experience will hold up.
Who sets policy?  In mandatory access control systems, usually it is envisioned that some omniscient and benevolent system administrator will establish the access control policy that everyone must abide by.  However, in practice, this can get really annoying.  I'm sure we've all had the experience where some firewall or security system prevents us from sharing data with someone else, or some company security policy makes it hard for us to grant access to someone we're working with.  What do you do when that happens?  Why, send it in an email attachment, of course.  In other words, having a system administrator set the security policy for everyone often fails to reflect users' actual needs, and the result is that users work to bypass the security.

SELinux is similar.  In SELinux's targeted mode, the idea is that omniscient and benevolent SELinux experts will establish an access policy for each application you might ever install, specifying what files and resources that application is permitted to access.  These policies have to be based upon the SELinux experts' guesses and predictions about how you might use the application, and what you the application might consequently need to access.  However, in real life, SELinux experts are not omniscient, and sometimes they fail to anticipate how people might use their applications -- causing the SELinux policy to occasionally block legitimate program behavior.

(In principle, end users can write their own SELinux policies and modify the default system policy.  In practice, not so much.  The level of complexity makes this way beyond the means of most end users.  In practice, I would expect that 99.99% of SELinux distributions use the default policy, because modifying it in any substantive way is too difficult.)

In contrast, object-capability systems don't rely upon an expert and well-informed system administrator to set the policy for everyone.  Instead, each application is empowered to enforce its own access policy, based upon the needs of that application.  Thus, access control is not specified in advance by a single central party; instead, it is determined, on the fly, by the combined actions of application developers and users.
Least privilege?  One of the benefits of object-capability systems is that they tend to guide application developers towards designs that respect the principle of least privilege.  Because the default is that each application receives no access, except for whatever it capabilities it is able to acquire from other sources, this tends to lead towards designs where each application receives no more privilege than they need, and where the same is recursively true of components and subcomponents of the application.

Some mandatory access control systems also try to enforce the principle of least privilege.  For instance, in SELinux's targeted mode, SELinux experts analyze each covered application to determine what actions it might legitimately perform and what security privileges it needs to be granted to perform those actions.  Then, these experts write a system security policy which specifies, e.g., the list of files and network sockets and other resources that, e.g., sendmail is permitted to access.  That policy is distributed with your Linux distribution and is the same for everyone.  In principle, this can also move us closer to the principle of least privilege, but it scales poorly: it requires a handful of experts to write rules for every application covered, so they can cover only a subset of applications (hence the "targeted" mode); it is trying to restrict legacy applications, in whatever form they come, which often means that no useful restrictions can be applied (try thinking about how to write a set of SELinux rules to limit emacs; what set of files are you gonna allow it to access?  the only sensible answer is "everything", which defeats the principle of least privilege), whereas object-capability systems can do better by guiding application developers to write their applications in different ways.
Deployment experience? We have more experience with deploying mandatory access control systems than with object-capability systems.  The conventional wisdom says that traditional mandatory access control systems are usually too restrictive and often prevent people from achieving legitimate tasks, though this doesn't apply to SELinux's targeted mode.  The conventional wisdom says that object-capability systems cannot support legacy code well and require us to start over from scratch and re-design and re-implement our entire system and all applications running on it; this is probably the biggest shortcoming of object-capability systems.

There is a lot more to be said, and there is a lot written on capability-based security, object-capability systems, and mandatory access control.  This answer only scratches the surface.  I suggest you do some background reading.  Then, if there is any aspect you'd like to learn more about, try asking a more focused question.  Tell us a little bit about your particular application domain, about your requirements/goals/concerns, and what you've read so far, and then we can give you some more detailed advice.  Or, tell us more about what specifically you'd like to know, and we can give you some reading recommendations.


Site inaccessible with Cookies turned off in browser Whenever I access my website with cookies turned off in browser, it redirects me to a google support page that informs me to allow cookies. My website is simple (a blog) HTML and CSS and I store nor ask for any data from the visitors.

I have noticed that whenever I visit the site, it's URL extends by /?i=1, /?i=2 and /?i=3  - what's that?

How could I prevent this behaviour?

My website is simple (a blog) HTML and CSS and I store nor ask for any data from the visitors.

Are you sure your site is only HTML+CSS? Your site wouldn't happen to be using some free hosting service that collects and sells user data, would it?

The fact that they're adding URL parameters that have nothing to do with your pages (the /?i=1), and that you get redirected to some help page that's not yours if you disable cookies strongly suggest that there's more going on here than just your HTML+CSS. Likely their webserver is processing the incoming requests, stripping off the user tracking information, and then serving your HTML+CSS content.

  How could I prevent this behaviour?

Change hosting providers to someone less sketchy.


What is the state of the art for forcing logout on browser quit? Background:

Most browsers have implemented some form of "Session Restore" functionality as a convenience to users where, if enabled, session cookies will be persisted across browser restarts.

Firefox has "Show my windows and tabs from last time"

https://bugzilla.mozilla.org/show_bug.cgi?id=443354

Chrome has "Continue where you left off"

https://code.google.com/p/chromium/issues/detail?id=128513

The browser vendors have a defensible position for keeping these features. This puts the onus on users to configure their browsers "correctly" and/or manually log out of the sites before quitting the browser.

Question:

For a site that provides access to highly sensitive data AND is used in shared computing environments, what are the best practices for guaranteeing that a session is destroyed when the browser is closed?

Possible ideas include:

Listening for onbeforeunload events or similar and counting the number of open windows or tabs. When the count goes to 0, send a message to the server to invalidate the session. This seems problematic, due to: a) cross browser event-handling quirks, and b) navigation away from the site, intentional or accidental, would be treated the same as closing the last tab or window.
Implementing a "heartbeat" in the client code that once absent for a period of time invalidates the server session. This also seems challenging due to: a) network latency possibly causing false-positive logouts, and b) some browsers suspending JavaScript code for backgrounded tabs (or applications on mobile).

Are there any other approaches that are reliable across the various web platforms? What are the highest-security websites currently doing in this space?

The best here would be to use a combination of cookies AND Rolling session IDs in URL (where a session id is put after the Query, like thisfile.php?sess=biskgndjkgnsldgsgdj) where this session ID Changes with each request.

This ensures only one tab or browser window is valid at one specific time.

Then you use the heartbeat system. The heartbeat can easly be constructed to send like 1 beat per 4th second, giving 15 beats per minute.
And then logout the user on server-side if ALL beats are absent for a whole minute.

15 beats are not going to get "delayed or lost" due to network latency. If one single beat arrives to the destination, timer is reset and allows up to 15 beats missing again.

Note: You CANNOT prevent that sensitive information is visible in the last browser window visible, since that is often based on information cached in the client, even if you use no-cache and no-store pragmas.
Thats why you should construct the UI to require a separate action for each opening of sensitive information dataset.
Requiring a separate action also make sure you can log the access to each dataset.

Example for a Medical data application (change to fit your application):
Lets say that you in Medical application can view a patients adress, a patients medicine history and patients 10 last visits.

Instead of showing all data on same page, allowing this information to be unauthorizedly cached, you can for example instead have a button to "reveal patients adress", a button to "reveal medicine history" and a button to "reveal patients 10 last visits", all these do a request to the server.

Thus if the user of application never press "reveal patients adress", then Anonymous medical data is going to be cached on the client.

If application has some sort of transaction log containing highly sensitive data, its better to split it up in Days, weeks, months or whatever is suitable with regards to how frequent events is, so each block of log data must be opened separately.


Can my employer monitor personal device use on my home network? I occasionally work from home. I have a work laptop that I bring home and connect to my company's network using my home WiFi (I assume it has its own direct connection). I also have my personal computer and my phone nearby, which also use my home WiFi but have nothing to do with my company's network. I use a browser-level VPN on my personal computer.

Will my employer be able to see what I'm doing on my home computer? I know better than to browse the Internet on my work laptop. The only shared thing between them is the use of my home WiFi.

Edit: I have my home network configured as "Public" so network discovery and file sharing are turned off, but I don't know if even that's entirely foolproof in this day and age.

They would have very limited visibility even if they went out of their way to configure it; on top of that, I would not expect them to do so.

They could scan your network and identify devices by IP and host name; a good scanner will often identify OS as well. Active measures of this sort are (a) detectable and (b) highly uncommon on user workstations. Restrictive firewall rules may limit detection, but Windows was discoverable on the public profile by default the last time I checked---just the machine itself, though, not details like shares/applications/services.

If they put their NIC into promiscuous mode, they could listen to any broadcast traffic on the network. Windows devices in particular are noisy, and if your router and computers are configured for DHCP then they could find everything eventually.

In a highly unlikely scenario, their system could run a rogue DHCP server that attempts to route all network traffic through their workstation by presenting itself as the network gateway. This is (a) extremely impractical, (b) unreliable, and (c) detectable. With browser-level VPN, they would be unable to see what you are browsing or downloading even in this extreme scenario. Depending on how your VPN handles DNS queries, they might be able to identify the domain. I.e., your browser must resolve security.stackexchange.com in order to load this page, and DNS resolution is typically handled by the OS. If your VPN traps that DNS query and resolves it over the VPN, then the security.stackexchange.com name would not even be visible.

In the end, it is extremely unlikely that they would see anything significant on your network. If your Windows machines are running default settings, there are some neighborhood discovery protocols that will touch the work machine, and incoming communications are often logged. However, these limited probes reveal very little (typically IP, OS, host name, and workgroup name). Unless you have a specific reason to be suspicious of their intentions, you probably don't need to worry. The level of effort required to snoop effectively is generally a deterrent, and that doesn't even consider the possible legal and PR issues.


How to stop malicious WIFI from infecting my computer? Was reading this: How to check if a Wi-Fi network is safe to connect to?
When I came across some comments

I can redirect you to other pages without your interaction. Install key loggers. Heck if your browser runs activeX objects I could open a shell on your machine without your knowledge. That last example is rare these days but what's not rare is tricking you into installing a shell for me, keylogging, session stealing, and redirection.
Or as I mentioned in my post, drop a crypto miner on your machine with the tool I wrote

Written by Anthony Russell in the comments of his answer.
So, this looks bad, obviously. What I want to know is how can I stop these attacks? Blocking javascript sounds like a good start, the original post also suggested to check my device for open ports (they did not demonstrate how to shut them though). What else? Is there a fool-proof way to prevent these sort of (virus injection? remote control?) attacks?
To be clear, I am not talking about logging. That's a given when you connect to any network. Please also dont give any advice along the lines of "don't connect to malicious networks". There are reasons that I cannot switch away from a (possibly) compromised network.
What I'm most worried about is virus injection. But other attacks (like key loggers) mentioned above are serious concerns too. Just share whatever comes to mind. I'm sure other people will fill in the blanks.
Sorry if I sound like a complete noob. That's because I am. Sorry in advance.

As Anthony Russell wrote in the answer to that other question you referenced:

Always use TLS and if you can, connect to a VPN whenever you're on a public wifi. Make sure that you don't have any unnecessary services running on your machine that are open to the network. Honestly, you probably shouldn't have any ports open. Any openings are potential access points. Also make sure your machine is fully patched and running all available firewall services.
Mind you this is all just mitigation. If you're connecting to public wifi points you have some accepted risk.

That is good advice.
The idea about TLS or VPN is these are ways to get end-to-end protection (authentication, encryption, etc.) so they can ride securely even over untrusted networks.
The idea about not having unnecessary services/ports on your machine is that even if your intended traffic (say, checking your email, etc.) is protected by TLS or VPN, there can still be attacks as incoming traffic from an attacker goes for your open services/ports.


Dealing with violating privacy of registered users during failed authentication We are forth and back discussing how to deal with privacy issues during failed authentication, password reset and account creation on a web application.

Let's say I am in the process of creating an account on an application and I am using an email that is already in use. If sending user feedback directly to the end-user saying "this email is already registered" the application might expose privacy sensitive information for the account using that particular email. I could for example check whether a certain person has an account on the application simply by using his/her email address during this process.

This for sure is a problem when it concerns applications dealing with sensitive content (like for example websites similar as second love or tinder).

Similar issues occur when resetting passwords or trying to log in with the wrong password. Useful user feedback seems like a must, but could be used by others to violate privacy of the already registered users.

For registering an account the problem could easily be solved by sending feedback in the line of "further instructions are sent to your email".
This does not necessarily mean the account already exists. In the email could then be written that "the email has already been linked to another account" including instructions how to proceed or when the email is not yet in use we simply send a link to activate the new account that allows the user to finalize the account registration process.

Similar could be done for password reset: "further instructions are sent to the email address". This doesn't expose anything.

But for failed login attempts such solution is not particularly user friendly: "this email password combination is not recognized".

The user might wonder, did I use the wrong email address or wrong password!?

Lot's of websites simply send feedback in the line of: "we cannot find an account with that email address" or "wrong password provided".

With privacy rules/laws getting stricter every day after many scandals I wonder whether the above response is acceptable for any web application, but it seems like even the big ones (Google, Amazon, Facebook, etc) don't seem to mind and simply show that the email used is recognized.

Am I exaggerating the care for the privacy of the applications registered users?
Is there some best practice or useful read on this particular topic?

EDIT:
Older questions on stack-exchange and other blog posts are mostly discussing the topic of exposing user information from a security point of view. But the General Data Protection Regulation (GDPR) is kicking in soon and I am particularly interested in the privacy issue related with revealing account specific information.

I like how the GDPR states: "implement appropriate technical and organisational measures". Now you should take a risk based approach to define appropriate. In sensitive cases like second love this would be totally different then for a more generic service like social media. So no you are not persee exaggerating, but it does depends on the risk context, and or if the data is already available publicly. For example my github account shows my email in the commits.

The Privacy by Design principle Full Functionality – Positive-Sum, not Zero-Sum states:

  Privacy is often positioned in a zero-sum manner as having to compete
  with other legitimate interests, design objectives, and technical
  capabilities, in a given domain. Privacy by Design rejects taking such
  an approach – it embraces legitimate non-privacy objectives and
  accommodates them, in an innovative positive-sum manner.

So, I like how you are trying to find a way to be both user-friendly, secure, but also respect privacy. Sounds like you might find a new innovative way, be sure to share your findings.

To be on the safe-side you could always send out the same reply that does not expose anything. You could do usability testing to see if this really an issue. Personally I think if I cannot login and immediately a reset password link is shown, that that is more user-friendly. Since this often the next step I take. If the reply is the reset password link has been sent, but if the account does not exist you send a registration email instead, that would also feel user-friendly. As I can now just signup instead. Without exposing if I already have an account to the public.

Similar you could always handle the registration process by email, this way you know the owner is the only one to know his account already existed. An email like: Hi, your email address already has an account, do you want to reset your password instead?

Now if all fails, you could ask existing users to give consent to expose that they are using the system, for the purpose to make it more user friendly. Pretty sure this is not a good idea though...


Make sure signed message can't be reused over IRC chat I want to send "administrative messages" over an IRC chat. So for instance, I want to be able to give points to a person during an animation and everyone can see it in their UI because I can change their web client.

Given I sign a message with an RSA key, people can make sure I issued the message the first time. However, I would like to prevent people from reusing my signed message.

Several problems I though of :

I could simply add a timestamp to the clients but there could be synchronisation errors and the message can be reused if fast enough
I could cache the messages that I issued so they can't be reused again but people can disconnect and then come back and would have missed the messages, the same problem is true for sequence numbers.
I could use challenge responses but the network is quite slow and dispatching a message to a handful of clients could slow down my own messages.

Is there any way to do this?

There are four major approaches to this sort of problem, which can be combined to get more desirable security properties.

Cache the received messages. In this approach you keep a list (of the hashes) of all received messages. If you find a message in said list, you discard it as a replay. The obvious problem here is the amount of storage needed.
Use time-stamps / expiration. In this approach you add a time-stamp / a time-window or an expiration time to your messages. If they are received outside of the agreed upon window they are discarded. The disadvantage here is that if the attacker is fast enough he can still replay and you need to have a relieable clock. This can be effectively combined with the first approach.
Use sequence numbers. In this approach you add a sequence number to your messages. Messages are discarded if their sequence number is lower than the expected value. The obvious disadvantage is that state synchronisation is required.
Use challenge-response. In this approach the client sends an unpredictable challenge to the server, the server includes this challenge in the message and the client keeps the challenge white-listed. As soon as a pending response to an open challenge is received, the message is accepted as valid. As soon as a valid challenge has been accepted the challenge must not longer be considered valid for future use (ie discarded). The obvious disadvantage to this is that the parties are required to be on-line, ie exchange messages somewhat symmetrical and in a timely manner.

For your system, it sounds like the minimal synchronization from the first two approaches offers what you needs.
TLS uses the third approach for the bulk data transport and something like the last for the handshake.


Why brute-force the password instead of the key directly? This answer on another question on security stackexchange by a very reputed user explains why he prefers GnuPG over OpenSSL for file encryption. From what I understand, it can be summarized as this:

  When using OpenSSL, the encryption key used is derived from MD5(password+salt) with only one iteration. So it is easy for an attacker to brute-force the password and get the encryption key.

My question is: Why would an attacker want to brute-force the password instead of the key directly? For example, if the key is 128 bits long and my password is 16 characters long (128 bits), my (password+salt) is already longer than the encryption key. This means that is would actually be easier to brute-force the encryption key directly instead of the password and the number of iterations in the Key Derivation Function is irrelevant.

But the answer given above is often linked as a reference on many other similar questions and it is from a reputed user. So where is the flaw in my reasoning?

Brute-forcing the key vs brute-forcing the password

Brute-force the key

To brute-force the key directly I need to keep guessing keys and attempting to decrypt the encrypted file with it until eventually the file decrypts properly. Without any extra information, I need to try the 2128 possibly key values at random.

On average I will need to do 2128 / 2 = 2127 guesses. By the way, this is a massive number! Physics reduction: one ARM assembly instruction (ADD, SUB, XOR, ...) consumes about 300 pJ ~= 3.0x10-10 Joules per instruction on a low-power embedded device. The sun contains roughly 1.2x1044 Joules of nuclear fuel. Assuming we could guess a key and try decrypting the file in a single ARM instruction (which is bananas, you're looking at millions of instructions for a reasonably-sized file), then doing this brute-force attack would require consuming 2x1015 stars! Yeah, 2127 is a massive number. Good luck with that brute-force attack. Hope you have a good electricity rate.

Brute-farce the password

The length of the password is only relevant insofar that a 16-char password has more possible combinations to guess over than an 8-char password. While your 16 character password may require 128 bits of disk space, it is certainly not 128 bits of security. For starters, there are only 95 printable ASCII characters, so for a password that only uses keyboard chars (no accents, emojis, etc), at best you're looking at 9516 ~= 2105 possible 16-char passwords to guess. On top of that, we know that 30% of accounts on the internet have a password from the top 10,000 passwords [source], so the length is actually irrelevant if you're one of those 10,000.

Putting it together

Brute-forcing the password, if this is some random internet user (ie they are inventing their passwords the way the average internet user does), then you have a 30% chance of cracking it in the first 10,000 guesses. If I'm brute-forcing the key directly (without using any extra knowledge), then I have a 0.0000000000000000000000000000000003% (3x10-35) chance of cracking it in the first 10,000 guesses.

Basically, passwords are weaker than keys because human brains are stupid and predictable. If your password came from a random generator, then this is a completely different story because it's really more of a key than a password.


Security test lab setup I want to setup a testing lab in my basement for penetration/vulnerability testing & offensive/defensive security skills. I believe I have all the equipment that I need, and if I'll need something else, I will get it. I also have Cisco routers, firewalls, and managed switches. Money and resources are not an issue. How do I setup a lab if I have one host machine and three to four guest machines? Obviously, the host is the controller, but what OS and VM do I use? With the other machines, do I use one for Backtrack, one for Snort, one for Linux distro, one for Windows OS, e.t.c.? Any ideas on the structure of the setup?

So if I was you I would start relatively simply with some VMs and a host machine.

Personally I use VMWare workstation but other virtualization products are possibilities.

If you've got a decent enough machine (e.g. 8GB RAM, Quad-Core Sandy/Ivy bridge, fast disks), I'd recommend keeping the Host OS clear of lab tools or target Apps, as re-building VMs is an awful lot easier than physical kit.  As to Host OS, I'd go with whatever you're most comfortable with as long as it runs your virtualization software of choice.

Then have a tools VM, and some targets.  I'd start with Kali for the Tools VM and then have a selection of targets to attack.

A good place to start is the post that @hamza-dzcyberdev mentioned in his comment.  Also you could look at pentesterlab who look to have some good free materials.

Once you've got the basics hanging you could start to introduce the physical systems (e.g. firewalls, routers) that you can't easily get Virtual versions of.


I want to pass an encrypted password to another program to decrypt I am trying do something similar to this or this.

I have managed to break the second post down into two jar files. I want to be able to use a command line, pass a password to it, and generate and encrypted password. This is step one (which I have successfully done). My output now is two things:

1) An encrypted password

2) a key, who's output is something like: javax.crypto.spec.SecretKeySpec@######

My problem is now the second part. I want to have another program that decrypts those into a password that can then be sent to log into an application.

My issue is that I cannot seem to set the key in the decrypt program manually. I really only have code to generate it.

Like it would be great to do something like

SecretKeySpec key = args[1]

But that is impossible because SecretKeySpec is not a string and that output is also not the key, but fully-qualified-class-name@hashcode

I guess my issue really boils down to this: I need to store an encrypted password in a config file that was created by program1. I need another program (program2) to be able to decrypt it. But how do I do that if program2 does not have the key that used to encrypt the password in program1?

I feel like I am going to a totally wrong path here, any guidance to get back on track would be greatly appreciated.

At the high level, it sounds like you're trying to get both programs to agree to use the same password.  You might then be muddying the issue by adding a second constraint to this, which is "how do I move the password securely from program 1 to program 2?"

This is the classic problem that Secrets Management solutions were developed to handle.  Have you considered using a secure storage program, like Hashicorp Vault?  You can give both programs 1 and 2 access to the same vault instance.  Then, your secrets are always stored in the vault, and only taken out by the programs as needed.


Securing access tokens? Preface: I have no experience with securing applications whatsoever.

I'm building a web app that uses Google Plus authentication to sign users in. My initial thought is to save the access token that gets returned after sign in and store that on my server and use it as an access token for my web app.

I have a concern that this isn't very secure. Anyone who is watching network traffic on my web app can see the token (in headers) and can copy it and form their own malicious calls. Even if the request was encrypted, isn't it possible for it to be unencrypted?

On the other hand, an attacker would need to have their victim signed in already which would imply physical access.

Anyone who is watching network traffic on my web app can see the token
  (in headers) and can copy it and form their own malicious calls.

That is correct.  This is why you would want to make sure you use a secure connection (HTTPS in the URL), which will prevent man in the middle attacks.


Ransomware - Full disk wipe versus formatting Typically when I encounter ransomware/cryptoware on a device I will fully wipe the drive(s) with at least one pass using a utility such as DBAN. I sometimes wonder if I am overestimating the potential of the malware (ex: rebuilding itself)

Is doing an offline full format of a drive just as effective as a full disk wipe would be in completely nuking a compromised device?

Your disk wipe can be a useless/waste of time if no-one tries to recover those previously deleted files from that drive. In which case, a normal deletion of all partitions and formatting is all that's needed

or

It can be a good safety measure if you know that at a point someone will try to use recovery tools to recover deleted files from the drive.

This is actually about if you want to prevent infected files from being recovered or not.


Risks of securing REST API using SSL? We are thinking of building a REST API where all calls are over SSL.  After successful login subsequent calls will include a token which was returned by the login service.  The server will validate that the token is legit and valid.  Is this considered a valid method of securing an API?  What are the risks here?

This assumes many other components of the system are secure. Likewise it doesn't protect the API from direct attack by a bad actor who can register for an account (may or may not be an issue for you). It is also always wise to have in-band protection for connections to any service. Maybe look at something like a Web Application Firewall (WAF) or something like mod_security to add additional controls. Some of it depends on how secure you want things but there are lots of additional security controls depending on your application.

See the OWASP REST Security Cheat Sheet for more information about REST specifically and don't forget to harden your servers and secure your network as well.

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet


What do emails have to do with the spread of WannaCrypt? After the recent spread of WannaCrypt, there has been a lot of warnings about the dangers of emails and clicking on links in them.

But the malware is spreading as a worm using SMB to infect other vulnerable computers.

Here is Microsoft's answer to the problem:

Customer Guidance for WannaCrypt attacks (Microsoft Technet, May 2017)

you'll notice they have no mention about emails in there.

My question is in the title:  What do emails have to do with the spread of WannaCrypt?

Many organizations don't have SMB directly exposed to the internet, but SMB is widely used internally by organizations.

It is believed that the initial attack vector for WannaCry was /is a malicious email. Once a single computer on a network of vulnerable computers is infected, it is then able to propagate itself to other vulnerable hosts on the network via the MS17-010 vulnerability.


Any residual effects after SQLMAP has been run? Some time ago, penetration testing was done on our website, and one of the tools used was SQLMap

It was executed by a security consultancy, but unfortunately they did not notify us beforehand.  So, seeing that they were in the middle of enumerating the tables in our database, we treated it as a genuine penetration and blocked their IP.

The environment in question is Windows based with an IIS webserver and SQL Server 2012 database server.

I've just recently been reviewing documentation for SQLMap and was a little alarmed to see references to Metasploit and uploading of binaries.  Until now I thought sqlmap was a passive scanner that would expose data that was previously considered secure, but now I am worried that the act of running SQLMap may have left new vulnerabilities behind.

The machines are regularly patched, behind dedicated firewalls and have virus scanners installed (for what it's worth) so we're taking what we thought were reasonable precautions.

Is any simple evidence to look for or a diagnostic tool to run to see if we're more vulnerable than we thought?

The SQL Injection vulnerability should have been reported in the pen test report along with guidance on how to fix it.

I would go back to the pen testers and ask them if you have any worries about what was done, if they didn't go further than enumerating the databases then metasploit payloads shouldn't have been uploaded to the server but definitely go back to them and ask if you have any doubts.

You should be able to see in the report how they exploited the vulnerability and from the information provided you should be able to reproduce it yourself.


SMS based 2FA intercepts Reddit just revealed that they experienced a security breach as a result of an intercepted SMS based 2FA. Another post on SMS 2FA refers to flaw in the telecom’s ss7 protocol that was used to perform the breach.

I’m not sure if the Reddit incident involved the ss7 technique or some sort of spear phishing to get some malicious code installed on the device that received the SMS.  However if an intercept was used I would have expected the original device to have received the message and the owner realizing they didn’t request it and alert their company’s security team. That being said, would the hackers have been able to block the legitimate device from getting their request for an SMS 2FA or would they have had to wait for the target to request one and just try to beat them to the login?

It's not clear from the article if the attacker intercepted the SMS code or if he just found a way to bypass it. I think we can't really say what happened without more details.

However take a look at the "Ghost
Telephonist" attack shown at Black Hat USA 2017, which is just a real world example of how an attacker could intercept a call or an SMS without forwarding it to the end user.

Also keep in mind that not every user take action when they receives a 2FA code: people could think "someone got my password but 2FA stopped them from logging in" and ignore what happened.


What are the advantages and disadvantages of using a HackRF One compared to specific protocol sniffers? I am performing some research on IoT test tools and came across the HackRF One which can transmit and receive from 1 MHz to 6 GHz. I therefore think that it can analyze many protocols, but I cannot find a list of them anywhere. Can it for example analyze (and exploit) Zigbee, Z-Wave, LoRaWAN, RFID and NFC? Why is there no list, because there are too many protocols? Is the HackRF a more general sniffer then?

I also came across some specific protocol sniffers, like the Suphacap Z-Wave Sniffer and the Proxmark and so on. What are the advantages of these over the HackRF? Is the best option to start with a HackRF and then when necessary buy specific sniffers according to the needs of the current pentest?

I would like to know this, because then I know which devices to afford for penetration testing.

From sniffing POV, HackRF One as well as many other SDRs give you radio wave processing capabilities. This means that you can tune to a wide band of frequencies and capture the signal. What you do with it then is generally beyond the SDR's scope.

You can always try to process the signal yourself (e.g. with GnuRadio) and write a decoder the data packets for the corresponding protocol (or use Wireshark if the decoder is already available). With the popularity of HackRF One there are often solutions available to work from, e.g. this Z-Wave tool claims to support it by default.

I have no hands-on experience with protocol-specific sniffers (sb. correct me), but I would expect them to provide the promised feature with little effort, while locking you from easily doing anything unsupported (e.g. capturing new/tweaked version of the protocol or tuning to different frequency than usual).


What is the difference between a data leak and a data breach? What is the difference between data leak and data breach? Could you give an example of what the insider threat would be for a data leak and a data breach?

Reading the section "Who Causes Data breaches" on Kaspersky page I think I  understand, but please help me with examples.

"Breach" has a specific meaning: existing controls were somehow broken or bypassed. This could have been accidental or malicious. Outside or inside people could breach controls. Hackers who manipulate a system to gain access to data they are not authorised to access is a data breach, as is an employee going against policy/procedure which exposes data.

"Leak" is a more general term and simply refers to the outcome that data was made available to unauthorised people. This could have been caused by a breach (broken or bypassed controls) or through other means. If there was no control in place, then unauthorised access is merely a "leak".


How can I enforce that an SSH private key has a passphrase? My company is serious about security and willing to move to SSH key-pairs. Users can generate their SSH key pairs independently and I worry if they set a pass-phrase. Can I enforce this? Does signing with ssh-keygen help?

No. You can't enforce on the server side that the key has passphrase. Key is always on the client side and the server sees only the signature of challenge and public key. Certificates (aka signed keys) will not help either, because the public keys are signed.

I propose you to have a look at some kind of two factor authentication or smart cards if you want to go this way in security.


Why WebSockets doesn't apply SOP? I can't understand why SOP (same-origin policy) cannot block Cross-Origin WebSocket Hijacking, I just read this article and I can't understand from where WebSocket requests comes from.
From where does WebSocket requests comes from, that SOP cann't block attacks related to it ?

Same-origin policy considers all of these origins to be different:
http://example.com
https://example.com
ws://example.com
wss://example.com

So if browsers were to apply SOP rules to WebSockets, if a page at https://example.com tried to connect to a WebSocket at wss://example.com it would fail.
In theory WebSockets could have been designed to use CORS headers during the initial HTTP handshake, but these two technologies were developed at roughly the same time.


How Windows FAX DLL injection works? On Wikipedia page we can read that "Windows FAX DLL injection" exploit would allow a user with malicious intents to hide its own malware under the DLL of another application.

How does it work exactly? Does popular antiviruses successfully detect such DLL injections of this type?

You can find the information at Wikileaks page.

This is a simple DLL hijacking attack that we have successfully tested against Windows XP,Vista and 7. A DLL named fxsst.dll normally resides in \Windows\System32 and is loaded by explorer.exe. Placing a new DLL with this name in \Windows results in this being loaded into explorer instead of the original DLL. On Windows Vista and above, the DLL‘s reference count must be increased by calling LoadLibrary on itself to avoid being unloaded.
This achieves persistence, stealth, and (in some cases) PSP avoidance.

So basically:

Compile your application as .DLL
Place it in C:\WINDOWS as fxsst.dll
It will be loaded by explorer.exe - (perhaps killing is enough)

The original file is located in C:\Windows\System32\fxsst.dll (handles T.30 Fax Protocol), but if you place another DLL called fxsst.dll in C:\WINDOWS this one will be loaded instead.
From Vista and above you need admin rights to install the DLL and you have to call LoadLibrary on your own DLL Loadlibrary("C:\\WINDOWS\\fxsst.dll") to increase the reference count or it will be unloaded with FreeLibrary.


What's the down side of a dynamic numbered radial keypad? Every time I visit a clinic, office or train station I notice how easy it is to figure out the PIN required to unlock the staff-only door by just watching an employee entering the restricted area.

I usually don't have to do anything, not even trying not to get caught, simply it's pretty easy to know the PIN from a decent distance because the keypad design in typical and everybody knows the location of the digits and which one corresponds to which square.

However I went to the bank and the keypad there had a different design which made it difficult to guess the PIN. What is the down side of this design? why don't we see it used in safes?

There is a Security User Experience (SUX) downside, which you might consider to be minor.

As someone who is more kinestheticly inclined, I don't memorize things like phone numbers or PINs: I memorize patterns. If I was forced to use this keypad, I would have to use a compensating method to remember the actual digits (like writing it down).

While not everyone is strongly kinesthetic, it is a factor in how people learn, which means that others might need to write down the passcode, too. This, of course, defeats the purpose of having a dynamic keypad.

As I say, it might be a minor point, but it is a downside that impacts security.


Is knowing someone's card expiration date a means of finding info about them? Card as in debit or credit cards. I heard that even showing someone your debit/CC can be considered an exploit not because of the number or name, but because of the date of expiration. He said that working backwards from that date they can tell exactly when it was first issued and can keep going from there on. I wanted to know if this is a real concern or just a hunch.

Can expiration dates on cards really give way for one to find more info about a person? I believe the date working backwards thingy is true.

No. The date on the card is set by the issuer. So the length of time can be different from vendor to vendor. Even might be different depending on the card or account type. So you would have to know exactly what that time frame is to get the issue date. The issue date is also not a security question at financial institutions to verify the identity of a customer. Whereas the expiration date itself might be. But not enough on it's own. So phishing would be an unlikely use for the date unless you already had additional information about the customer. (IE Last 4 of social, last deposit amount, account number, other information about that card, etc) All of which are impossible to get from the date.


To DMZ, or not to DMZ So for an assignment, we need to create a scheme (and eventually also the set-up) of a couple of servers in a network.

The 'networks' are:

Internal network
DMZ
The internet

And the servers we need to place are the following:

DNS Server
Active Directory ([multiple] DC's)
MSSQL server
Webserver
MS Exchange 2010 Server, split up in 3 parts: Client side, SMTP, and
other functionalities (whatever those may be)

Now I was wondering which of these servers to put in the DMZ <-> internal.

The MSSQL server and AD server(s) should be placed inside the internal network. Of that I am quite sure (? :D).

The webserver and DNS server should be in the DMZ, right? I just dont know why, so any explanations about that would be greatly appreciated as well.

But then there are the three Exchange servers. I have absolutely no clue about where to place which part of these 3. Could anyone give some hints/tips and best practices about (mail)servers?

Also, to route/firewall these networks (internal, DMZ and internet), we use the Forefront TMG.

Any help is greatly appreciated!

You put in the DMZ the servers which must be accessed from the outside. Since they are reachable from the external World (which is assumed hostile), these servers are potentially subject to hijack by attackers. The DMZ is a containment area so that a subverted server does not gain immediate access to your most valuable data (which will be presumably kept in the inner network).

Your AD and SQL servers are meant to be used only by machines from your network, not by machines from the outside, so you put them in the inner network. Your Web server is meant to be contacted by external clients, so put it in the DMZ. Similarly, the DNS server which publishes to the outer world your domain (e.g. the IP address of your Web server) is also meant to be accessed from the outside, hence DMZ.

There is no rule without exception. Occasionally, you will need to have some data path from outside to the inner network. Typically, emails come from the Internet but must ultimately appear on desktop systems. You normally want to store the incoming emails in servers which are in the inner network (this is the presumed safest place in your network) but if you run your own SMTP server (for incoming emails), then that one has to be in the DMZ.

It really depends on your exact situation, but the rule of thumb is simple: DMZ is for that which can be contacted from the outside.


OSSEC Rules Group Explanation I am new to OSSEC and Cyber Security in general and would like to understand it a bit better. OSSEC provides so called "Rules Groups" alerts get assigned to and I would like to understand those groups a bit better.
https://www.ossec.net/docs/docs/manual/rules-decoders/rule-levels.html#rules-group
Some of the 12 groups are pretty straight forward and do not need any explanation what kind of alert gets assigned to the group. However, I do not know what the following groups mean:
attacks
adduser
sshd
ids
firewall
squid
apache
syslog

Maybe someone of you knows that and could help me out or give me something to read!
I tried to google but didnt find anything helpful.

Here's a brief explanation regarding the kind of alerts assigned to each group:
attacks: Events associated with attacker activity (brute force and code injection attempts for example).
adduser: New accounts created in the system.
sshd: Events associated with the Secure Shell daemon (for remote access to terminal in Linux machines)
ids: Alerts from Intrusion Detection Systems.
firewall: Events from firewall software or hardware.
squid: Events from the Squid proxy.
apache: Events from the Apache web server.
syslog: Syslog messages from various sources (this can be software, network devices or other syslog producing sources).


Are mulitple Service Accounts more secure than a single account? I have a server with three custom processes running under a single domain account.

A security "expert" has recommended that three accounts be created, and each one should run under a separate account.

How is that more secure?

If you have one account for 3 services this means that if one of the services have a security issue and an attacker can get in, he will access to the other services files for example. By having different accounts, you reduce the impact of this effect. This depends on your case but if you have 3 services such as HTTP, DNS and an LDAP is a good idea to have different accounts for them in general.


iPhone passcode security With iOS 11 I was compelled to switch from two-step-verification to two-factor-authentication. This has the implication that somewhere at Apple there is some blackbox that can decide, using my AppleID credentials(?), whether a given passcode coincides with the actual iPhone passcode.

When I wanted to check how many bruteforce attempts I have I run into the convenience feature which allow unlimited bruteforce attempts with the same passcode.

Given this I have two questions:

I asked Apple support if this weakens the security of my passcode.
They say no. How can this be possible if off-device bruteforcing is
possible?
The fact that entering the passcode twice doesn't increase the
counter makes me wonder how the counter is triggered. If the passcode
attempt is first checked against the actual password and then checked
against the last attempt, wouldn't there be a delay between when the
passcode is checked and the counter is incremented during which the
phone could crash? Wouldn't this potentially allow a brute force
attack, or am I missing something?

Recap and basics
First off, let us take a quick recap on how to prevent brute-force attempts.
A brute force attack is one where someone tries lots of different passwords (potentially sequential) until they get into the system.
With this in mind, there is really only one way to prevent brute-force attacks: throttle the speed with which attempts can be made.
Example
If all passwords were 8 alpha characters, there are 26^8 ≈ 208 billion password combinations. If a brute force algorithm was restricted to one attempt every second, it will take approximately 26^8 / (60*60*24*365.2425) ≈ 6617 years, so this would be one easy way to prevent brute force attempts without interrupting the user experience.
Most systems, (probably including iOS) are more likely to have an incremental throttle system, something like:

normal max rate is 1 per second (that is quick for a person, really slow for a robot)
after 10 incorrect attempts, this reduces to 1 per 10 seconds
etc.
after a successful login or a specified amount of time, the rate resets.

Caveat
This incremental throttling type of system can massively penalise individuals with long passwords and/or a disposition towards mis-typing their password.
If a person mis-types their password the same wrong way, how many passwords have they actually tried? Only 1, so why would it throttle them more than that.
As such, a decent throttling system would also store a hash of the attempted password, and only track number of unique passwords attempted.
Side note
This could be an interesting (though unreliable) way to determine if it is a user attempting to log in or a robot - a robot attempting to brute force would be much quicker (unbelievably so) and would never need to attempt the same password twice.
Summary (and answer to the ops question)
You have tried the same password multiple times, so might not trigger anything as there is no brute force attempt.
Even if you were to attempt different passwords, it is unlikely you will be able to enter them quick enough to trigger anything that prevents brute force attacks: you are nowhere near as quick as a robot.


SYN flooding attack causing high CPU on hardware firewall I have a ZyWall USG 200 firewall. A few days ago there was a SYN flooding attack on it causing 100% CPU load. After investigating it turns out this was attack from a single IP address and while the attack was going on the WAN port was downloading at 30Mbit/sec. The uplink on the firewall is 1Gbit and the attack didn't affect anything else on the network.

Blocking the attacker's IP address on the firewall didn't do anything.

I did a SYN flooding test myself and it shows that the firewall is very sensitive to SYN flooding. I have all content scanning services disabled because they cause high CPU load so I'm only using the firewall service.

I have contacted ZyXel and they responded that there was nothing I could do except wait for the attacker to give up. That is unacceptable because apparently anyone with a decent network connection is able to bring it down.

Is this normal and common issue in low-end firewalls? Is there anything I can do to prevent this?

If you have a router in front of your firewall, configure the router to drop the packets originating for the IP address. Your router should be better equipped (I hope....) to deal with that level of network activity compared to the firewall.


How to transform an hash into a usable password? I was reading about PwdHash and it inspired me to create a little project where you input a master password and an easy to remember alias into a password hash, like bcrypt, and then you get an hash.

So far so good ; that hash should be pretty secure and no one should be able to guess my master password from it.

The problem is that this hash is not really a usable password. For example, website have all sort of requirements for password like not more than 20 characters, must contain symbol, number, lower case letter and upper case letter, must not start with a number, etc...

So : hash + requirements = usable password

But I have a concern. Is it possible that by applying the requirements to the hash in order to produce a usable password, I will lose some of the security that the hash produce?

For example, let's say the hash is 60 characters long and the password cannot have more than 20 characters. Is it bad to only take the 20 first characters of the hash? Would it be better to produce the 20 characters of the password combining together the 60 characters of the hash?

So the general question is :

How should I proceed to create a usable password from that hash? Do I have to worry?

For a good hashing algorithm (and unless you've rolled your own hash, you're probably using a good enough one), all of the bits should be pseudorandom.

A 20 character password is indeed weaker than an 60 character password, but one  20 character password is equally secure as another if they're equally random. Combining a 60 character hash into 20 characters would not add more randomness than just taking the first 20 characters.

When it comes to password design, the main threats (strategic guessing of your password, brute force, trying your password against all of your online profiles) can be mitigated by just using a different, long, random password for each website. The level of randomness provided by truncating a hashing function is enough.


Are there any problems with using CAMELLIA, IDEA and SEED based cipher suites on a web server in 2016? I have recently seen CAMELLIA, SEED and IDEA cipher suites in use for HTTPS on a web server and am unsure what to suggest to the owner. The keys in use are all over 128 bits in length and standard OpenSSL is in use.

IDEA was deprecated in rfc5469 due to it not seeing widespread use but may not actually be insecure.

Possible reasons to use the above cipher suites may involve being excessively paranoid about potential NSA interference and wanting to use Japanese / European / South Korean cipher suites instead. It is not affected by any local legal requirements to use these ciphers.

Possible reasons not to use these ciphers include they are not widely used across the industry so are likely to have been subject to less research by the security community compared to AES or other alternatives. It is possible someone may be able to develop side channel attacks by adapting those used against other ciphers but this is extremely unlikely for this server. Support from them has been removed from most modern browsers and I cant think of any situation where a client that could use these cipher suites would not support AES which was also available.

Beyond alerting the owner to the deprecation of IDEA and suggesting that it is generally a good idea to use the de-facto industry standard cipher suites, as these have had the most research performed against them, is there anything else I should be aware of?

IDEA uses 64-bit blocks. This means that it begins to run into trouble, cryptographically speaking, if you encrypt more than 232 blocks worth of data with the same key (in CBC mode). That's 32 gigabytes, which is quite large, but not unattainable by today's standards. Thus, it should be avoided.

Camellia and SEED are block ciphers that exist mostly because the Japanese and Korean governments suffer from NIH syndrome. As far as we know, they are pretty decent algorithms -- just like the AES. There is no substantial reason to believe that they are stronger; if you are on the paranoid side, consider that if there is some unknown method by which the AES could be spiked, then there is no reason to believe that Camellia and SEED are not equally affected.

A practical reason to prefer AES is that there has been a lot more work on making constant-time implementations of AES. Also, some CPU offer some hardware support, which is even better for protection against side-channel attacks, and offers better performance. A typical Web server will not have any performance issue with any of these algorithms; whether side-channel attacks are applicable in practice or not is anyone's guess.

Still on the practical side of things, if clients don't support Camellia or SEED, then it is quite pointless to enable them on the server -- they won't be used anyway.


How to force ALL programs to use my Proxy? I have a local proxy on my PC. (localhost:8888)
But unfortunately there are many programs which are not able to go through this proxy.
So how can I force all my programs to go through my local proxy (or tunnel my connections to my local proxy)?

So all the programs on my PC could go through this proxy before reaching the internet!!?

Have you considered using a transparent proxy?  It can automatically intercept all traffic and feed it to the proxy.

If you're asking about Tor, check out the Tor transparent proxy, which might do exactly what you want.  You might also check out Torouter.