WhatsApp: Someone makes screenshots of a friends chat. Can I help them? A group of friends is being stalked by an unknown person (or bot?).

Everything started with person A. A was sent authentic screenshots of several of his WhatsApp chats. Screenshots were sometimes sent from an unknown number in WhatsApp, sometimes using other Social Media.

Later, A met B and they started a conversation on WhatsApp. Soon B also received screenshots of several of her chats.

B just clarified neither A or she receives actual screenshots. The messages are authentic, they also contain authentic pictures sometimes. But the look is different, as if a screenshot was made in another app. It's quite different from WhatsApp, for example, the background of every message is plain white. Also, the pictures only show the messages, nothing else. B also told me that some messages directly address her. These are not copied from WhatsApp. For example, she might receive a message like "(Some insult here), look what I've found: (Some message copied from a WhatsApp chat here)"**

A and B are located in different towns. A is using an iPhone, B had an iPhone at first, but changed to an Android phone later and changed his number at the same time (which didn't help). Both are using recent versions of WhatsApp with end-to-end encryption. B (at least) was also using some web client for WhatsApp.

It's highly improbable that someone had physical access to either phone or to local WiFis.

Is there some common explanation on how the stalker might have gained access to my friend's chats? Is there anything I could recommend to them other that switching to a different app?

Edit for compression:

Possibilities:

There are too many possible ways for intrusion in this non-detailed situation, therefore the question is not really answerable.

The possibilities range from firmware-os level infection, till disguised apps, or vulnerabilities in the app or encryption processes. Also wifi hacking is possible even if not probable.
This needs a lot of time and testing to find it out, what very likely noone will do do for free for a stranger.

Explanation:

Many hardware come nowadays with preinstalled backdoor firm-software, which are exploitable by anyone the day you start it up first time. If it was not the case, there are many other possibilities to infect it later, even imposing the malware as part of the system/app. There are other ways to work around encryption too.

Tips:

Average users definitely need help from professionals if they wish to have a secure/private digital communication or they need personalized help.
Not even an IT professional may help, since they might be are motivated by money or limited by local law.
The best way is to understand, that if you are not a security professional, your digital life is definitely not secure. Noone should live in false sense of security.

Achieving high level of security needs a lot of personal work and knowledge, if you do not trust others, and you should start being interested in open source hard-firm- and software, encryption, hidden and decentralized services. Not even those are going to protect you from organized criminals for sure.


False acceptance rate in biometric authentication system False acceptance refers to an unauthorized user given access to a system which he is not allowed to access. Therefore a false acceptance rate of 1% means the system will incorrectly allow access to someone who is not allowed 1% of the time. I have tried to google around but cannot come up with how the false acceptance rate is determined. Does it refer to a random error as explained in scenario 1 or to a systematic error as explained in scenario 2?

Scenario 1. Person A is authorised. Person B is not authorised. Person B has a very different fingerprint from person A. However, person B tries to authenticate 100 times. Out of those 100 times, 1 time is successful.

Scenario 2. Person A is authorised. Person C is not authorised. However, person C belongs to 1% of the population that have very similar fingerprint as person A. Therefore, person C will always trigger a false acceptance in the system.

Assumptions: Only 1 fingerprint, person A, is registered with the system. Therefore, it is impossible for person B,C to match with other prints.

Edit: In short, does the false acceptance rate refer to accuracy or precision?

False acceptance results from the need to deliver a user friendly system and is tied to  false rejection as well as the technical limitations of systems.

In short it is an accuracy issue.

A digital representation of a finger print (or any other biometric for that matter) is effectively a digital subset of the information about a finger print. The amount of information stored about each biometric record will be system dependent, but will be finite and therefore there is the potential for duplication. As with most digital representations some information will be lost and for an authnentication system there is a trade of in terms of storage space and processing speed which will limit the amount of information that can be used for the digital representation of each finger print.

As with any user system useability is key, with a biometric system users would soon stop using a systems if they had to submit their fingerprint repeatedly before it is accepted (false rejection), therefore the system has to have a tolerance threshold which allows for inaccuracies during the submission process by valid users i.e. a low false rejection rate, but decreasing false rejections will increase the possibility of a false acceptance because it is more likely that a different fingerprint will 'become' acceptable.

For your 1% FAR example, there is an expectation that out of 100 fingerprints it should be expected that 1 will result in a false match. Whether this means the person with the false match will always be able to create a false match is going to be dependent on how the system works (both hardware and software).


Have any viruses leveraging the GPU been discovered in the wild? What is the mitigation? This news article from 2010 discusses how a GPU can be used by a virus to avoid detection by common anti-malware/anti-virus software. The idea is to obfuscate the virus payload and leverage the GPU's computing power to unpack it, thus defeating a signature-based antivirus that is limited by CPU computing power.

Has there been any documented instances of viruses leveraging the GPU occurring in the wild?
How have antivirus and antimalware vendors responded to this threat?
Does this mean WebGL and WebCL is another vector for exploit?

The first GPU-assisted malware is considered to be the Badminer trojan reported by Semantec in 2011. Although its GPU leverage level is pretty low and the risk is low too, this is still the first precedence of using the GPU maliciously in the wild.

Another more intrusive example of the same idea is RiskTool.Win32.BitCoinMiner.

Then antivirus designers started to think really hard. No AV vendor will invent effective GPU-related protection until high-risk GPU-assisted malware starts to appear in large volume and more traditional AV approaches fail. It won't happen very soon. Meanwhile, it's just not feasible to protect against a still imaginary danger.

Everything is a potential attack vector as soon as it becomes more and more profitable. There's no such thing in the world that is not attackable or misusable in some form. Regarding particular WebCL, from Wikipedia: "Currently, no browsers natively support WebCL, seeing as it is new. However, non-native add-ons are used to implement WebCL."


Should I worry about remote timing attacks on string comparison? Say we have a Java web application which uses a shared secret to verify the identity of the client. The secret is stored on the server, and the client transmits the secret over SSL where it is checked:

String SECRET_ON_SERVER = "SomeLongRandomValue";

if (secretFromClient.equals(SECRET_ON_SERVER)) {
    // request verified - client knows the secret
} else {
    // request not verified - generate failed response
}

String.equals(String) returns as soon as a single character doesn't match. This means an attacker, if they can accurately track the time it takes to respond, should theoretically know how many characters of their attempt - secretFromClient - match the server secret, leading to a plausible brute force attack.

But the difference in timings seem to  be tiny. Quick investigation suggests the differences are easily in the sub millisecond range.

Can I safely ignore these kinds of timing attacks due to its insignificance compared to network noise?
Are there examples of successful < 1ms timing attacks over the internet?

There are published successes with remote timing attacks.
From the document -- "... we can reliably distinguish remote timing differences as low as 20µs."  So yes, you should be worried about the underlying implementation of .equals() (spoiler: Not secure). Implement .equals() using a sum of XOR of characters to compare in a timing-independent way.

Here's a python implementation as an example of a timing independent compare of bytes.

def equals(bytes1, bytes2):
    if len(bytes1) != len(bytes2):
        return False
    else:
        differences = 0
        for a, b in zip(bytes1, bytes2):
            differences |= a ^ b
        return differences == 0


Does preventing password recycling increase or damage overall security? The general opinion on password policies seems to be that complexity rules are counterproductive to security due to the human nature [1].

Does this also apply to password policies prohibiting the re-use of passwords that a user had on the same system? What are the actual benefits (or disadvantages) of preventing the re-use of e.g. the 3 most recently used passwords? Would it be "secure enough" to just prevent that the current and the new password are identical?

Following the gist of the answer linked above, I feel that if e.g. a specific system's user has to change his/her password every month with a password policy in place that prohibits the re-use of the 3 most recently used passwords, the user would just use the password used before the 3rd latest. Hence, cycling through a pool of 4 passwords instead of 3, adhering to the password policy but defeating the policy's purpose.

Limitation:

The password must be remembered and typed by a human being. Password
managers with CSPRNG-passwords are not feasible in this scenario.
The policy to regularly change the password cannot be challenged

[1] https://security.stackexchange.com/a/32223/176023

Forced password resets make passwords worse - unless users are educated otherwise (which can be non-trivial, especially in the enterprise Windows space).

Password crackers know very well most of the common schemes that users use when faced with periodic forced reset (incrementing a number, "Spring2018!" to match the 90-day cycle, etc.). Password crackers have many tools to quickly exploit these patterns. "[Current season][current year]!" is literally one of the first passwords that pentesters and crackers will try. Because of this, forced resets are an understandable but ultimately misguided cure.

The true solution is a combination of user education (teaching users to use random passphrases), and improved technology (improved UX to provide immediate feedback about exactly why a proposed password is probably bad, and - crucially - suggested alternative strategies).

On the web-application side, the improved UX is possible today, but there are no good reference implementations that I'm aware of. (We should probably make one!) But your question is almost certainly driven by a corporate use case, since most websites don't force password rotation on a scheduled basis.

For Windows interactive login (the most common corporate use case), there are OS-level (passfilt.dll) constraints on how UX can be used to provide password-specific feedback to the user. So the Windows ecosystem is currently making it hard to help corporate users pick strong passwords (which is unfortunate, because NTLM passwords are one of the faster/easier hash formats to crack!)


Is it possible to protect a DER private key with a password? I want to write an API, based on OpenSSL, that can convert an RSA private key stored as DER to the PEM format. I'm just wondering if a DER key can be password-protected. I've searched the OpenSSL documentation and found out that it can only protect a key with the PEM format, but is it a restriction of OpenSSL or is it basicallly nonsense to password-protect a DER key ?

but is it a restriction of OpenSSL or is it basicallly nonsense to
  password-protect a DER key ?

It makes a sense to protect a key with a passphrase  but this requirement does not arise when using OpenSSL format with DER encoding, as encryption is not then supported.


Chrome users and malicious extensions I have 2 users in Chrome. One is used for personal purposes has gmail box, google disk, etc. The second one is "business" user who has another configuration, it's own gmail, google disk, etc.

Let's imagine that for business user I install some extension with read permission  all data from all sites. One day this extension is bought by some bad person and it starts for send all my data I entered to all pages.

As far as I understand, correct me if I'm wrong, this extension can steal and send my passwords that I enter at any page for this business user. But if this one is installed can it still also a data from my personal user?

If there is a malicious extension for one user in Chrome, can it steal data for other users in the same chrome even if they did not install it?

"Steal" in the scope of what was allowed when you installed it? yes, this is due to Chrome's extensions auto-update feature and there are documented cases of this happening. You can however disable the automatic updater as described in this Stackoverflow answer, the main point is that the code from the extensions isn't compiled and you can edit it rather easily:

Step 1: Find the extension id

You can get this from the web store url, for example: https://chrome.google.com/webstore/detail/cfhdojbkjhnklbpkdaibdccddilifddb tells the id is cfhdojbkjhnklbpkdaibdccddilifddb

Step 2: Find the manifest file

On Windows: C:\Users\<User_Name>\AppData\Local\Google\Chrome\User Data\Default\Extensions

On Linux: ~/.config/google-chrome/Default/Extensions/

Step 3: Edit the manifest file

Browse to the folder where your extensions are, find the folder named according to the id from step 1, browse to the folder for the latest version (usually only one is there) and open the file manifest.json, edit the line for update_url so it looks like this:

"update_url": "https://localhost",

and it should lock that extension to that specific version you are running


PCI Compliance and fines Our organisation has validated compliance with PCI DSS.
What are the consequences to us if we had been breached by a security incident related to credit card information, considering we have validated PCI DSS compliance?
Would any fine apply to us?

Card companies have contracts in place with processors to force them to both be PCI compliant and to force them to make their merchants compliant. I guarantee you any bank or processor you contract with as a merchant will stipulate PCI compliance. To the degree of verification is on there part.

If a breach occurs, the card companies can go after the banks, and intern the banks could go after you if they feel you've broken your agreement. Card companies also have the right to sue you for lack of security or improper management, or some other legal speak.

This as also mentioned this doesn't cover the cost of investigations, etc.

I believe the last average was $225/ record. The Verizon Data Breach Investigation Report usually has some good figures.


C shellcode explanation I've found this shellcode at https://www.exploit-db.com/exploits/39624/:

#include <stdio.h>
char sh[]="\xeb\x0b\x5f\x48\x31\xd2\x52\x5e\x6a\x3b\x58\x0f\x05\xe8\xf0\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68";
void main(int argc, char **argv)
{
    int (*func)();
    func = (int (*)()) sh;
    (int)(*func)();
}

Instructions:

  How To Run

$ gcc -o sh_shell sh_shell.c
$ execstack -s sh_shell
$ ./sh_shell

Can someone explain how it actually works?

In what ways can it do harm to something?

What is sh used for? ("뀋_H1ҀR^j;X耰bin/sh" (unicode) or "�_H1�R^j;X�����/bin/sh" (ASCII) don't make much sense, except for the last 6 characters, what are those characters in front?)

using ndisasm, the data in the sh array can be disassembled into the following valid 64bit x86-machinecode:

00000000  EB0B              jmp short 0xd
00000002  5F                pop rdi
00000003  4831D2            xor rdx,rdx
00000006  52                push rdx
00000007  5E                pop rsi
00000008  6A3B              push byte +0x3b
0000000A  58                pop rax
0000000B  0F05              syscall
0000000D  E8F0FFFFFF        call qword 0x2
00000012                    '/bin/sh'

It looks line simple position-independent shellcode to do a kernel syscall to execute /bin/sh.

The first instruction jumps ahead to the instruction just before the /bin/sh string, that in turn does a call back to the second instruction again. The return address is then popped from the stack into register rdi.
This is a trick to get the memeory address of the /bin/sh string, since the shellcode does not know where in memory it is when it gets executed.

The register rdx is then set to 0 and pushed to the stack and poped back into register rsi. The byte 0x3b is then pused to the stack and popped back into register rax.

We are now set up as follows:

rdi = pointer to the string /bin/sh
rdx = 0
rsi = 0
rax = 0x3b

At this point, we hand over control to the kernel with syscall, where the argument 0x3b in rax tells it to execve() the file path that is at pointer rdi

If we translate this back into C, it is basicly doing:

execve('/bin/sh', NULL, NULL);


gpg: Every private key export (of the same key-pair) is different gpg version: 2.2.16 (as part of Gpg4win 3.1.9).

Is this supposed to happen: Every export of my private key partially differs from every other export as follows: 2 middle chunks of the main block, and the last 4 characters before the footer. So it looks like this:

  -----BEGIN PGP PRIVATE KEY BLOCK-----
  < blank line >
  < identical chunk of characters >
  < non-identical chunk 1 >
  < identical chunk >
  < non-identical chunk 2 >
  < identical chunk >
  < non-identical chunk 3 (last 4 chars) >
  -----END PGP PRIVATE KEY BLOCK-----

A --list-packets on any two exports shows a difference in two lines:

  iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: < variable hex string >
  protect IV:  < variable hex string >

If the above is normal, then why is that - why is each export different? And what are you backing up when you export your private key for safe keeping? If it's abnormal, then what causes it, and what steps can I take to address it?

I couldn't find anything in RFC 4880 about the "protect IV" line.

Note: My question has some similarities to this one, and this one.

The exported private keys are encrypted using a password (by default, at least). This means that the private parameters have been encrypted with a key derived from that password plus a randomly generated 8 byte salt. The standard modes of operation for the chosen cipher (like CFB or CBC) also have a random IV (of the block size, so 8 or 16 bytes, depending on whether CAST5/3DES etc. have been used or AES).

Both the salt and the IV will modify the bulk of the private key to be quite different. So it's by design, to hinder some password bruteforcing attacks (always the same salt would mean we could precompute tables for common passwords and dictionaries etc.)


Certificate Chain checking I have a very specific question.

A client verifies a server by taking the certificate and checking specific values and that the digital signature of the intermediate CA is correct (according to the public key stored on the clients computer).

Option A:
Does the client not make sure that the intermediate CA signature (signed by the root CA) is valid, and that the root digital signature (self signed by the root CA) correlates with the public key stored on the computer?

OR

Option B:
Does the client see that the digital signature of the server is correct and therefore uses the information stored in the certificate store to make up the rest of the chain (i.e. if Certificate B was used to sign the server certificate then my certificate store says that certificate A was used to sign certificate B and therefore I will show that as the rest of the chain)

I understand that the entire chain is installed on the server, but does the client use all certificates?

This was sparked by my general interest and I experienced a case where the intermediate certificate was not installed properly and Google Chrome and Internet Explorer accepted it but Firefox 4.0 did not.

I hope I made my question as clear as possible.

I have taken out some of the other steps used in SSL validation on purpose as not to confuse the question.

Note: There was an invisible image associated with this question which I discovered when editing:

The server will provide its own certificate, and optionally (but recommended) all intermediate CA certs in the chain (aka the CA bundle). It need not provide the root CA cert of the chain, and the client should disregard that cert if provided in the bundle anyway, see this question for more details on that. Since the complete bundle is quite possibly unneeded overhead, in the future the client will be able state it has a cached copy of it to reduce connection setup.

The point of validation is that the client should be able to verify the entire chain up to a trusted root, so it must have a copy of the root already, and must have or obtain all intermediates.

If the client is missing intermediate CA certs it can trust those provided by the server as long as they are verifiable, it can then fill in any missing pieces using its local copies of CA certs. This is the method used for intermediate CA cert updates, so that clients can update easily (there is no widely deployed X.509 certificate fetching or publishing system analogous to PGP key servers). There can be zero, one, or many intermediate certificates in a chain.

Each certificate has only the identifying details of its immediate issuer/parent (i.e. not the entire chain) – this is recorded in the Issuer DN field, and more usefully in the AKID field (AKID/SKID PDF). The readable Issuer name may not uniquely identify a specific cert (it does not record the specific serial number). The SKID (Subject Key Identifier) is effectively a thumbprint of a certificate, and the AKID (Authority Key Identifier) is the thumbprint of its issuer, this works like a singly-linked list from the end cert (ideally) up to a trusted root (though older certificates often lack those fields, so the DNs are used instead).

Starting with the server provided chain (if present) the client should work down the list, it may add intermediate certificates it is missing to its store, if they are valid.
Then, the client should trace back up from the servers certificate, usually using the AKID field to locate the specific issuer (parent) certificate, verify, and work up until it gets to a trusted self-signed root.

The terms associated with this process are Certification Path Building and Certification Path Validation. There is no single "right way" to do it. A robust client will check from end to end, browsers typically offers a bypass (with sternly worded warnings), and on some systems you can limit the depth from the end certificate to check as an optimisation.

(Validity checking includes signature/hash, date range, CRL, OCSP, pinning  etc. and possibly DANE.)

This overlaps with both of your options, plus self-updating of intermediate CA certs.


Google App Script as public gateway for database (spreadsheet) I've created a google app script that takes a POST request and writes to a google spreadsheet. In parallel, I've also made an Android app that sends HTTP requests to this google app script.

I did it like this because my company didn't want to buy a server to store data. Now I'm worried about security issues. For example, if a user sniffs the network or reverse engineers my app, he can

Get the URL of the script
And the parameters required in the POST request

So am I screwed? Or are there some tricks that I can do to make people waste their time in the hacking process?

NOTE - I do not have a server available/at my disposal merely the script I've written.

Any user can extract the parameters and send the scripts yes. Unless you have a method to authenticate users and sanitize input server side anyone can post anything to your script.

Depending on how you have published your script you may be able to use googles authentication system here. You could force the user to be logged in with a valid google account to be able to post, recording the changes against their username. If required you could also lock execution to only pre-approved google accounts.

Alternatively a small VPS (EC2 or similar) instance hosting a web front end and a database would be ~$10 USD per month. I'd suggest you make your employer aware this would make the system far more flexible, secure and scalable. I'd imagine compared to your annual salary this is a negligible cost.


Where can I find some "real time" discussion forums for security issues? The place where I work was hit by the new Qakbot variant (3rd generation) a couple of days ago and it has been brutal. Unfortunately a lot of the documentation out there is from the 1st iteration of this virus.

We've looked at a lot of the big antivirus sites (Symantec, McAffee, etc.) but unfortunately they are a little slow in getting their documentation up.

I'm looking for some online discussion forums or sites (simliar to here) where people would be discussing this issue in more "real time" so that we can look for some alternative plans of attack.

Can anybody recommend some sites for this? Interestingly enough, I have been doing some searches via Twitter as well, with limited results.

You can try in our chatroom, at http://chat.stackexchange.com/rooms/151/it-security.
Depending on hour of day / day of week, you may not find many people there... as it is, the regulars are not a huge crowd... but hopefully that will grow, along with the site.


Verifying that a request is internal I've got a web app that will only output safe code. It needs to pass this to a Python backend. The logical way to pass things between JavaScript and Python is to have a Flask server running. Then, the JavaScript would send a request like http://example.com/test/?code=this_is_safe_code. The code would be evaluated.

I don't want outside users to be able to send code through, though. I want all requests made to be internal. Since I know the internally transmitted code will be a safe mathematical expression, I feel comfortable using eval. However, if someone from the outside sent something like http://example.com/test/?code=__import__%28%22os%22%29.system%28%22echo%20DANGER%22%29, then Python would run __import__("os").system("echo DANGER"). Which is obviously not safe.

The JavaScript calls are entirely client-side, I'm not using any backend JS with things like node.js.

What are the security methods to allow internal requests from JavaScript but not external requests? Would this need to be some kind of private certificate?

You can't secure this. There's no way to ensure that your web app is on the other side of a connection. Even if you come up with (convoluted) methods of trying to checksum and sign your requests in the JavaScript, a user could simply use your JavaScript to sign their own requests.

You can probably secure this by changing the format of what you pass to the server from being free-form Python into something much better specified. For example, perhaps you pass an array of N numbers and N-1 operators. Your server would then validate (using a whitelist) that the numbers are numbers and the operators are in the allowed set of mathematical operators. If this passed, then you could reconstruct the Python code and execute it.

Another solution is to run the JavaScript on the server and have that data directly passed into the Python. In this case, you need to validate the input to the JavaScript in a manner similar to that described above.

Reference: OWASP Input Validation Cheat Sheet


2FA using Kerberos and SSO within CDE I was wondering if anyone is using Kerberos for their 2FA solution into their CDE for PCI DSS compliance. Also, what does PCI DSS say about SSO once 2FA has occurred through a Radius Server?

(2FA = Two Factor Authentication, for those just tuning in)

  I was wondering if anyone is using Kerberos for their 2FA solution into their CDE for PCI DSS compliance.

Kerberos is an authentication mechanism most commonly used to grant access based on password credentials.  As such, it doesn't provide 2FA; it provides 1FA.  I have seen Kerberos used as a 1FA in CDE environments.

There are 2FA systems which incorporate Kerberos, such as RedHat's Identity Management server, but in those cases Kerberos is used for "something you know" and glued to "something you have" (Software or Hardware OTP) using LDAP and possibly RADIUS.  And MIT appears to have integrated Duo OTP more directly with Kerberos, at some cost of client support.

So - Kerberos may be part of a valid 2FA solution for your CDE, but in general it only provides one factor, so additional lifting is required.

  Also what does PCI DSS say about SSO once 2FA has occured through Radius Server.

The DSS does not address Single Sign-On per se, however, it does state:

  Multi-factor authentication can be performed either upon
  authentication to the particular network or to the system component.

(DSS 3.2 section 8.3)

I'm not a QSA, but I think one could make a legitimate case that that language could be used to argue that 2FA is not required upon each system component sign-on, as long as it's used for the initial login to the CDE network.  Which is to say that the DSS does not appear to prohibit SSO when it requires 2FA.


HTML Entities to hide Email Addresses I'm on WordPress trying to keep spambots from grabbing email addresses that may be in The Content. WordPress has a nifty little function simply called antispambot() which will convert the email address into HTML Entities.

no-reply@domain.com converts to:

n&#111;-r&#101;&#112;&#108;&#121;&#64;d&#111;m&#97;&#105;n&#46;&#99;&#111;&#109;

This function has been around for a LONG time and I'm sure the method has been around for longer so my question is: Is this still a valid way to beat spambots? Will this method still fool spambots and keep said email safe?

No, that's not going to fool spambots.  I've seen a couple of spambots that were parsing the entire DOM using tools like html5lib or comparables.  Of course, many spammers just "guess" at email addresses: the cost of sending emails when you have a botnet is basically 0, so making combinations of username & domains to guess works out well.

Slightly better techniques I've seen have involved using javascript to render the email address into the DOM at runtime.  A spambot would need to be running in a browser or use something like WebDriver to get at those.

But, in all reality, hiding your email address is a losing battle.  A contact's address book might be compromised, or you might miss one place where its posted, and then you're back where you started.  Good filtering is probably a better investment of time & energy.


Would first encrypting a password make slow hashing algorithms unnecessary? If you first encrypt a password using a secure key, and then hash the result, and both algorithms are fast, say sha_256(salt+aes_256(password, secure_key)), would that make the hash expensive to brute-force without making it expensive to generate?

[Addendum for clarification]

I have a security concern with slow hashes in that they weaken availability.  If I use a slow hash that requires my server to be CPU-bound for, say, 500ms per user, and I get a flood of new users all at once, then I will have given poor or no service to many potential customers as their first experience with a site.  It also seems to be an easy vector for a DOS attack.  A slow hash intuitively feels like a brute-force defense to me, and I'm questioning whether a lot of CPU effort from the defender is really necessary to thwart an attacker.

Yes this would make brute-forcing  more expensive, but as was pointed out by “kelalaka” it creates an additional key management problem.

The more classic way to make  brute-force more expensive is by iteration. A hash of a hash of a hash … of a hash a few hundred thousand times can be made arbitrarily slow without creating additional key management problems.

Fundamentally the expense to generate is what makes it expensive to brute-force, all other things being equal.

An unequal example would be a too small hash space. If I assume an arbitrarily complex hash-encryption-magic method that produces a 32-bit hash result, I only have to find a password among 4 billion, and it’s probably not even the one you used but it will still work because of the small collision space.


For how long ISPs keep record of Internet usage? For how long ISPs keep record of Internet usage?
Do they keep record of every page we visit?
In what form do they keep such records (remote IP, URL, page title, headers, etc.)?
Is it possible for an employee working at ISP to monitor an individual customer's Internet usage?

As one commenter already alluded to this is a pretty broad question. The broad reply is this: assume anything put on the internet is there forever. Different cities,states/provinces, countries, organizations, etc have various retention policies. It even varies from industry to industry. What kind of data stored can also change dramatically between all of these different groups.

Further, even if a site takes down data within a relatively short period there's no guarantee nothing isn't scraping it and storing it for later (4chan comes to mind as a prime example).

This goes a little deeper than your initial question but it's a part of the larger picture: a lot of things can leave a lot of historical evidence of your whereabouts.

Lastly, in regard to your question about if an ISP employee can monitor your activity - that's a pretty easy "yep!" unless you're taking certain steps to obfuscate your traffic. However, your destination IP address will likely be able to be easily mapped back to your account.


Effectiveness of Belarc Advisor I have seen some people recommend Belarc Advisor for Windows hardening, especially for servers. It's supposed to check for stuff such as installed hotfixes and CIS benchmarks (<-- which are great, btw).

So question is: Anybody tried it? Anybody know something better?
Hypothetical situation I'm in is that I'm an engineer in development and I need to make it as easy as possible for the IT guys to manage our servers since they don't have the best grip on security.

Very subjective question - as you will see from the FAQ, subjective questions will usually be closed.

In saying that, I would say that while I think Belarc may be useful for a home PC, it really isn't the sort of thing I would ever use in an enterprise or SME environment, nor have I ever seen it used outside the home.

I would recommend looking for a product which can tie in with your policies, central exception logging and centrally managed - there are a lot on the market, depending on your price range.


Android / CyanogenMod encryption vs GNU/Linux Hi I am trying to understand how encrypting an Android based phone works compared to a GNU/Linux host which relies on LUKS dm-crypt.

Here is what I understand: Encrypted LVM on GNU/Linux is an option only available at initial install, so there is no opportunity to do that at a system level later on, if it isn't done in the beginning. Removing FDE would need a full reformat of the drive after data backup. The only way to be safe while using FDE is to completely turnoff the device and not leave it in a suspend to RAM mode. Password screen savers are useless in this event because a memory dump can retrieve the key. Hibernation is OK as SWAP is encrypted by default.
Please feel free to correct me on any of this if I am wrong.

What I am puzzled about: How can Android perform post install encryption of the system when it relies on LUKS too? Does it only encrypt the internal storage and not the SD card? What is the point of encrypting if the cellphone is left in an ON state for most of its life, shouldn't a thief be able to bypass the swipe screen encryption by dumping the phone RAM and extracting the master key?

TIA

Android implements the device encryption in a module of Vold (Volume Daemon) called cryptfs that makes the calls to the kernel which actually encrypt the device. When a user encrypts the device, Vold reboots the device and begins encrypting the data partition. During the encryption process Vold disables everything that is not a core service on the device. Android requires that the user create a passcode if they have not already set one at the beginning of the encryption process, which is one of the criticisms of the implementation since the decryption process is tied to the users screen unlock passcode which isn't super complex. Once the device is encrypted, according to the documentation at the AOSP page, the encrypted master key is stored in the footer of the data partition. As far as I know Android's implementation only encrypts the data partition, which would be user and app data. Once the device is encrypted the user will have to enter their passcode whenever the phone is locked. Before they can access their data, the kernel mounts a tmpfs/data that reads from the actually encrypted block devices. Your screen unlock passcode hashed and used to decrypt the master key. This is the description on the Notes on the encryption implementation.

  The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.

Once the device is encrypted, the only way to undo it is to wipe data. I don't think that the default implementation you get in the AOSP source encrypts the SD card since not all android devices have a removable card, like the Galaxy Nexus, but I guess device manufacturers could add support in for that. The AOSP documentation on the FDE implementation is available here, Android Notes on Encryption Implementation. It's pretty thorough compared to some of the other AOSP docs. You might be interested to check out this blog post, Cold-boot encryption key recovery on an Android phone that has some information on attempting key recovery with CyanogenMod7.

His conclusions were:

  The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.

But he was running CyanogenMod7 so I don't know if that is generally applicable to stock ROMs on devices or ROMs built straight from AOSP, but maybe there is some more information and research out there about the potential for key recovery.

Hope this helps some.


Security concerns on hosting server Few years back I hosted my website on godaddy but I was not that tech savy so they (customer care people) assisted me on hosting the website on their shared hosting server. Since then I am on a constant endeavor to educate myself in tech area and now I feel to it is pretty easy to host a website and make it up and running live.

But when I needed the assistance back then to host my website on godaddy, they were able to have access my website files and data, moving them on their end in a particular folder to make the website go live. They were also telling me to remove the custom CSS codes from a particular line as it was giving me the some error.

So I want to know, is it possible to prevent hosting providers getting access to my website files and data in it and how ?

is it possible to prevent hosting providers getting access to my website files and data

Short answer: no.

You are uploading your files to someone else's computer, so they have access to every single file there. You have a database? They have access to the database too, and its contents, and the server logs, and are in position to know every single byte of data sent and received from every single client you have.

How you prevent that? You have your own computer connected to the internet.

Encryption can help? Not really. You could encrypt data, but your clients would need the cleartext, so you would need to provide the decryption keys, and your provider would get that too.


SSL, SSH, OPENVPN, etc which one? To start with I am not a security professional, in fact I am on the other end of the spectrum. In the opinion of people on this site what would you choose for secure internet browsing. I will be accessing interactive websites and making transactions.

It is absolutely essential that my real IP remains secret and immune to attacks. I will be using sites that have adopted an aggressive attitude to blocking certain geographic locations and have engineers and software that attempt to discover real locations (beyond simple IP check).

I have seen this question posed on this site and various others, most responses detailed the merits of various combinations VPS with SSH being one example though others suggestion socks 5 with SSH sock with VPN.

After a while its starts sounding like Chinese to me. Also the number of options is overwhelming. Could someone give me a heads up on what they would personally choose for the above problem?

First off, you need to realize that you're asking for anonymity and confidentiality. Those don't always go together, and if you don't keep both goals in mind, you will wind up with confidentiality (which is what SSH, SSL, and OpenVPN are more designed for) but miss out on anonymity.

Second, you really need to read some documentation on whatever solution is recommended to you. Only you know your exact requirements, and this stuff isn't actually terribly difficult to figure out if you take the time to understand it. I'd hate to give you advice based on a paragraph of explanation when it sounds like there may be real consequences for you if things go badly.

With that said:

Look at Tor - https://www.torproject.org/ - to start with. There is a lot of documentation on the site about what it can and cannot do. There's also a lot of the principles of anonymity on the site that will be good background reading for you.

You could also look at anonymizing web proxies, like Anonymizer and Proxyfy (disclaimer: I haven't used either in years). Again, read about them.

Finally, realize that anonymity is difficult to ensure. If you use an anonymizing service whose servers are in a jurisdiction that cares about you (e.g., if you're American and you use an American proxy), the government can just go to the proxy with a subpena and a gag order and you'll never find out until it's too late. The jurisdiction question is more complex than I'm making it sound, too; you have to consider which countries would be willing to work with each other. That's not a straightforward topic.

There are some good wikipedia articles on the subject of anonymity, e.g. https://secure.wikimedia.org/wikipedia/en/wiki/Anonymizer, with linked references.

Finally, if you really do care about both anonymity and strong confidentiality, you probably need to combine anonymization techniques with a VPN of some sort, or with SSL if you're very careful. It's wise to expect anonymizing proxies, Tor, and the rest to be monitoring and even tampering with anything you do, so for anything important, I'd definitely use crypto. SSL is the most natural fit, but be very sure to validate certificates properly, since there are SSL-snooping proxies out there that play games with certificates.

If you're interested in rolling your own solution and you have enough cash, you could get virtual private servers in a few different, orthogonal jurisdictions - very carefully - and knit together an openvpn or SSH tunnel from end to end. Just remember that traffic from the last hop ("exit node") to the final destination is always going to be unencrypted and non-anonymous, in the sense that it can be traced directly back to the exit node (but no further if you're careful).

I'll repeat one more time - this isn't something you should just get advice on from a stackexchange post. If this is meaningful to you (and it sounds like you're concerned about meaningful consequences), you should spend the time it takes to get comfortable with the issues involved.


Is CVE-2017-5428 (mfsa2017-08) a zero-day? CVE-2017-5428 aka MFSA-2017-08 is an integer overflow vulnerability in Mozilla Firefox.  It was reported through the Pwn2Own contest, and corrected in Firefox 52.0.1.

This article describes it as a zero-day vulnerability, but I thought Pwn2Own used a coordinated disclosure policy?  The Mozilla bug isn't open yet, and I can't find exploit information anywhere else, but perhaps I just don't know where to look.

Do we need to panic (so to speak) or can we treat 52.0.1 on the same urgent-but-don't-panic basis as every other web browser security update?

Zero-day is not a useful categorisation for assessing risk.
In terms of risk what matters is:

Is this bug being actively exploited in the wild?
How wide spread is the knowledge of this bug?
How hard would it be to reproduce an exploit of this bug, given the publicly available knowledge of this bug.

The new version of firefox is available so knowledge of this bug has been published (at least the source code changes required to fix it). I don't have knowledge of how hard it would be to reproduce the exploit.

The urgency with which you should patch is dependent on your expected advisories, are you of interest to governments or organised criminals? If so update now. If not follow your normal process for security updates.

When the bug was used in Pwn2Own the bug was a "Zero-day", i.e. the vendor was not aware of it. Once it was disclosed to Firefox (one of the conditions of Pwn2Own) it stopped being a "Zero-day", i.e. the vendor was aware.


Is removing the Ethernet cable from the router (when I'm not using it) a good security measure? I have here at home a router, like many people out there.
The router is connected with an Ethernet cable that comes from the modem.

But, to prevent hackers or anything else to try bothering me, if I'm not using the router, is removing the Ethernet cable a good security measure? Or it doesn't do that much in security, so I should leave it always connected?

If there is not an internet connection to your device then a hacker is not going to be able to communicate with that device. (Edit: As some have pointed out...this is assuming an attacker is attempting over the internet from a remote location)

With that said, eventually you will have to connect to the internet again if you want to use the internet and if you were to eventually obtain malware on your computer such as a keylogger. That keylogger is going to rely on the internet to send its data back to the hacker. If the keylogger is written properly, when you disconnect, it will just wait for you to connect to the internet again to send its data back to the attacker.

In my opinion, I think disconnecting from your internet will prove to be more of a hassle than a protection. Instead, focus on the security of your device and your actions on the internet. Being a smart internet user can provide a great deal of security to your device.

Elaboration (EDIT):

I do agree that this method with decrease the time of opportunity for an attacker but the reason I chose to put emphasis on endpoint security and user education is because if you imagine an enterprise environment, they have devices and services that rely on an internet connection 24/7. So an enterprise can't rely on disconnecting from the internet as a viable security measure. Instead they focus on securing the devices on the network and the network itself. So I believe this will achieve 2 things: 1) greater security. 2) better user experience(always have internet access on demand) and I believe you can apply these strategies to your personal network as well.


how IPS and IPSec work together in a host I want to know how they work together . for example , we implement IPSec tunnel between 2 routers and we establish Snort IPS on Router 1. when Router 1 get the packets , they're encrypted . Now which one examine them first ? if IPS investigate the packets , it can not detect malicious content . so do we lost IPS because of IPSec tunnel ?
my questions are

Which one examine input packets first ?
Does IPS examine packet after decryption ? or before decryption ?

I think my problem is that i have no idea about packet flow when they are received on interface .

Linux Based Router

In Linux the key exchange (generally ISAKMP) is performed in user space, while the security policies, keys, and encryption/decryption are performed at the kernel level.  When a packet arrives the kernel first processes this packet by checking to see if the SPI and IP match a security policy.  If it does the packet is processed using the policy's stored keys, and the promoted up the network stack for processing.  This is still performed at the kernel level.

Now where Snort sits in the network stack implementation is important.  As it's a user space program it receives packets from the kernel.  This is generally performed by the kernel's network filter.  Then the packets from the kernel's netfilter get passed on to user space programs like snort [1] (search Snort).

What this means for you

Kernel sees encrypted packets
Kernel determines if it has a security policy matching these packets
If yes, kernel decrypts the packets and promotes them up the network stack
Netfilter processes them, and pushes the decrypted packets up to user space
Snort sees decrypted packets and processes them.

This isn't the full process, and I'm might have glossed over a bit of the Linux kernel network stack.  But you really don't want those details anyway.

Or maybe you do...
Dirty Details on Linux Kernel Network Stack
Dirt Details on Netfilter
Filtering IPSec packets after decryption using iptables

An Interesting Side-note:
If you're sniffing packets on Router 1 with Snort or even Wireshark.  Ping through the VPN.  From Router 1 you should see both the encrypted ESP packet coming in, and the decrypted response in Snort/Wireshark.  As verification that it will in fact see both packets.


Should I trust that the Android factory reset actually erases my data? I bought a Galaxy S20 Fe, logged my LastPass in it and all of my accounts (google, twitter, etc).
Now it has a malfunction and I'm going to have to send it back to get my money back.
When I factory reset an Android, I presume that it zeroes the memory in the writable partition of Android. This would explain why it takes 30 minutes to do a wipe. Instead of simply marking the data as deleted, it actually deletes it.
Can I trust the factory reset, or should I change the LastPass password + all passwords inside?

All android 7+ devices are enrolled with File Based Encryption (FBE) that encrypts /data partition from first boot. FBE keys are bound to TEE and user screen lock authentication. On factory reset, TEE clears stored keys and OS wipes the data. At this point, even if your screen lock password is known, it's not possible to decrypt recovered data.
It would not take longer than few seconds to wipe the data. Secure erase is not needed as clearing FBE keys is enough. Your device might be taking time in restoring factory image.

I use fingerprint unlocking, which means keys/password/secrets are stored somewhere.

Secrets that are bound to in-app biometric authentication are encrypted by the key that is generated & stored in TEE. Apps can also import cryptographic keys in TEE. Unless biometric authentication succeeds which is verified by TEE, TEE doesn't release keys of the querying app. This protection ensures that even if a malicious app compromises other apps, it won't be able to steal secrets of those apps without user authentication.
Apps that are storing secrets outside of TEE and not bound to user authentication are still protected by FBE. On app uninstall, associated keys of the app are deleted. On factory reset, TEE clears all keys.

reset - This permission allows to reset Keystore to factory default, deleting all keys that are not vital to the functioning of the Android Operating system.

Hardware-backed Keystore


How to fully view cross-signed certificate signatures Long story short: Security scan raised a flag about a cert, found that it was an expired root on a cross-signed cert. Yadda yadda, updated intermediates, fixed issue.

However, I noticed that openssl x509 -noout -text intermediate.crt only lists a single signature on the certificate, even though there are two. I've looked over the man page and I can't find an option that prints additional signatures, and google searches are even less useful.

Is there a parser out there somewhere that will list all of the signatures on a certificate? I notice that Qualys enumerates and follows the various cert paths, but I'd prefer not to have to make prod changes to view certificate metadata.

There IS only one signature on an X.509 certificate.

But there can be multiple different certificates for a given CA, and multiple different verification paths using DIFFERENT certificates, with one signature on each certificate. That's what Qualys/ssllabs shows you (when detected).

Usually the CA involved will document this; one of my favorites for clarity is LetsEncrypt. And if your recently-expired bridge was Sectigo-usertrust-under-addtrust, about which maybe a dozen Qs have already been posted, their picture is less clear but their text is good enough (IMO).

Alternatively, now that Certificate Transparency has become common (though not universal) you can usually (though not always) search on one of the logviewers. I find crt.sh most convenient, e.g. https://crt.sh/?q=usertrust%20rsa%20certification%20authority quickly shows the now-expired bridge, the better root, and the new 'alternate' bridge to AAA, as well as the irrelevant Microsoft codesigning endorsement, all with links for details and download if desired.


Burpsuite accidental defacement, should I be concerned? I was spidering a website with Burpsuite and the automated Form Submission caused me to unknowingly deface the main page with "555-555-0199@example.com".

It took me a decent amount of time to notice but when I did I immediately worked to resolve the issue by finding an archive of the page and recreating the content by hand.

I doubt anyone but me noticed this, though I'm very concerned about the legality of what happened and should anything in the future happen would I be liable since it was just simple spidering of the website that caused this to happen...

Number one rule of penetration testing: don't do it on things that don't belong to you. Yes, it is merely a spider. However, people think wget is a scary hacker tool and the US govt. actually used that in a case. I appreciate that you rectified your mistake, and I think that reflects well on you. You have a few options here, depending on your moral beliefs:

Honesty. Send the webmaster a note with what happened and how to fix it. This could go a few ways -- you either make a webmaster happy, you piss them off and get tangled up in it, or you get no response.
Run away. Act like it didn't happen. The website will chug on and no one will be the wiser. Of course, someone may notice your activities in the web log, and they most likely will not be motivated to track you down.

To be quite honest, both of these are decent solutions. And in the future, don't run Burp against targets you don't have permission to test on. It saves everyone's time :)


Black-box fuzzing a TCP Port running an unknown applicaiton I'm looking for any guidance around testing a service I've found running on a target server. I'm doing a 'black-box' pen-test and the company is one of those 'I-don't-want-to-tell-you-anything' types so they won't tell us what service is running.

NMap picked up an open port and suggested it was a SIP service, however after testing a number of different SIP attacks/clients it almost certainly is not (the box i'm testing is also supposed to be just a webserver).

I've not had much experience with fuzzing TCP ports before and from what I've found it seems you need to have some information about the protocol first before you can start fuzzing (a template of sorts). Additionally, a 'dictionary' of different things to throw at the service is required as well (which is usually relevant to the type of application your testing). What can I do if I don't have either of these things?

Since I know nothing about the application and what it's expecting it seems like I can't run anything against it. Is that correct? Am I missing something obvious here that will help?

Edit: To be clear, there is Also an Apache+Tomcat web server running on 443 and this is a linux box. That part is not an issue as i've already tested it. Its just this other 'random' port which I have no idea about.

You are correct: technically, fuzzing is usually regarded as sending invalid or random requests/data, it's implied that you know what you're testing in order to "break" the input. In some terminology (PDF) white-box fuzzing is the close to former (generated input) and black-box fuzzing (random input) is the latter.

What you're attempting is better described as just "black box testing". The general problem here is that while some protocols (SMTP, IMAP) freely offer details with banners, or some (HTTP) are overly chatty about protocol transgressions, there are many that need a magic protocol handshake (LDAP, RPC, and many more).

Try nmap again, but with the version detection turned up to 11 (actually only to 9, but no matter):

nmap -sV --version-all --all-ports -p $port $host

nmap -vvv -A --reason --script="+(safe or default) and not broadcast" -p $port $host

Note in the second example the script prefix of + -- this means run scripts even though they would not ordinarily run. Many plugins will fail to run anyway, you'll need to read the output carefully.
Hopefully this will give you some extra info (make sure to use a recent nmap, scripts often hang in old versions).

You haven't given the port or the nmap reason, so I cannot explain why it concluded it was SIP, my best guess is it either responded to a GET or OPTIONS request or it is port 5060 or 5061.

More general advice:

it should be easy to confirm or deny the existence a public web server, tune down the nmap rate with -T1 or -T0 in case an IPS is blocking you.
make sure to scan SSL with a recent tool in order to properly support contemporary TLS versions and options

Finally, there are other application scanners out there, amap isn't nearly as comprehensive an nmap, but it's worth a shot.


Bots trying to spoof encoded email links, but why? I've setup an application for my client, that sends lists of job vacancies to subscribers every Monday morning.

The emails use a custom link redirector service, to make the links email friendly, and to count clicks etc.

This redirector uses a hashed path parameter to uniquely identify the click.

Every week, after the emails are sent, I start receiving error alerts in the logs, for redirector links that can't be decoded.

At first I thought this must have been a bug in the coding, and that some end users were unable to click on the links. However I was able to verify that these links were bogus, and had not been created by our system.

What seems to be happening, is a bot of some kind must be trying to create random redirector links. What I can't understand is why?

The links have clearly been designed to try to mimic the format of the real links. At first glance they look legitimate. They could be identified initially because they included non-hexadecimal characters in the parameters, where the real parameters are always hex encoded. However now the bogus links are also hex encoded.

What would be the purpose of this link hacking? Would the attackers be hoping to figure out how the links are encoded, thinking they might be able to then create login links, or password reset links?

The other curious thing, is that that these attacks only seem to occur directly after the mail-out. If it was a regular intrusion attempt, I would expect it to just happen at various times throughout the week. Would this be intended to make it look less suspicious, and to make it appear more likely to be legitimate user activity?

In case it's helpful, the links that are sent in the emails look something like this...

/email/links/287545cb07c0/985edd0470e453.asp

Note: The .asp is completely arbitrary, it's not actually using classic ASP, I mostly just wanted to use an extension which wouldn't confuse email clients, but would also give hackers less clues about the back-end application environment.

Since your links do not contain a target URI, there are only a few possibilities for an attack here:

The attacker has (or assumes to have) found a way to route through your redirector (unlikely)
An attempt to damage your web reputation; look up your domain for URI DNSBL listings
An attempt to water down your service in the eyes of your users
The attacker assumes your anti-spam system whitelists emails with such URIs
An attempt at Bayesian poisoning (which doesn't even work) or another nonsensical task

Perhaps there's a bug in your (and/or the attacker's) code, but I'm guessing it's more of an annoyance than anything else: damaging your reputation in some way (to your users or globally) or trying to game some anti-spam system.

If your redirector had retained the target URI

I had originally assumed that your redirection service retained the target URI, something likehttps://host/redir?hash=b17d56eb7444&uri=http%3A%2F%2Fexample.com given hash = substr(sha1("s3cret_pepper:" + uri), 0, 12) and that these forgeries failed the verification but the attacker was too stupid to have checked that.

In such a case, the redirection targets in these messages would probably be malicious sites.

This would be web reputation hijacking, in which they're using your redirector's reputation in place of the likely bad reputation of their own landing site, thus bypassing URI DNSBLs in spam detection.

Another possibility is that they don't like you and they're trying to damage your web reputation.

A third possibility is that they're trying to trick your users (and/or your internal whitelisting) into thinking these links are safe.

The first two scenarios are likely to harm your web reputation. Look yourself up at a site like http://multirbl.valli.org/lookup/ to see if you've been blacklisted already (and compare your reputation to that of the sites this attacker is trying to redirect to).


Preparing for a stolen physical server What would be the best ways to protect sensitive data stored on a server/drive that gets stolen? The confidentiality of the data is what is important, not retrieving it. Obviously, physical means are one way, but lets assume the thieves devised an elaborate heist to bypass the physical security. This data would ruin the lives of thousands if it got out.

What would be the best ways to prepare for such a situation?

There's no way to be certain that someone with physical access to your server can't get at your data. But you can take certain precautions:

First of all, if the attacker gets access to your server while it's in its "running" state, so either through the console, through remote desktop, SSH, etc., then there's not a lot you can do. You're relying on your OS protections to save you while the server is operational. Not a lot more you can do there other than what people talk about every day.

But normally an attacker can circumvent your OS by powering down the system and bringing it up in "rescue mode" mounting your drives in another machine. You protect against that attack using encryption.

There are several whole-disk encryption systems out there. TrueCrypt is well known, and LUKS/FreeOFTE is another reliable one. BitLocker and other closed systems may or may not be secure; you don't really know because you don't know what's in them.

Obviously if you use a system like this, then your server boots into an unusable state. That's rather the point. So you must be logged in to bring the server online. If you can get a remote low-level console (e.g. IPMI) then you can type in the password at  boot to unlock your drive.

Alternately, you can put your sensitive data on a separate data drive or parition which you unlock after booting up.

Or, a third option is to run your hardware simply as a VM hypervisor, and run your sensitive software on an encrypted virtual machine.

All three of these suffer from the weakness that if the attacker seizes control of your server but leaves it running where it is, he can modify the environment to capture you typing in your password when you bring the server online. There's no way around this flaw other than to take the server out of your attacker's possession.

But it is arguably better than nothing.


CentOS payload injection attempts? My PHP logs have been flooding with seemingly random attempts to access scripts and software which isn't installed on my server. At first, All the attempts came from a single IP, I was using CloudFlare, so I was able to block the IP address. I thought I was successful in preventing them but a day later it continued from another address. I'm not sure what to do or how to prevent these attempts into my server.

As was pointed out by @Daisetsu this a common thing to see in web access logs these days on anything exposed to the internet (it is mostly automated).

Per the comments I'm going to recommend you install/configure a Web Application Firewall.  You can find several good ones by doing a quick online search (trying to stay product neutral).  Most of these come pre-configured with some basic rules to filter out blatant/known bad stuff but you can/should also add custom rules if you have some special/unusual components to your application that need to be monitored/protected.  If you have a web application of any kind exposed to the internet you probably should have at least a basic/out-of-the-box WAF unless you know for sure you don't need one for some reason.


Grabbing ChaCha20 key from ram There are various other posts which talk about grabbing a key from ram such as

https://electronics.stackexchange.com/questions/198274/storing-a-secure-key-in-an-embedded-devices-memory
How would you know a certificate/private key if you extracted it from RAM? Or would you?
https://crypto.stackexchange.com/questions/30281/storing-a-secure-key-in-an-embedded-devices-memory

My question is a bit different. Assume that we have the key and for a brief window we'll use it to initialize a cipher (in this case ChaCha20) and then wipe the key from memory (using best practices, memset_s etc.)[*edit2]

Once the cipher is initialized, is that equivalent to having the key in memory?

Specifically, looking at the ChaCha20 reference code: https://cr.yp.to/streamciphers/timings/estreambench/submissions/salsa20/chacha8/ref/chacha.c

void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
  const char *constants;

  x->input[4] = U8TO32_LITTLE(k + 0);
  x->input[5] = U8TO32_LITTLE(k + 4);
  x->input[6] = U8TO32_LITTLE(k + 8);
  x->input[7] = U8TO32_LITTLE(k + 12);
  if (kbits == 256) { /* recommended */
    k += 16;
    constants = sigma;
  } else { /* kbits == 128 */
    constants = tau;
  }
  x->input[8] = U8TO32_LITTLE(k + 0);
  x->input[9] = U8TO32_LITTLE(k + 4);
  x->input[10] = U8TO32_LITTLE(k + 8);
  x->input[11] = U8TO32_LITTLE(k + 12);
  x->input[0] = U8TO32_LITTLE(constants + 0);
  x->input[1] = U8TO32_LITTLE(constants + 4);
  x->input[2] = U8TO32_LITTLE(constants + 8);
  x->input[3] = U8TO32_LITTLE(constants + 12);
}

It seems that one simply needs to get the memory location pointed at by x->input, read in like 48 bytes of data from that point, and you've got it.

Is this correct?
How can this be prevented in software? (best practices)

EDIT: I see that at least input[12] and input[13] are adjusted as bytes are crunched... and that the cipher can be "seeked" by adjusting input[8] and input[9] (or at least in salsa20, I guess chacha20 is similar)... so therefore it would probably be enough to simply seek to a random "location", and encrypt some random filler bytes, upon initialization

Is this correct, would it improve defense against grabbing the key (or initialization state)?

EDIT 2:

I believe the key can be wiped from memory once the cipher is initialized since the reference implementation does not use it for decryption... or am I missing something?

Example:

ECRYPT_init();
ECRYPT_keysetup(&ctx, MyKey, ECRYPT_MAXKEYSIZE, ECRYPT_MAXIVSIZE);
ECRYPT_ivsetup(&ctx, MyIv);

//notice neither MyKey nor MyIv are used here:
ECRYPT_decrypt_bytes(&ctx, ciphertext, plaintext, ciphertext_len);

The ChaCha20 algorithm is simple enough that if you're curious about how it works you could just write your own implementation (but don't use it in production!).  RFC 7539 is a simple reference that also comes with examples so you can easily check for correctness as you go along.  But the way it works is that you XOR the message with a keystream that is generated as a set of 64-byte blocks, where each block is "named" by three arguments:

The key (secret);
The nonce (not secret);
The block counter (not secret).

The block is initialized with these values and some constants in the way that your code snippet shows.  Then the block is scrambled with the doubleround operation ten times (ten double rounds = twenty rounds, that's why there's a "20" in the name).  And now, critically, the initial state of the block is added into the result of that, and this step requires the key again—so if you erased it you wouldn't be able to carry out this final step.

After that final addition the key should not be easily recoverable from the resulting block (or otherwise the cipher is completely broken!).  But nevertheless the block's content is a sensitive secret, because an attacker who sees it can decrypt the corresponding ciphertext block.

All you've got at this point, however, is one 64-byte block, which is good only for encrypting or decrypting one 64-byte block of the message.  Unless 64 bytes is the largest message length you'll ever encrypt, you're going to need the key again and again to generate additional blocks.  So you can only erase the key and blocks after you've encrypted or decrypted the whole message.

Since both the key and the keystream blocks are secret data, you'd want to use your operating system's facilities to prevent that memory from being swapped out to disk.  And you'll want to safely zero out that memory after you're done with it.

Similar considerations apply to other ciphers, but the details are different.  For example, many ciphers (but not ChaCha20) have a key schedule, i.e. a sequence of "subkeys" that are derived from the secret key.  Often it is the case that after you've generated the key schedule you don't need the key any more, so you could zero out the key at that point, but the subkeys need to be protected, and you need to hang on to them because you reuse them for each block that you process.


What will happen if my GnuPG passphrase is discovered? Hypothetically, should I be concerned if someone has my public key and knows my passphrase? Will they be able to decrypt messages sent to me?

Should I be concerned if someone has my public key and knows my passphrase?

The passphrase is used to encrypt the private key. An attacker cannot do anything with the passphrase and the public key; but make sure he cannot get hold of the encrypted private key. The private key's security is somewhat like two factor authentication: something you own (the private key file) and something you know (the passphrase).

Changing the passphrase might help preventing the attacker gets hold of a copy of your private key encrypted with the already known passphrase, also consider backups. If you're in doubt whether the attacker also got hold of the encrypted private key (which he's now able to decrypt), consider revoking your key.

  Will they be able to decrypt messages sent to me?

Absolutely not (without a private key as described above). All decryption operations are performed using the private key.


Is it possible to turn a computer into a bomb? I know this newspaper article sounds absurd.  Even if a machine is compromised we (should) have hardware safe guards in all our devices to prevent the software from damaging the hardware.  But is it possible to make a computer explode or catch fire?   Has this ever been done?

In 2011 the news was reporting on HP Printers catching fire. HP Responded saying that there was a hardware element called a "thermal breaker" to prevent this from happening.  The researcher never produced a burning pile of printer.

Also in 2011 Charlie Miller was researching the firmware on Apple's batteries trying to get them to explode or catch fire.
However the worst he was able to do was brick the battery.

Edit Feb 2014 - CrowdStrike demonstrated an attack at RSA on a Mac which overrode temperature controls, powered off the fans and spiked the CPU usage in order to overheat the machine. And while this specific example was limited as fires are not welcomed in the Moscone Centre, the ateam state that they can cause the machine to catch fire.

Now lets flash back to 1985. The Therac-25 radiation therapy machine is killing people  due to a bug in how the software interacted with hardware.  An eariler model had "Hardware Interlocks" which prevented the operator from accidentally overdosing patents with radation.

All of the devices we use should have a hardware control preventing software from damaging the physical world.

But there are some systems where its impractical for hardware to prevent all damage to physical systems. This is the real fear behind vulnerabilities in SCADA systems. It maybe possible for an attacker to remove safety controls used by a power plant or put it into an unstable state.

An example of this happening in real life is Stuxnet being used to destroy centrifuges. There is some evidence to suggest that a hacker was the cause of a missile explosion at an Iranian Military base.  So if the computer happens to also be a bomb,  then yes,  a hacker can probably make it explode.


John McAfee's Explanation of iOS Hack I'm referring to this YouTube video, and further comment from John:

  I hope everyone knows that the Apple explanation was VASTLY dumbed
  down for the press. I know the A7 system chip well, including its
  secure enclave with separate coprocessor that stores the encrypted
  fingerprint, the ephemeral key generated by the co-processor that even
  Apple doesn't know, the secure enclave memory isolated from the rest
  of the processes on the chip, etc. Doesn't matter. The main ARM
  processor has its own memory and that's what I'm interested in. I will
  simply sidestep calling the secure enclave and pretend it doesn't
  exist. I'm not trying to get encrypted data, merely trying to force a
  complete boot of IOS. Trivial, given the fact that the entire A7
  system chip has been expanded into a board with separate components
  for every subfunction of the chip. on the board, the secure enclave
  processor and it's memory are fully accessible, even though we won't
  need it. made in China.

What I don't understand is how this solves the problem. In a nutshell, John is taking the hardware, extracting the assembly into a readable instruction set and running the code flow. He claims that finding the method that accepts the keyboard input and then finding the memory location of the Touch ID code will open the phone. What is is conveyed to the public, at least from a Joe Blogs standpoint, is the Touch ID code is stored in the clear i.e. You can just read it off with no post processing once you know the memory address.

Two things struck me:

I assume the TouchID Lock code, which is what he is referring to, is
at the very least hashed and likely salted. I'm lead to believe it
actually resides on a separate chip entirely with the encrypted
finger print. So even having the memory location and the hash itself
is pointless, you still need to brute force it and depending on
complexity you are no further along.
He claims he needs an iOS full boot, which occurs regardless of if
you have the TouchID Lock code or not, but critically you need to
enter the TouchID code when the phone is booted anyway to do
anything. So I don't see his point.

Unless I'm missing something, I don't see how this solves the problem and I feel its utterly misleading. Explanations & clarification welcome!

I think the biggest red flag to me is that he talks about the secure enclave. That model didn't even have one. I think that's enough to tell me he doesn't know what he's talking about.

  The recovered iPhone is a model 5C. The iPhone 5C lacks TouchID and, therefore, lacks a Secure Enclave. The Secure Enclave is not a concern. Nearly all of the passcode protections are implemented in software by the iOS operating system and are replaceable by a single firmware update.

Source

If I could guess what he was getting to, it would be that he's on about getting an unofficial patched/modified iOS to boot to the lock screen and then allow it to allow numerous unlock attempts without wiping which is what was requested but limited by the iOS signing protection, when he's talking about just getting it to boot and fingerprints he is perhaps talking about bypassing the iOS signing protection that means the device will only boot official iOS code that it likes and matches the trusted fingerprint. From there the cracking can begin.

The fact he references a secure enclave that doesn't exist however to me makes me dubious of his further statements.

The best write-up I have found for this is at http://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/ most other sites appear to be getting this horrificly wrong.


How to safely collect bank account from website? I want to collect bank account information from my customers on my website.

I'd like to do that through a form, then I will download it to a PC, print it, and then delete it from the website. Or eventually, send it somewhere external right after the user submitted the form so it never gets stored on the website.

The goal is to receive the payment information without having to ask the customer to print, fill manually, and send it over fax. And accomplish this without having to use an external payment gateway.

The simple answer is don't. Don't handle financial information unless absolutely necessary. Look into third-party payment processors. Supporting them is far easier than tackling the legal and technical challenges of handling sensitive information like bank account numbers. Also, by hosting this information, you are making you and your customers a target.

See Monthly Payment Processing and others like it.


Can counter-based OTPs instantly be reused at multiple services? I am reading about hardware-based 2FA and wonder about counter-based OTPs generated from, for example, a Yubikey. I have read that in these cases, a push of a button generates a string composed of a public key, a counter, and the OTP. The service verifies the OTP using the public key and the counter, and ensures that the counter is higher than a previously used counter using that public key at that service.

But a different service would not be able to know if this OTP (for counter 50, let's say) had been used someplace else. Am I correct or am I missing something? How is this dealt with?

Am I correct or am I missing something? How is this dealt with?

No. You're right. This is up to the backend to deal with. If it doesn't do anything about that then that's just the way that is.

To counter this you could e.g.

imagine something like keeping a centralized round robin database of the last five minutes of used codes. (Assuming that after 5 minutes or so, they're expired anyway and you can remove them from the database.

It seems that Drupal can do that:

  New table stores salted hash of accepted TOTP codes to prevent replay attack. TOTP plugin rejects codes that are stored. Stored codes are cleared on cron after 1 day,

It seems that FreeIPA also does this

  We will implement a watermark system which records that last interval used.

Only accept the TOTP via HTTPS, so it is harder to intercept in the first place.


SYN scan, TCP packet question during SYN scans, many small tcp packets are sent to multiple ports to determine which ports are open or not. But when you're streaming media, aren't you receiving many

One type of ID system, the Dendritic Cell Algoritithm is used to determine if SYN scans are occurring on a host. Now, one portion (out of 7) determines the ratio of TCP packets to total packets that are being sent to a "malicious host". How would this portion be able to determine whether the (would be victim) host is seeding a torrent, or if they were being SYN scanned by an attacker?

The next portion of this DCA calculates the average size of packets and the standard deviation. The average packet size becomes 40 bytes because much of the traffic is just ~40 byte SYN packets. Now the reason for the standard deviation being included is that many of the infinite combinations of network packet sizes could average to 40 bytes so this is a safeguard. This seems pretty secure, but I don't know much information about this, are there other common types of packets that one can send in large quantities to a network (to multiple ports or even a single port) that are about 40 bytes?

SYN packets are a TCP concept. TCP is about opening then using a connection, i.e. a bidirectional tunnel. A connection begins with the three-way handshake: a packet with the SYN flag from the client, then a packet with the SYN and ACK flags from the server, then a packet with the ACK flag from the client. So there will be, for a normal connection, a single incoming packet with the SYN flag, even if gigabytes are data are then exchanged over the connection.

With UDP, there is no "SYN" at all. "SYN" is a flag written in the TCP header of some packets. No TCP, no TCP header, hence no SYN.

For a server which "streams media", the ratio of SYN packets ought to be very low: either the streaming protocol uses TCP, in which case there is only one incoming SYN per connection, or the streaming protocol uses UDP, in which case there is no SYN at all.

Using packet size as a way to detect SYN packets seems kinda stupid. A SYN packet can be unambiguously recognized as such by virtue of the SYN flag being written on it. Any decent IDS system ought to be able to decode TCP and UDP headers, see what packet is which, and look at the SYN flag. See the TCP standard for the header format: the SYN flag is 7th bit of the 14th byte of the header. Relying on the packet size, instead of simply looking at that bit, smells like incompetence.

Also, packet size is not guaranteed. A "SYN" packet is an IP packet which contains a TCP header which features the SYN flag. Both the IP header and the TCP header can contain "options", allowing the size to be changed at will. A SYN packet is not necessarily 40-byte long; this is just the usual size. If IDS systems begin to use packet size as a way to detect scans, then scanners will soon randomize the size of their SYN packets as a countermeasure.


How to set autorunscript of core commands? I'm trying to automate scripts of an Android Metasploit payload. I can successfully automate any script on the /post module, however, I'm trying to automate geolocate, dump_calllog and others that are not on the post module. I think from what I searched in the metasploit folders that they are in /lib/rex folder. How can I add them in autorunscript so that they automate?

If I were doing this and wanted to own the process, I'd copy the scripts into the self created scripts section under ~/.msf4 then I'd call the script from there.

here is a link for custom scripting. Some scripts can be added to the /usr/share directory while others need to be placed in ~/.msf4

https://www.offensive-security.com/metasploit-unleashed/custom-scripting/

Here is a copy of the geolocation script from google.

https://github.com/rapid7/metasploit-framework/blob/master/lib/rex/google/geolocation.rb


Speaking Plain HTTP over an SSL enabled Server port atm I'm facing a problem with IE and Firefox because they don't redirect my Links correctly.
I'm requesting my application via:

https://myapp.example.de/context

In my webapplication I have links like that:

http://myapp.example.de:443/context/sublink

When I try to navigate to this link I get the following error

in Firefox:

Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

in IE:

blank page

in Chrome:
it works perfectly and I'm redirected to the correct path which is:

https://myapp.example.de/context/sublink

My rewrite condition in my apache vhost from 80 to 443 and 443 looks like that:

<VirtualHost ip:80>

        RewriteEngine On
        RewriteRule ^/?(.*) https://myapp.example.com/$1 [R,L]

</VirtualHost>

<VirtualHost ip:443>
        RewriteEngine On
        RewriteCond %{SERVER_PROTOCOL}  =http
        RewriteRule ^/?(.*) https://myapp.example.com/$1 [R,L]
</VirtualHost>

How can I write a Apache redirect rule that lets me navigate to this links and redirect them to the correct path which would be:

https://myapp.example.de/context/sublink

Thanks in advance for your help!

http://myapp.example.de:443/context/sublink

This is incorrect and shouldn't work in any browser. You are explicitly telling the browser that it should use plaintext http protocol on port 443. If your server is serving SSL on that port, the connection should fail (as it correctly does in Firefox).


Are requests with no UserAgent header a risk? A service I use has decided to block HTTP requests that do not provide a UserAgent, citing security reasons.

As far as I can tell, the UserAgent is a string without a standard format used primarily for statistics, serving different page versions (eg mobile), and blocking bots.  The RFC says it SHOULD (but not MUST) be sent.

Why Shellshock works in useragent string? suggests that a malicious UserAgent could be constructed, but the service is blocking requests without a UserAgent.

Is there a vulnerability around absent UserAgent headers I'm not aware of?

Not really, your understanding seems to be correct. Pretty much every web browser (and most other HTTP clients) will send a user-agent string, so arguably any request that arrives without one is pretty sketchy-looking. On the other hand, it costs basically nothing to send one (for example, with curl, use the -A argument) and is not guaranteed to have anything to do with the truth. Most clients, including browsers, let you spoof the UA string as anything you (the user) want it to be.

Of course, if you tell the server that you're IE 5 running on Windows CE, you might get back some really abysmally shitty HTML/JS - many web servers use UA strings to send different versions of web pages based on the expected capabilities of the browser making the request - but that's your problem, not the server's problem. Same goes for sending no UA string at all.

Security-wise, you could maybe put a speed bump in an attacker's way by blocking requests with no UA, or with an untrusted UA, but all that an attacker has to do is just spoof the UA of, say, the current version of Chrome (which is easy to find and easy to use). It's nothing more than a speed bump. I wouldn't even call it defense-in-depth, since it's so trivial to bypass.

I think your service provider really doesn't grok security, and is falling for what I call the "no legitimate user" fallacy (not to be confused with "no true Scotsman"). It goes like this: "OK, so there's a security threat if the user [does X]? Well, no legitimate user would do that, so we're safe." In this case, [does X] seems to be "spoofs their client's UA string". A lot of people just don't understand that an attacker can, and will, impersonate a legitimate user well enough that you can't reliably tell the difference until you've been exploited.

Well, either that or they just aren't aware that the UA string is nigh-meaningless and trivially editable.


Amazon S3 Encrypted File Backup System I am designing my backup system to Amazon S3 (probably Singapore) and I would like to have all my files strongly encrypted on the server. I use ArchLinux x64. My system will append only once an encrypted folder is upload nothing inside this folder will change.
eg. I have documents and each month I will upload a folder for that month.

please note I do not want to use Amazon SSE something about them having the keys to my data feels like a waste of time to me (I may use this in addition to what I describe below).

I wish to do the following (to encrypt the folder foo):

sha512 every file in foo and place the list of hashes in foo/hashes.sha512
dd if=/dev/urandom | tr -dc '[:print:]' | fold -w 256 | head -n 1 > foo.key
tar -cvjO "foo" | openssl aes-256-cbc -salt -kfile foo.key | dd of="foo.enc"
sha512sum foo.enc >> foo.key (openssl only reads the first line for the key)
sha512sum foo/hashes.sha512 >> foo.key
openssl aes-256-cbc -salt -in foo.key -out foo.key.enc
Manually specify password
Upload foo.enc to S3
Keep foo.key.enc safe!

I have a few key questions:

Is this a proper use of each of these tools?
Is using /dev/urandom a good method of generating a password?
Is my method of storing locally the file encrypted with the weaker key (the one I remember) and only uploading the files that are encrypted with the larger unique keys as strong as it seems?
What is the largest value I can put in as the key value for openssl?
Any obvious serious issues?

+1 for Yoav Aner's comment.

I don't have any particular experience with the questions you asked, but it seems like designing such a system from scratch without any prior knowledge and experience will only lead to trouble.

Is there are particular reason you do not want to use premade tools?


Aren't VPN servers exposed to the same threats as public Wi-Fi? Besides trust of the VPN provider, are VPN servers safe? Other people connect to it and it can be compromised, right? Is it the same threat as being connected to a public Wi-Fi where someone could performs a Man-in-the-Middle attack?

You hit the nail.... "trust of the VPN provider"....

Whilst we can read what a VPN provider might offer, this still doesn't solidify the fact we have no real idea.

We have to just assume the VPN provider is routing our traffic in the correct manor and sourcing it from random locations as per our request. We also have to assume they encrypt log files (if they store them) and encrypt our traffic.

It's maybe too open ended to give a short & sweet answer here, but we can guarantee that certain VPN's don't use the best encryption methods, especially most of the free VPN's that only offer single layer protection (i.e, just concealing your IP and nothing else).

VPN servers are indeed vulnerable to mitm attacks, but the amount of variants that come into play are quiet large, the best summary of which would be to say it really does depend on the quality of services the VPN distributor is providing.


IMAP credentials in WEB (browser) app - how to use securely I need to send and check email (via IMAP email servers) from my web app. Storing credentials on server seems like problem as they are almost always plain text.
So if I store them in client browser's storage how security risk this could be? Is there any way to make this secure without access to OS security enclaves like native apps have?
I think other than Google who uses oauth any other provider probably allow access to IMAP with just plain text.
Thank you

Based on the comments following the question:
You might want to consider encrypting the IMAP credentials on the client-side (in-browser, using the javascript web crypto api), using an encryption key generated client-side, then storing the encrypted credentials on the server.  This way, the server stores only the encrypted credentials, not the plaintext credentials; and the key for decrypting the credentials never leaves the browser.
As for storing the key for decrypting the credentials - see https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for a solution for storing the key securely in the browser's indexedDB storage.
When it comes time to login to the IMAP server from the client, the client simply fetches the encrypted IMAP credentials from the server, and retrieves the key from the browser's IndexedDB storage, and uses the key to decrypt the credentials.


Can Windows 10 bootable USB drive get infected while trying to reinstall Windows? Microsoft allows you to create a recovery drive for Windows 10.

If Windows gets infected with a virus or other malware, can the USB driver also get infected while trying to reinstall Windows?

Of course it can.

Either the OS created on the USB can be made out of a source that has been altered by the virus, either the virus alters the download if the USB stick is initialised with an image downloaded at the moment of the installation.

Even thought malwares usually have a specific task, a very good malwares could also alter the files that are copied when creating a USB stick or the ISO once downloaded


A repeated visitation to a certain url of my app. Why? My app is hosted on google app engine.

I just realise there is a regular visitation from a single IP address to a particular url of my app.

My app always returns 500 because of this runtime error. It is most likely the requests are made by a script (because the user agent column shows 'Unknown')

The incoming IP address is resolved to a physical location in Atlanta, Georgia, USA.

Anyone know why these GET requests happen? Can they be considered 'attacks'? They look rather benign to me.

Edit:

The get request:

So the IP address of the requestor belongs to "Rocket Science Group, LLC". Upon visiting their website, it looks like they develop applications as well. Now knowing who the requester is, does this shed some light on what the activity could be and if it is wanted? Here is a link to their website: http://rocketsciencegroup.com/


Password reset mail - reset password again Let's assume this situation: I am a user of an online shop, I forgot my password. So I use the functionality of this online shop to reset my password. The online shop sends me an email with a link I should visit to change my password. I changed my password, but did not delete this email.

Now, a day later (after this passwod reset) I saw this email again and clicked again on it and I can change my password again. From a security perspective: How would you value this situation?

If you can do that, it means that the developers didn't use a token to only make valid that link for a certain time.

The right solution is to use tokens that will expire either after the password has been reset or after 10-15 mins.


Hashing sensitive data and checking for duplicates I have some sensitive client data that needs to be hashed, but I also need to check that that data isn’t duplicated by another client.
So the hash function needs to produce the same value for the same data so I can search the db for duplicates.

One option is brcrypt with a constant salt but that isn’t very secure.

Any ideas?

ps. we are hashing a short string that could be thought of as a password for the purposes of this.

"Secure" for file hashing is very different to "Secure" for password hashing.

When password hashing, you usually have a "small" string, like "password123". When someone is trying to break the password, they go through small strings and get longer until they find a "collision". Bcrypt and other "slower" choices help to slow down brute-forced password breaking, by making the algorithm more memory/CPU bound with a linear chain of hashing cycles so that GPU optimization doesn't give a significant speed boost.

For file hashing, unlike short password strings, the files are relatively huge. There's no practical way that files could be "brute-forced" to finding a collision. So an algorithm like bcrypt doesn't add any meaningful security benefit.

Therefore, SHA (and even MD5) are "secure" for file hashing. I would tend to choose a hashing algorithm that's CPU/Memory efficient and outputs a large hash string to reduce random chances of a collision with another file. A recent edition of SHA hashing algorithm is probably the best choice.

You might also transmit the length of the file along with the hash for further reduction of risk of a collision, however, that might not be valid for your situation, where revealing a file size could be saying too much.

(Note: I assume the communication of the file hashes occurs over an encrypted transport like TLS)

Looking at the other answer from kelalaka, it's a great answer, but I don't agree with a couple of points, so to clarify:

1)  I don't believe salt is necessary. That's for password hashing, and further slows down the possibility of creating a universal rainbow table. However, again, this is necessary because the password is so short.

2) I don't believe that any form of signing (HMAC) is necessary. For one, that makes hash comparison impossible. Usually a signature accompanies the file bytes, the verifier may hash the file themselves, then check the signature. But also, a hash is already secure enough to disquise the data in the file - that's what it does.