What does a secure path mean? I saw it in a slide for Mark Stamp. He says:

  "Authentication on a stand-alone computer is relatively simple: 1) For
  example, hash a password with a salt. 2) “Secure path,” attacks on
  authentication software, keystroke logging, etc., can be issues "

What does a secure path mean? While I find it easy to understand this term in the context of computer networks, I have trouble understanding it in another context (as in protocols or software for example).

Your question refers to the use of the phrase "secure path" in slide 13 of a talk about Simple Authentication Protocols (or the same/similar slides in several other talks or courses). This context states that "Authentication on a stand-alone computer is relatively simple" but that "attacks on authentication software, keystroke logging, etc., can be issues".

In this context "secure path" refers to the path which leads to the final authentication result, i.e. entering the authentication credentials and validating these credentials. While there can be attacks which affect the security of this path, like key loggers or bugs/backdoors in the authentication software, this path can still be considered sufficiently secure, especially compared to authentication over a network which is the next point on the slide. Thus, "secure path" is meant to be read as not fully secure (that's why it was put in quotes) but comparatively secure in contrast to authentication over a network.


Translate token into cookie I find myself in a situation where I need to hand a user off from a mobile application into a web application. The mobile application is using WebAPI on the backend with OAUTH 2. The web application on the other hand is MVC using cookies.

I'm not able to change the web application in any meaningful way, but I have a requirement to not have the user to log into the website after they've already logged into the app.

So my thinking is add an entry point route to MVC, that doesn't require auth and takes as parameters the token used on the api, and the url the user desires.
The controller would authenticate the token, issue the cookie and the redirect the user to where they want to go.

This would be an invisible hand-over controller. It makes a kind of sense and it should be easy to do, but I feel uncomfortable logging the user into the site without going through the typical route.

Are there potential vulnerabilities in this approach?

I had a similar problem to solve, but from a URL in SMS (simple logon, without username/password). So I generate one time code for it, but you can as well use the existing token (you need to know the keys of course to decrypt or validate it).

You can find details of my approach here with an answer on how secure that approach is. So you can always generate this one time tokens for logon that are valid for say 30 seconds, so it will be very hard to abuse in this short time as far as I can see (though of course you'll need more entropy in the token than I needed for SMS).

Otherwise if you can reuse the same token in the web application, then you don't even need to validate it in this additional request: just issue the cookie with what you got as a parameter, redirect and let MVC handle the rest.


ISO 27001:2013 certification questions Advice/opinion appreciated.

Ultimately, our company would like to achieve ISO27001:2013 certification, but that is some way off. In the interim, we want to be able to get to the point whereby we can "attest" to compliance (similar to the PCI DSS AOC). Is there such a mechanism for ISO27001:2013? Is it possible to get a 3rd party auditor to confirm "progress towards compliance" or will a 3rd party only ever certify based on an audit establishing full compliance?

Our company is effectively split into 2 business units within the same corporate structure. We anticipate that scope for compliance would exist almost entirely within one of those units. If we presented that scope to a 3rd party auditor, but the auditor felt that the scope wasn't wide enough to fully address information security risk within the company, would the auditor be likely to agree to certification?
In other words, will a 3rd party auditor only ever certify at corporate level, or are they amenable to certify particular functions within a corporate structure?

Certification by accreditation bodies only occurs if you are indeed compliant within the scope you have set for your company. You can request ISO27001 auditors to perform a gap assessment and current state and they can do low or high level recommendations to improve your ISMS or assist with implementation. Note that depending on the amount of advise given to you, they may not be allowed anymore to perform the audit (you aren't allowed to audit your own work).
Your certificate states what you are complying with and what the scope is of your certification. Therefore if you can't state to your clients that you are compliant with ISO27001 for your whole company. You are only compliant for that particular business unit within your organization.

They can certify certain parts of your company depending on your scope. Let's say you want to for instance only certify your datacenters then you can, but it will also clearly be stated with regard to your certificate.


Pen Tester's Programming Style I recently graduated and now work as a software developer but at some point in my career, I would like to transition into Penetration Testing.

I know that pen testers sometimes write their own tools but I am curious to know if they follow and use Design Patterns, SOLID principles and aim to write clean code, or is it more about getting the program to do its task.

There's a big distinction between pen testers who write a bit of code, and developers of security tools.

During a pen test, you may need to write some custom code. For example, if you find server-side template injection, there's likely to be no off-the-shelf exploit that works in this exact scenario. But with a little bit of coding you can get a shell. These scripts just get the job done; design patterns are irrelevant.

Many security tools are much more complex than one-off scripts. Metasploit is a good example. Before Metasploit, most exploits were developed like one-shot pen test scripts. The exploit would target a specific vulnerability and deliver a specific payload. Metasploit introduced modularity and structure into exploit development. In particular, separating the concepts of: exploits, payloads, and encoders.

In fact, there are now all sorts of security tools that are developed with strong design practices in mind, although a lot of these are commercial, e.g. Nessus, Checkmarx, Burp Suite.


Can my email account be accessed without the password? How secure is it? Can my email account be accessed without the password, and how secure is email if I store my personal documents on it?

And how come Yahoo Mail asks me to tell them my friends and folders names to give it back to me after being stolen?

Typically, your email provider (Yahoo, for example) can read everything in your email without knowing your password.
And they will, as required by law and potentially in other circumstances, provide copies to Law Enforcement and Government.
It is also possible that an attacker could compromise Yahoo's servers and access your email that way.
And an attacker might be able to get hold of your password in various ways, in which case the attacker can gain access to your email.  Or, an attacker might be able to guess the answers to your security questions, which also is sufficient for the attacker to gain access to your email account.
Lastly, it's important to mention that emails are not just documents on your email server; they're also on the email server of the person who sent it to you, and maybe cached on your client, and maybe on their client, and backed up in various places, and they travel over the network. Lots of copies mean lots of places where an attacker can get hold of a copy. (Your question hints that you might just be storing documents in email without sending them, in which case this is less of an issue.)

Now, all this sounds very scary, but it's important in security to understand the level of risk and what your risk appetite is. Nothing is 100% secure - so you have to ask yourself:
 - How valuable is this data to me? What will it cost me if there is a breach?
 - What kind of attacker might try and get it? What resources and capabilities do they have?

If the data is not very valuable, and anyone who is likely to want it is not very capable, then you don't need a lot of security.

I'm not sure this is very practical, so here's some simple tips will help you improve the security of your stored email:

Choose a good password - not in a dictionary, not a name or a date, as long as possible, with a mixture of lowercase, upper case, symbols.
Don't use that same password anywhere else; don't write it down or tell anyone, and use something random that isn't connected to you.
Be careful about your answers to security questions, to make sure that no one will be able to guess them.  If it looks like someone might be able to guess one of the answers to one of your security questions, you could consider lying (pick a random answer that will be unguessable), and write it down somewhere in case you ever need it.
Consider encrypting the documents (with a different password to the one used for your email). There are lots of good tools for this: I like http://www.sophos.com/en-us/products/free-tools/sophos-free-encryption.aspx. Don't rely on built-in passwords in Word or WinZip, use a dedicated encryption tool.


(Android) hacking server by a simple socket I have written an Android game. Now, I want to connect the marks of the players.

The code below is the client side program, which send their names, countries and marks to the server. Basically, I use ':' to separate the information.

However, hackers can know my server ip and port by decompiling .apk file. Then, they can create a basic java application to access my server. They could send me "hacker:badserver:123456789". Finally, the top mark becomes "123456789".

Is it more secure method to connect user's data?

Socket client = new Socket(ip, port);
OutputStream outToServer = client.getOutputStream();
DataOutputStream out = new DataOutputStream(outToServer);
out.writeUTF("Hacker:HK:3910");

You have encountered two "hard" problems: authentication and authorization. There is plenty of information online on thes topic, but in your case I think your problem goes back to the design of the app.

Let us start with two questions:

How do you know whether user is allowed to post a high score? (Authorization)
How do you know the connection to your server comes from an actual game user and not somebody impersonating the game like in your Java example? (Authentication)

Before you try to re-invent the wheel, be aware that there are many libraries that do just that, with the added benefit of being mature, tested, working and well documented.

Not knowing the details of your app, here are a few suggestions:

Let users play in 'solo' mode or in 'online' mode. In the former mode the game is standalone and does not need to make any network connections (good for privacy-aware users). In the latter case users SHALL register with your server.
Once a user is registered (login/password) and you have verified they actually are a "real" user to some extent (e-mail responder, text message, etc.), your server can send back a 'token' to play.
When the app wants to send its high score to your server it MUST authenticate itself by providing the token in a manner similar to what user @mike-mackintosh described in his answer.
All communications to/from should obviously be encrypted with TLS or other forms of strong crypto.
Your app should validate the certificates to avoid man-in-the-middle attacks.

The scenario is simplified: of course an attacker with enough resources could register a fake account, reverse engineer your app, determine the message to use and send bogus data to your server. To prevent it you'll need to ask the platform to verify that the app hasn't been tampered with, which in turn means extending the chain of trust to the operating system running the app, and so on. In the end it gets complicated (ever heard of "trusted computing" and digital rights management?) and depends on the value you're trying to protect.

Another avenue of research could be some form of server-side validation. For example, every time a user posts a score higher than X, they must also supply "proof" that they unlocked a certain achievement e.g. a random string that is saved in the user profile when they reach a specific point in the game. In this case you can double-check server-side that the user did actually pass the previous achievements earlier on.

You can spice things up furtner by generating the 'level' tokens by combining the phone's IMEI with a random key and using some form of public key encryption so that each user is tied to their phone. Which would work, unless somebody were using a custom ROM for android that allows tweaking the phone's IMEI, and so on.


What is the difference between claims and capabilities in access control? I've read about the differences between capabilities and access control lists, but to me capabilities seem similar to claims. Can anyone explain the difference, if there is one?

Claims and capabilities are both evidence-supported tokens, but they are totally different in terms of intent.

In a capabilities-based access control model, a capability is a token which demonstrates a capability, i.e. a right to perform an action on an object. An important thing to note here is that the capability does not contain any notion of identity, but rather the permission itself. Possession of the capability token is considered evidence towards being able to carry out an operation.

Claims are similar, but they're about identity. A claim says "I am this person", and is usually comprised of sets of evidence to demonstrate that fact. Kerberos tokens work on this model. Claims are combined with access control lists (ACLs) applied to objects. An ACL might say "user X has permission Y for this object". The user makes a claim to be user X, and provides evidence to prove this fact. If the evidence is accepted, she is allowed to perform operations which require permission Y.

In summary, the main difference is that a capability is a token which provides proof of being allowed to perform a privileged action, whereas a claim is a token which provides proof of identity, which can in turn be used to show proof of being allowed to perform an action in the context of a particular ACL.


Why can salts be public? From what I understand, salts are called "salts" rather than "keys" because they are allowed to be public. I understand that applying a random salt makes it difficult for rainbow table attacks because the hashed and salted password will be different for each user, even if they have the same password.

However, isn't going from salted password to hashed password trivial if the salt is public? Even if an attacker has to recalculate the hash for every user, that is still only one calculation for each user. And if applying a salt is O(1), shouldn't undoing every user cost O(n)?

I feel as if I am missing something. To me, it seems like undoing the salt is only one additional step that can be easily automated, and in the end leaves hashed just as susceptible to rainbow table attacks.

The point of a unique salt is this: the work that the attacker does to crack one user's salted password cannot be reused against another user.  So it addresses this point of your question:

  Even if you had to recalculate the hash for every user, that is still only one calculation for each user. And if applying a salt is O(1), shouldn't undoing every user cost O(n)?

Think of it this way.  Suppose you have n users, and the attacker is going to perform m password guesses.  If you don't have salts, then the attacker can check each of their m password guesses against all n users—which means that they get to perform m × n user/password pair guesses.

With unique salts, on the other hand, each of the attacker's m password guesses is only applicable to one user.  So they can only perform m user/password pair guesses.  This is a big win for the defender.

And this analysis assumes that the attacker knows all of the salts.  So the answer to your question, strictly speaking, is that salts can be public because they offer a big security improvement even if the attacker knows them.  (In contrast with keys—e.g., ciphers offer no security against an attacker who knows the key.)

We can tweak your question a bit and ask: why not keep salts secret?  Well, that's actually a thing; the popular name for "secret salts" is  pepper, and there are people who use them—they offer further security beyond what public salts do.  But many folks just don't think that the extra security is worth the time and hassle of keeping additional secrets.  Others are actually skeptical that it adds more security in practice:

http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html
https://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords

Others however are more positive about peppers.  Notably, the Password Hashing Competition's call for submissions specifically allowed for algorithms to accept a "secret key" (pepper) in addition to a salt.

But one thing is for sure—using peppers is much more complex than using public salts, because of the extra measures needed to make sure that a compromise of the password database doesn't also compromise the peppers.


What (aside from the law) prevents cloud-hosting owners from eavesdropping on servers/code? Given a server hosted on a cloud platform, what would stop the cloud platform owner from stealing the server's data and/or code?
As far as I can tell, a motivated cloud owner could retrieve the data in its servers while keeping plausible deniability.
Certain large companies also seem to have incentive to do this, as they'd benefit from extra data.

Technically, you cannot protect a system against its administrator. So when a company hosts a site or an application in an external computer center, they trust that computer center to behave professionally.
For that reason, it in common not to externalize the most sensitive informations.
As usual when it comes to Information Security, everything ends as a matter of cost and risk. For rather trivial information, the gain of externalization is higher than the risk of stealth, but for highly sensitive information the risk is often bigger than the gain.


What problems does this "recover account" procedure have? On a website I run I have implemented this procedure for account recovery (forgotten password procedure). I would like to know whether there are any issues with it that I have not spotted, that make it insecure.

When the user creates an account, they are required to enter a password (of course) and an email address. They are also required to select a "secret question" from a list of about 20 questions, and enter a "secret answer" to that question. The password and secret question answer are each hashed, each with a different, random salt. Assume that the hashing function used is adequate. (The user can change their email, password and/or secret question/answer at any time, must enter password to do so. I do not impose any password strength requirement, except for a minimum-length requirement.)

If the user needs to recover the account, they go to the account recovery page and enter their user name. An email is sent to the email address associated to their account. This email contains a link which contains a randomly-generated code (site.com/accountrecovery?user=1234&code=bryvthery6y65htee or the like). When the user clicks the link, they are taken back to the site, and assuming the code checks out they are taken to a page where they are asked their secret question and must answer it and at the same time, enter a new password.

Whenever the stored password or secret answer is changed, by whatever method, a new random salt is generated for it.

Are there any issues with this setup that come to mind? I would like constructive criticism. The thinking behind it is that in order to be able to reset the password, the user must have access to the registered email address and must know the secret answer.

As usual - depends on the nature of what you're protecting.  Seems decent enough for basic information.  May need more if you are writing code for something high end - like web banking.

Whenever secret questions/answers are used, the answer ends up taking the place of a password somewhere, and its easy for that to be your weakest link.  Since secret answers can easily be things that an attacker could find out by Googling the person, they can be a real risk factor - and it's hard to tread the line of questions that are so unusual that they are not relatively easy to figure out and questions that are so esoteric or non-applicable that the account owner can't answer them.

I like @Iszi's idea of letting the person write their own Q&A set - that circumvents the problem nicely.

In the case you mention if an attacker can intercept email coming from you system, then they don't need the user's account.  That means that the biggest line of defense is that shared secret.

You didn't say, but I'm assuming that all account set up and password reset happens with SSL/TLS protection, right?  If not, that would probably be the bigger problem.


Tampering files to protect them I compressed some pictures it a zip file.
Next, I opened this zipped file with Notepad++, changed it a bit and saved it. As expected, in this condition the zipped file doesn't open up.

When I undo the changes I made to the zip file, it opens up and the pictures are still there!

My question is, is this a good method to secure my personal files? Most importantly is it possible that the changes of the code could be undone by a software or other ways?

No, it's not secure.

First, it relies on security through obscurity. Someone who knows you used that method might be able to undo it by trying random changes to the file.

Second, you don't know what you changed, so it is possible you changed something unimportant which might be fixable by a better packing tool.

Third, zip files can be password-protected. Why don't you just do that? (for further reading I recommend the question Is it easier to crack a ZIP file than a 7z archived file given they have the same password?)


Which CA currently issues certificates for Wikipedia sites? Which CA currently issues certificates for Wikipedia sites? Are there two or more different CAs issuing certificates for *.wikipedia.org?

In a short period (less than half a hour), I noticed certificates for Wikipedia issued by two different CAs (GlobalSign and DigiCert). I do not know much about certificates, so I'm asking here.

I can remember that for some time certificate(s) for Wikipedia sites was/were issued by GlobalSign. I'm using Firefox, and last year or two, when I clicked the green lock in the address bar, it always displayed Verified by: GlobalSign nv-sa. A few hours ago, while browsing Wikipedia from home, I opened another page in a new tab. It seemed to me that the page loaded incompletely and then stopped loading and reloaded again. I clicked the green lock and this time it displayed Verified by: DigiCert Inc. I am not sure whether I saw Verified by: GlobalSign earlier in the same session, though.

I closed all tabs, cleared history and cache and restarted the browser. When I entered https://en.wikipedia.org in the address bar, the browser refused to open it and displayed error page with message that something is wrong with certificate (I do not remember what was the exact error message). I visited a few other sites and did not notice any problems, then restarted Firefox again and this time was able to open https://en.wikipedia.org. The certificate was issued by DigiCert. I thought that if Wikipedia's CA changed then there must be something about this on the web and googled a bit but did not find anything relevant.

I opened TBB and browsed Wikipedia in it for few minutes and the issuer was DigiCert. At some point I opened another tab and noticed the issuer was GlobalSign nv-ca again. Now I have TBB open with two tabs; clicking green lock sign in one tab shows Verified by: DigiCert Inc, and in another tab Verified by: GlobalSign nv-sa (see below for more differing details from these two tabs). I guess this might be due to changed exit relay.

I found this question which seems to be related somehow.

Can someone explain what might be going on? Did Wikipedia's CA change recently or is it changing currently? Is there something to worry about?

Details from the two tabs in TBB:

Tab 1:

Issued To
  Serial Number: 05:A9:5C:0D:34:A8:31:F3:7F:8A:5F:72:9C:C2:3C:74
Issued By
  CN: DigiCert SHA2 High Assurance Server CA
  O:  DigiCert Inc
  OU: www.digicert.com
Period of Validity
  Begins On    19 Dec 2016
  Expires On   3 Jan 2018
Fingerprints
  SHA-256: E8:04:B7:5C:F2:B5:0B:1F:41:EE:B1:BB:90:81:17:8D:86:86:3F:93:25:3D:10:0D:85:8D:FB:3D:51:20:B8:6B
  SHA1:    1B:27:6F:BE:CD:10:49:C8:F2:F1:72:C8:40:99:D2:19:25:78:B9:9C
Certificate Hierarchy:
  DigiCert High Assurance EV Root CA
    DigiCert SHA2 High Assurance Server CA
      *.wikipedia.org

Tab 2:

Issued To
  Serial Number: 10:E6:FC:62:B7:41:8A:D5:00:5E:45:B6
Issued By
  CN: GlobalSign Organization Validation CA - SHA256 - G2
  O:  GlobalSign nv-sa
  OU: <Not Part Of Certificate>
Period of Validity
  Begins On:  21 Nov 2016
  Expires On: 22 Nov 2017
Fingerprints:
  SHA-256: 05:7A:A6:B4:58:FD:66:B7:F1:A0:72:2B:2E:0C:9E:08:BE:A1:76:6C:77:85:43:C0:99:01:7F:61:FF:65:7F:7E
  SHA1:    58:66:84:EF:77:3E:A0:B8:5F:23:38:73:CB:46:10:E8:D0:E0:8C:B3
Certificate Hierarchy:
  GlobalSign
    GlobalSign Organization Validation CA - SHA256 - G2
      *.wikipedia.org

There is an ongoing task at Wikimedia to use two separate CAs:

  This was originally on our long-term radar as part of the (forever-stalled and in-discussion!) [H]PKP ticket: T92002 . The recent GlobalSign issue has highlighted the need to break this out as a higher-priority action we should take on independently of that.

  We need to obtain our "unified" cert from two vendors with the same SAN set, in both ECC and RSA forms. Ideally the annual renewal time for each should be at least slightly offset (~1 month?). We'll puppetize the deployment of both keys to all of the cache clusters, including live OCSP staple fetching for both from everywhere.

  We'll puppetize such that VendorA's certs are live in one set of datacenters and VendorB's are live in another under normal conditions. With both in active use, we'll be ensured they're both normally working properly on fine details like browser compatibility, OCSP, PKP, etc. By splitting on regions (rather than other arbitrary splits), we avoid issues with individual clients commonly bouncing between two disparate certs and the effect that may have on performance-related issues.

On January 5th (today), a change rolled out to use both certs in normal circumstances:

  These are now deployed (digicert in esams, globalsign elsewhere). Pending closing this until we document switching off either of the certs...

So in summary: yes, this is expected and not indicative of a problem.


How to solve this double master password dilema with dashlane? I just installed this password manager (dashlane).
I put all my password in it including those of my email accounts.

I thought password managers have the purpose that I only have to remember one master password and it stores all the other for me securely. This allows them to be long and random and hard to guess and so on and so forth. Great, except that it doesn't really work like that in practice, because dashlane requires verification whenever I use my master password on a new device.

Here are two scenarios where this fails:

I installed a new system. Then installed the dashlane app. Now I can enter my master password there, but it doesn't grant me access, because I need to enter a security code that it sent to my e-mail. But guess what I need to check my emails? My e-mail password, which is stored in dashlane. This is a security deadlock.
If I want to check my e-mails in an internet cafe or on a friends computer, I can retrieve my password for that without having the dashlane app installed via their website. But again, I have to verify the login through my e-mail. Deadlock, again.

To solve this, I have to have a human rememberable password for my e-mail. As it appears to be a bad idea in general to re-use a password for different places, this password should be distinct from my dashlane master password. But that in turn weakens the purpose of the password manager.

What's the best practice for solving this problem? Should I have two passwords (for my manager and my e-mail associated with it)? Should I include the e-mail password in the manager?

The goal of a password manager is indeed to reduce the memory requirements needed to use lots of strong, unique passwords or passphrases.  But they don't completely eliminate all memory burden, as you've noted.  There will always be some passwords/passphrases that you have to commit to memory.  Password managers just help you reduce that to a manageable number.

So yes, you should have a separate email password and memorize it if you need to log in on a system where you won't have access to your password manager database.  That's true of any similar situation, regardless of the behavior of a particular password manager product.

Alternatively you can write your email password down on a note that you keep in your wallet or other private place, if you are willing to accept the threat of someone finding it there and figuring out what it is.

I would still keep a record of your email password in the password manager just as a failsafe since you could still access it from a trusted computer in the case of a memory lapse (or losing your wallet).


Persistent Bootable USB with Write Protection? I am developing a series of extraction scripts (currently python 2.7) for a university project - these tools will be provided on a bootable USB for use by first responders when encountering a suspect device (PC/Laptop).

I am currently using the CAINE distro as a payload to transport and execute the scripts given it has in-built in write blocking capabilities on all drives. (This is a must for my project) However the absence of persistence on the USB means that any extracted data is lost on unplugging the USB.

Does anyone know of a platform which can provide the same write-blocking capabilies while also enabling persistent storage on the USB? I understand KALI has a persistent mode, however I also believe this does not come with the write-blocking provided by KALI forensic mode.

I would prefer not to build my own custom distro however if this is the only possible method then any documentation or guidance as to where to start would be greatly appreciated. :)

Put an additional partition on your USB drive.

Mount it as write enabled from CAINE. Target your extractions to this partition.


Limiting FTP privileges on Windows Server I currently have a Windows 2012 Server which is acting as a webserver running IIS.
I am using Filezilla to host an FTP server to allow some clients FTP access to their own websites.

I have setup the FTP account with ease and they are able to access their website folder. However I really wish to explore this further and actually make this secure. At the moment there is nothing stopping them uploading .exe file and run on the website, to hack my server.

How can I limit the files they upload to just a few desired extensions such as PHP, JS as well as disabling renaming of entities (to stop them changing back the extention to .exe as an example).
Additionally, are there any other security measures I could take?

Please tell me if I missed any information. Please do not reply with comments such as "If you don't trust them, dont give access" as this is off topic

First things first -- FTP is a deprecated protocol according to the IETF.  It has been deprecated in favor of secure protocols such as SFTP.  I recommend using only SFTP and not using FTP, because FTP commands and usernames/passwords are sent in plain text.  Anyone monitoring the user's network (e.g. a coffee shop wifi) could obtain their password and easily get into their account.

That said, FileZilla server has a function called "Filename Filters" but this isn't enforced on the server, and can only be used from the client.  So, there is no way in FileZilla server according to the documentation that I see to do this.  That said, malicious files can easily be javascript files, or simply have no extension or masquerade as a legitimate extension such as .html.  If an exploit is run to somehow invoke the code in those files (e.g. being executed through another executable -- like a bug in the filezilla server, so ostensibly filezilla.exe is executing this code), it wouldn't matter what the file extension was, as that code will be executed.  Thus, the server's lack of support for this filtering isn't much of a security loss.

So, limiting filename extensions can provide a minor increase in security; but is definitely not a cure-all nor would it prevent a skilled attacker from exploiting your system -- thus probably the reason support isn't implemented in FileZilla server.  Instead, think of it as a small part of a comprehensive program of "best practices" to limit access, including using secure protocols such as SFTP, security hardening the server (e.g. CIS hardening standards), installing regular updates, antivirus protection, firewalls and/or intrusion detection, regularly updating the FileZilla server, et cetera.


symetric key encryption vs hashing This is a fascinating document: top 100 passwords from adobe breach
I have a question about one part of it:

However, thanks to Adobe choosing symmetric key encryption over hashing,
selecting ECB mode, and using the same key for every password, combined with a large number of
known plaintexts and the generosity of users who flat-out gave us their password in their password
hint, this is not preventing us from presenting you with this list of the top 100 passwords
selected by Adobe users.

So, because in the past we have allowed developers to use symmetric key encryption instead of password hashing, and here they view "using the same key for every password" as a separate problem, what is the big deal with using symmetric key encryption to store passwords?  I understand there could be a performance hit because hashing was designed with speed in mind.

What's so important about passwords? There's no way around it. Users reuse passwords. Accept it. As a responsible service provider you must understand that and handle your customer passwords with care.

Why not store passwords in plaintext? Because passwords are used for authentication, and password-based authentication doesn't need the plaintext password. Passwords are sensitive information and needs to be kept secret.

Why not store passwords in a non-plaintext reversible format? If an attacker compromises your system, he will have access to your password storage logic and he will reverse the password mangling you're using. This renders the passwords plaintext.

Why not encrypt passwords with a symmetric key? Because the login logic of your application needs to have access to that key, which creates key management issues. In case of a breach, it's very likely that the attacker will have access to the key. This renders the passwords reversible.

Why not use MD5/SHA1? Because they're super fast. Super fast for you means super fast for the attacker to crack.

So, now what? Securely hash your passwords using a strong, non-reversible, and slow scheme like bcrypt. There's no alternative for this. Period.

Adobe went with the symmetric encryption option, not only that, they implemented it incorrectly by using ECB. So they took something bad, and made it even worse.


Specifying my key name while encrypting file to some receiver using GnuPG I would like to make sure of one thing. When I am encrypting file, the only needed key to specify  is --recipient, because I only need to specify key to encrypt (receiver key)? I don't need to specify name of my key. There is no point in specifying my key name, because encryption only uses only receiver key. Is that right?

There is no need for your own key when encrypting message to other recipients: only the recipient's public key is required.

There would be two scenarios though requiring to denote your own key: signing messages (which is an operation involving your own private key) and adding yourself as another recipient, consider encrypting mails also stored as encrypted copy in your sent mails folder. You wouldn't be able to read your own messages any more, if the only encryption key is the recipient's one. There is the --encrypt-to  option in GnuPG, which allows you to define additional keys to encrypt for.


Extract smartcard certificate for server to server authentication I want to get data from a server that accept only client authentication via smartcard and save them to my server. Since they are a lot of data, I want to create a connection between my server and this third party server, but I need the user's certificate in the smart card.
It's impossible for me extract the private key from the smart card, of course, so I don't know if this is possible or not.

I enabled on my Apache server the client authentication in this way:

  SSLVerifyClient require
  SSLVerifyDepth 4
  SSLProtocol +TLSv1.1 +TLSv1.2
  SSLOptions +ExportCertData +StdEnvVars
  SSLCACertificateFile /usr/share/ca-certificates/ca-bundle.crt

After the user insert the PIN, with my PHP script I can get the certificate in this way:

$_SERVER["SSL_CLIENT_CERT"];

Finally I try to use this certificate to sign the request via php cURL this way:

$curl = curl_init();

curl_setopt_array($curl, array(
  CURLOPT_URL => "https://ext.processotelematico.giustizia.it/pda/pycons/GLMV/JPW_SICID",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_ENCODING => "",
  CURLOPT_MAXREDIRS => 10,
  CURLOPT_TIMEOUT => 30,
  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
  CURLOPT_CUSTOMREQUEST => "POST",
  CURLOPT_SSL_VERIFYPEER => true,
  CURLOPT_SSLCERT => $certificate,
  CURLOPT_POSTFIELDS => "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>\r\n  <soapenv:Header>\r\n    <ws:InvocationDomain name=\"JPW\" role=\"AVV\" group=\"9876\" soapenv:mustUnderstand=\"1\" soapenv:actor=\"http://schemas.xmlsoap.org/soap/actor/next\" xmlns:ws=\"http://www.netserv.it/anag/security\" />\r\n  </soapenv:Header>\r\n  <soapenv:Body>\r\n    <sicc:execute xmlns:sicc=\"urn:CONS-ANONIMA-SICC-BE\">\r\n      <sicc:name>RicercaRuoloGenerale</sicc:name>\r\n      <sicc:valueSet>\r\n        <sicc:value name='idUfficio' type='string'>9876</sicc:value>\r\n        <sicc:value name='numero' type='integer'>1</sicc:value>\r\n        <sicc:value name='anno' type='string'>2017</sicc:value>\r\n      </sicc:valueSet>\r\n      <sicc:orderBy>\r\n        <sicc:entry mode='asc' property='IDFASCICOLO' />\r\n      </sicc:orderBy>\r\n    </sicc:execute>\r\n  </soapenv:Body>\r\n</soapenv:Envelope>",
  CURLOPT_HTTPHEADER => array(
    "cache-control: no-cache",
    "content-type: text/xml",
    "x-wasp-user: user-id"
  ),
));

$response = curl_exec($curl);
$err = curl_error($curl);

curl_close($curl);

if ($err) {
  echo "cURL Error #:" . $err;
} else {
  echo $response;
}

But I receive this error: "unable to set private key file: ".
So, I suppose I have only the public part of the certificate. There is something I can do to login remotely? Or it is impossible? I know I should use client-side code, like Java Applet, but, like said, there are a lot of data and I want to avoid to download them on client and upload again on my server.

UPDATE:
Just to make clear the use case:

The second server is a government server. The ministry provides citizens' data after the login. I cannot change nothing on this server, obviously.
The government releases the smartcards for authentication, via Trusted Certificate Authorities. I have on my server the CA certificates, so the CA are not an issue (I suppose)
My web app should download, manage and represent the citizen's data in a better way than the original server

It's impossible for me extract the private key from the smart card, of course, so I don't know if this is possible or not.

It is not possible, because the private key cannot be extracted from the smartcard.

  So, I suppose I have only the public part of the certificate.

Yes that is exactly that. The certificate transmitted to the server by the SSL/TLS protocol does not contain the private key.

  There is something I can do to login remotely?

The common way is that the first server signs the request with its own certificate (that will be controlled on second server) and passes the client certificate in a custom header. You build a trust chain that way:

client authenticates to first server with its certificate signed by a CA - first server trusts the CA and through it trusts the client certificate
first server authenticates to second server with a server certificate. The second server trusts the certificate and then trusts the client certificate passed in the request

After the edit, what you describe is a serious MITM attack: you want to manage the data exchanged on a secure connection. If you could do want you want, your server would be able to submit any request on behalf of the user, while the request would be authenticated with the user certificate said differently a strong authentication including non repudiation. That is exactly what smartcard certificates prevent! The best you can do is to contact the ministry to explain that you would like to provide a service above this data, and asking what they propose. If they agree they will be able to adapt the authentication system to allow value added providers, if they do not, I'm afraid that your project will not be possible. And even with client side code, you should considere the legal consequences.


How can I secure my server to ensure pre-login calls are originating from my app? I have a .NET Web Api servicing a Cordova based mobile app and web front end written in AngularJS. I have done a ton of research and most sources don't give a great answer or one that's huge overkill for my situation. Security is not a huge concern but I want to employ some amount of basic security to ensure that only my app is making calls to my server.

All users are required to login through Facebook and do not have their own passwords for my app. My thought was, as long as they are auth'd through Facebook and the request is originating from my app, then they are good to go.

The question is, how do I ensure the request is coming from my app? During logon, I issue bearer tokens so that part is fine but what about calls that don't require authorization? The primary issue that comes to mind is submit feedback and survey forms, would hate someone jacking with those records. The best option I've come across seems to be create an encrypted token of the call parameters plus an app_secret, and attach to the request. Issues with that are couldn't someone recreate that? And since the front end is in Javascript they could find the app_secret.

1) How can I secure server to ensure pre-login calls are originating from my app?

In general, you can't. If you want to execute code on a user's machine, nothing whatsoever stops that user from manually doing the very same stuff themselves. You cannot effectively keep something secret from a motivated user and simultaneously run it on their computer; any secret in the app's code is accessible to the user. The solution is that you can't trust user-supplied input; if it's critical people not be able to submit feedback forms under fake names, for instance, you should have a user-specific secret that isn't built into the app (so that a user doesn't know other users' secrets, e.g. a user token) and use that to ensure people are who they say they are.


Is it dangerous to use hamachi for sharing game servers I'm sure most of you are aware of a game called Minecraft. Well a lot of people like to host servers, however many are unable to port forward or pay for hosting so they download and use a piece of software called Hamachi.

It seems to allow them to form a connection group that acts as if they are all on the same router when they are not. This is becoming a widely used and I was wondering if there is a risk to it.

Because its young children who are using this, they are most likely to be a risk of being tricked.. I'm curious to the damage that could be done and to who.. Would only the host be affected or will others in the group as well.

I'm going out on a limb here and going to say you are talking about: http://en.wikipedia.org/wiki/Hamachi_(software)

Since its a publicly available VPN, connecting to a Hamachi network is a lot like connecting you your own LAN; except for the fact that EVERYONE on the Hamachi network you are connected to is unknown and can pose a very real threat to anyone on the network. Since you are essentially providing a door into your own network without some of the more external safety precautions, I wouldn't be surprised if there were some unscrupulous people taking advantage of it.

Be careful!


How does Windows use the TPM for BitLocker encryption without an attacker being able to do the same? How does Windows use the TPM for BitLocker encryption without an attacker being able to do the same?

From this FAQ, I understand that BitLocker uses the following keys to encrypt the hard-drive:

Full volume encryption key (used to encrypt raw data; encrypted by the volume master key and stored on-disk)
Volume master key (encrypted by a key protector and stored on-disk)
Key protector (TPM or numerical password)

The following output from manage-bde (with hidden data) shows that the system uses both TPM and numerical password (recovery password) as key protectors:

    C:\WINDOWS\system32>manage-bde -protectors -get C:
    BitLocker Drive Encryption: Configuration Tool version 10.0.16299
    Copyright (C) 2013 Microsoft Corporation. All rights reserved.

    Volume C: [Windows]
    All Key Protectors

    Numerical Password:
      ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
      Password:
        XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX

    TPM:
      ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
      PCR Validation Profile:
        0, 2, 4, 11

In this case, what key protector is used to encrypt the volume master key?

Also, what prevents an attacker from either using the TPM as Windows would do it, or to read the recovery password from disk (the latter protector must exist in cleartext)?

The volume master key is encrypted by one or more key protectors. You have a range of key protectors to choose from depending on the machine's configuration and hardware, each can be used to unlock the volume master key independently.

In your configuration above you have two encrypted copies of the volume master key - a TPM key protector, as well as a Numerical Password key protector - a 48-bit recovery password which itself decrypts the volume master key.

  Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key. The volume master key is in turn encrypted by one of several possible methods depending on your authentication (that is, key protectors or TPM) and recovery scenarios.

  The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted drive, along with the encrypted volume master key.

  This storage process ensures that the volume master key is never stored unencrypted and is protected unless you disable BitLocker. The keys are also saved to two additional locations on the drive for redundancy. The keys can be read and processed by the boot manager.

BitLocker Key Management FAQ

When you access a disk protected by BitLocker, such as when starting the computer for the OS volume, BitLocker requests access to the key protector.

For a recovery password key protector, you are required to type it in to the pre-boot environment.

The TPM Key Protector is a special key protector that (a) stores the encryption key inside tamper-resistant non-exportable memory in the chip, and (b) uses the capabilities of the security processor to perform validation of the machine's current configuration before releasing the key from its encrypted memory to the Operating System.

When BitLocker with a TPM key protector is initialised, a validation profile is created in the TPM chip of the machine which includes the readings of a number of Platform Configuration Registers (PCRs). Each PCR represents the state or value of a number of boot-critical components and services. This validation profile is the 'known good' state of the machine.

Each time the machine is booted, the TPM measures these PCRs again. Provided the PCRs match the known-good profile, the TPM releases the key to the Operating System enabling the automatic unlock of the disk and the remainder of the boot process. Additionally, a PIN may need to be inputted to provide additional authentication to the TPM of the user (highly recommended).

If the value of any of these have changed (e.g. the Master Boot Record (MBR) code has been modified by an attacker to display or release the encryption key in the clear), the PCR will have changed when assessed by the TPM during boot, the system is not deemed to be secure and the TPM will not release the key. In this case another key protector is tried - which is often prompting the user to input the recovery password.

Whilst Windows provides a secure by design default configuration, you can change the PCRs that are assessed and read more about the functions of each PCR in the relevant Group Policy settings for BitLocker PCRs:

Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives\Configure TPM platform validation profile (...)

This is fundamentally what stops a malicious user from accessing the volume master key via the TPM.

Further reading: How does the TPM perform integrity measurements on a system?


Way for two parties to establish that they are not previously known to each other (Sorry if this isn't in the right SE / is not relevant for security.stackexchange - seemed like the best choice)

Is there a way for two anonymous parties to establish that they are not previously known to each other, before revealing their identities?

Suppose that Alice and Bob are able to communicate anonymously and wish to engage in some sort of embarrassing activity together at a later date. They do not mind revealing their identity if the other party is someone they do not know, but they do not want to reveal their desire to participate in this activity to someone they do know. They want a way to confirm that neither of them knows the other without having to reveal their identity in the process (but they will inevitably reveal their identity if they go ahead with whatever activity they're planning).

So far my only idea is to involve a trusted third party that receives a list of names from both parties (including their own names), and checks for matches. The third party only confirms the presence or absence of a match. It might be possible for each party to only submit a list of hashes instead of identifiable names to reduce the risk of the third party revealing identities, if certain naming and hashing standards could be agreed by Alice and Bob.

This way if there is a match, Alice and Bob only know that the other is someone from their list. This is not ideal, though, as either party could manipulate the process by providing limited or targeted names to enable them to guess the other's identity.

Are there any more elegant approaches to this situation?

If you're assuming that either Alice or Bob could be malicious and would actively try to subvert the process (e.g. by lying about their identity or their list of "known identities") then it would seem likely that you would need a trusted third party involved.

I'd suggest that the way to go is to have the TTP involved from the start.  So if we assume that at the start of using the service Alice and Bob have no-one in their lists then the TTP can intermediate each transaction and be the custodian of the lists of who knows who (either using direct identities or using some form of pseudoname)

A challenge is what's to stop Alice or Bob from submitting another identity and then starting from scratch so to speak.  That would be harder to overcome without the TTP taking up some kind of relatively immutable identity check, to make it harder to have multiple accounts.


Reference "non-secured" web application? I'm new to both web development and security, and I was wondering whether there is some kind of reference web application that doesn't follow any of the security best practices. Something like a "Security hello world" :).

On OWASP's site there are code examples for almost every threat, I was wondering whether there is an application that would put them all together.

I would like to use it to both test my knowledge while trying to find the flaws, and to run and understand ESAPI with it.

Meanwhile a colleague of mine pointed me to OWASP's complete (and up-to-date) list of deliberately vulnerable web applications. There's so many of them, I really have to work on my googling aptitudes...

WebGoat
Multidillae
Samurai Dojo
Google Gruyere
Damn Vulnerable Web Application (DVWA)
Hack Yourself First


Strange HTTP GET Requests My server has a static IP and listens to a port (8000) when it get's a file it automatically saves it with predefined extension. It's an internal project and no one knows about this server. I see few HTTP1.0/1.1 requests a day. should I be worried? They're origin is in Russia, Viet Nam and may be more.

It's an internal project and no one knows about this server.

Just because you did not tell anybody does not mean that nobody knows about it. Any host exposed to the internet is usually often checked for the kind of services if provides. Also the usual exploits are tried in the hope to find an easy target to take over and misuse, i.e. sending spam, delivering malware, attacking other systems within a DDoS attack, cryptomining, etc.

  ... should I be worried?

If your server is not secure you should be worried. It is better to keep the attack surface small, for example by requiring authentication, limiting access to specific IP addresses or whatever is possible in your specific use case.


Benefits of a wildcard vs per-subdomain certificates As you might know, Let's Encrypt doesn't offer wildcard certificates and it won't in a short-term because you can just order as many certificates as you want for the sub-domains.

This make me wonder... assuming money is not a problem so that I can request all the certificates I want (I know about the rate limits though), is there any advantage of using a wildcard certificate over requesting a certificate per subdomain?

For websites which dynamically generate subdomains (for example, if users can create their own subdomain for some service), installing a certificate for each new subdomain is far from ideal, because you need to verify the ownership of the domain for each subdomain, followed by the installing of the certificate for each subdomain (which typically also requires a reboot of the web server).

In addition to activating new subdomains, managing many certificates (each with its own expiration date) quickly becomes a major hassle. All in all, this constitutes an increased complexity at the cost of no extra security.

So, in summary, the advantage of a wildcard certificate is in the lower administrative burden.


Is it safe to store a file in a temporary folder before it has been scanned for a virus? I'm working on an application that makes use of the Symantec Protection Engine to scan uploaded files.  I'm having issues with my files after they have been scanned.  One possible solution I've seen is to store the uploaded file in a temporary folder, then stream it to the protection engine.  If the engine determines the file is clean, I would then access the file from the temporary folder and pass it on to it's final home.  If the file is dirty, delete the temporary folder and let the user know what the problem is.

So the question is, would storing the possibly infected files in a temporary folder open the system up to infections?

There's nothing inherently dangerous about a virus stored on a hard drive.  To infect something viruses have to be executed in some manner.  That means either directly being executed by the user, or exploiting some vulnerability in an application that opens the file.

Deleting the file if the engine says it's infected is also problematic.  No anti-virus engine is perfectly accurate, and false positives happen all the time.  This is why the general practice is to put infected files into a quarantine so they can be inspected manually later.  That may or may not be appropriate for you based on your use case, but you do need to keep in mind that false positives happen all the time, and are normally more likely than viruses.


How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android) There are built-in functionalities to encrypt a storage on OS X (FileVault) and Android.

On OS X: to enable encryption current user must have a password protected account. After enabling the encryption, recovery key is generated (something like HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). After the encryption is finished (and in all probability before that as well) user is able to change his password, without the need to re-encrypt the storage.

On Android: user is required to set lockscreen protection to either pin or password. After storage encryption is done (again, probably before that as well), user is able to change password, and even switch from password to pin and vice versa.

Now here is what puzzles me: my understanding is that when storage is encrypted, it is done with current user password (sort of like encrypting an archive) and if password is changed — the whole storage must be re-encrypted. This (apparently incorrect) understanding brings me to following questions:

Based on what "key" (since it is not the password itself) encryption is done then?

For OS X, I am guessing, it's the recovery key, but how is it connected to the user's password then?

If password is not the basis for encryption, why is it required to set one before encrypting your storage?
How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?

At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.

When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.

Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.

Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.


How can antivirus companies analyze the large amount of samples that they receive? Antivirus companies collect samples from their products or the users can directly submit the samples through forms on their websites. The number of collected samples is very big. How can a group of analysts analyze such a big volume of malwares?

I read several papers made by researchers that describe different techniques. One technique is to cluster similar malwares together and analyze only one 'representative' for each cluster.

What are the methods really used by the AV companies?

Ok, I've found the answer. AV companies use clustering/classification techniques in their propietary analysis tools. These are some examples:

Kaspersky uses Astraea [1]: a machine-learning based malware analysis system. Astraea automatically analyzes notifications from protected computers and helps uncover previously unknown threats. By using the threats’ metadata (like age, origin, filename, file path and more) the system is able to fully detect threats without information about the file contents (only static features?).

Comodo uses Valkyrie [2]: it's a cloud based file analysis platform providing static, dynamic and even human expert analysis for submitted known and unknown files. Valkyrie processes over 200 million unknown file submissions each day. Some of the Machine Learning techniques Valkyrie employs include support vector machines, naive bayes, decision trees and random forest classifiers. Additionally, Valkyrie will employ linear discriminant analysis, stochastic gradient descents, hidden markov models and neural networks, just to name a few.

Avast uses Medusa [3]: a GPU-powered classification system. Every Medusa node uses two or four Nvidia GPUs. Each sample is represented by a constant-sized feature vector consisting of approximately 100 attributes. Taking into account the nature of the attributes, they ended up with several distance operators and a weighting scheme that equalizes the importance of the attributes. They use a kNN classifier. Their internal systems handle around 250,000 new PE files every day. They claimed to use complete linkage, this means their algorithm to find the clusters could be the agglomerative hierarchical algorithm.

Avira’s Cloud Protection [4]: Avira uses big data analysis to automatically determine if a newly discovered sample belongs to a known family of malware. At any given minute, they are processing 1.3 Million malware updates on their servers worldwide. In one day alone, their Avira Protection Lab honeypots will receive more than 130,000 new malware samples to analyze.

Microsoft Azure Machine Learning [5]: They use probabilistic machine learning to find patterns in the data that may have been undetected by the more blunt deterministic technique. The algorithm runs without human intervention and produces a map of sorts. The map shows populous clusters, less populous clusters, and perhaps a few outliers or very sparsely populated clusters. At this point, a human expert is called in to look at the clusters and decide if a cluster is a normal process or malware.

BitDefender [6]: uses several machine learning techniques (Perceptrons, Neural Networks, Centroids, Binary Decision Tree, Deep Learning, etc.) for several tasks: filtering URLs, identifying malicious files and to classify emails.

Symantec uses Cynic [7]

References (I haven't enough reputation to put them as links):

[1] usa.kaspersky.com/about-us/press-center/press-releases/2016/Kaspersky_Lab_Number_of_the_Year_2016_323000_Pieces_of_Malware_Detected_Daily

[2] enterprise.comodo.com/valkyrie/

[3] avast.com/technology

[4] blog.avira.com/virus-hunters-catch-bad-guys-part-2/

[5] microsoft.com/itshowcase/Article/Content/618/Improving-network-security-using-big-data-and-machine-learning

[6] businessinsights.bitdefender.com/machine-learning-apt-detection

[7] symantec.com/connect/blogs/myth-busting-next-generation-threat-protection


What is this for a Request? i see the following request-string (see complete example below) with the same request_parameters, but differing values, hitting all our sites/wafs. the scheme is always the same:

&amp;sa=...&ei=..&ved=..&usg=...

UAs are varying from Libwww-perl to (probably faked) legit ones.

sometimes an url-based exploit-attempt is found after this string, targetting timthump and joomla - vulns (none of these apps are existing on our systems)

these strings are appended to:

urls like /contact/
static-files
existing request-parameters

sample:

&amp;sa=U&amp;ei=w0QtUoiKC4jukQWZjYGQDg&amp;ved=0CMcBEBYwOTiQAw&amp;usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

It's hard to judge the source or the purpose of these requests based on information you provide, but one thing is rather clear: somebody was translating request URLs with the wrong function, using HTML encoding in place of what it should have been URL encoding of the query part of the requested URLs.

For example, the sample you provide should read as:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

If this was meant to be passed to another URL as a single variable, it would have to be translated using URL encoding, and it would look like this:

%26sa%3DU%26ei%3Dw0QtUoiKC4jukQWZjYGQDg%26ved%3D0CMcBEBYwOTiQAw%26usg%3DAFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg%2F

As it was translated with HTML encoding instead, the & ampersand character (for example, there are other problems with it) denoting new URL parameter value will repeat in the HTML encoded string at wrong places, your web server has no way of knowing which parts are the URL query name and value parts in the format: &field=value once it URL decodes the requested resource location.

This, I imagine, translates in all kinds of illegal requests listed in your web server's access logs. I would advice simply blocking all such requests in your web server configuration, as there is no way they can be served proper response anyway. How you'll do that though, is entirely up to you and your needs. I personally deny access to any User Agent (UA) strings that I deem having no business accessing my server, including default UAs of many web framework libraries, among which the one you mention: Libwww-perl.

I'm on Apache, and using PerishablePress' 2010 User-Agent Blacklist for these tasks (among other custom blocks in web server config and other means of controlling access, of course). It's in my opinion a convenient enough collection of blacklisted UAs, and while there are newer ones published even on this same blog, I find the one from 2010 to work the best for my needs. Anyway, I thought you might find it useful, too. ;)


Why should I separately backup my revoke certificate So I understand the principles behind the concept of a revocation certificate and why it should be useful to create one and back up before harm occurs. The thing is, I don't see a wide range of media (or any at all) on which it makes sense to do this in practical life.

Here's what I'm taking into consideration:

Having your revoke certificate compromised is an annoyance.
Losing your revoke certificate is potentially a major problem.
Having your private master key compromised is potentially a major problem.
Losing your private master key is an annoyance.
You can reproduce a revoke certificate if you're in possession of the master secret key
If you have your master private key entirely offline: you'll actually gonna need it more often than your revoke certificate.

With that in mind, every time I picked a media or a way to store my revocation certificate, I thought "hell, I might as well backup my entire private key set on this [because I deem this media safe enough]". At the end of the day, I backed up only private keysets.

To me a media that would indeed fit the bill for storing your revoke cert only would be very (very) reliable, at the expense of (some) security, and ease of access.

Do you see any such media, or are any of my assumptions wrong? Why and where do you store your revoke certif on its own? I'm thinking maybe some kind of on the cloud storage which I wouldn't dare with my master keyset, but I don't know if I'd find it safe enough even for a simple revoke certif, without getting too complex (given I can't of course encrypt it with my GPG key).

You can backup your revocation certificate to a more reliable, but less secure place (friends, relatives); losing it is just an annoyance. You probably wouldn't do that with your private keys, losing them is a catastrophe (or major problem, as you described it).

Just storing to multiple devices does not seem reasonable. Maybe this argumentation is usually a little bit constructed, but who knows? Police might seize all your devices, a GnuPG library bug might affect all stored keys at the same time, ...

As there are few disadvantages and low cost for doing so, there isn't really a reason against.

  Do you see any such media, or are any of my assumptions wrong? Why and where do you store your revoke certif on its own?

I store my revocation certificate (apart from a digital version, which is backed up digitally) on a piece of paper: qrencode is a great thing, just don't forget to add a note what this is and how it was created. And verify you can read it, I was having problems using some readers. A revocation certificate fits rather well on a DIN A4/letter format piece of paper, and could even still be read using smartphones.


Should I delete locally synced data if the user can't log in? I'm building a Mac app that syncs the user's documents down from a third-party cloud service. When you set it up, it will sync all your documents down to the local hard disc, at which point you can access it in Finder.

For the purpose of this question, you can imagine I'm building a third-party Dropbox client. I'm not, but it's a good enough approximation for this question. The key points are that I don't control the cloud service, and that the data is accessed through Finder once synced down.

Suppose, at a later point, the server rejects the OAuth token / saved password, and the user is unable to supply a password that works. After a certain number of attempts or a certain amount of time passing, should I delete all the synced documents to prevent misuse?

Scenario 1: An attacker guesses a user's password, and uses that to log in to the cloud service through my app and accesses the user's documents. The user comes to know and changes his password/revokes auth tokens. At this point, the user would want his documents to be deleted from the attacker's hard disc. Or if the user sells / gives away / lends his laptop to someone, forgetting to log out in my app, and he realises it later and changes his password/revokes auth tokens, he would again want the already synced documents to be deleted from the laptop's hard disc.

Scenario 2: A hacker takes over the account and locks the user out. Or the cloud provider makes a mistake and locks the user out of his account. Then the user would want a backup of his data on his local hard disc, as opposed to losing access to his precious data.

If I delete all existing synced documents, I've failed the user in scenario 2. If I don't delete all synced data, I've failed the user in scenario 1.

Is there a best practice for this? A general guideline on what clients to cloud services should do if the user can no longer log in?

Note that I can't keep the data on the Mac's hard disc but deny access, since the user accesses the data through Finder, not through my app. The choices are to delete or not delete the data.

Scenario 1 will only work if the attacker is stupid. If a guy manages to steal the password of somebody and sync a cloud folder on his machine, the next thing he should do would be to save the content of the stolen data elsewhere just to make sure that a sync problem could not change it.

In that case erasing the synced folder will just have no  effect...


PHP Session Vulnerability I'm trying to solve a challenge on a CTF, with PHP sessions.
The goal is to make check.php echo $_PASSWORD.

I do not have access to the files themselves, and therefore I cannot edit them.

My proposed solution is:

We want the session to be locked for 20 seconds, therefore we need to make eat.php run that much time.
At the same time, we need to run check.php, having it set $time and then wait for the session to be unlocked.
Now we need to unlock the session, which means we need to stop eat.php.
check.php will continue running, the following expression: $time+20!=$_SESSION['time'] will be false, and PHP will echo $_PASSWORD.

Is my proposal possible? If it is, how would you implement it?
I'd also like to hear about other directions for solving this problem.

get.php:

<?php
setcookie('id',uniqid());
?>

eat.php:

<?php
$cookie=$_POST['cookie'];
session_save_path('/home/mawekl/timetravel/');
session_start();
echo 'You ate: '.htmlspecialchars($cookie);
echo "\n<br>";
$_SESSION['cookie']=$cookie;
$_SESSION['time']=time();
?>

check.php:

<?php
$cookie=$_COOKIE['id'];
$time=time();
session_save_path('/home/mawekl/timetravel/');
session_start();
if ($cookie!=$_SESSION['cookie'])
    die('Wrong cookie');
if ($time+20!=$_SESSION['time'])
    die('You must eat cookie after 20 seconds from now, but you ate it '.($time-$_SESSION['time']).' seconds ago');
echo $_PASSWORD;
?>

I might be wrong of course, since I don't know the solution, but here's my analysis.

get.php can be completely ignored, as you can make up a random id cookie value.

We might not have all the necessary information. Does the server run Apache or something else? Which PHP version was used? Is there a description for the challenge (they often contain obscure hints)?

As it stands, I see only two realistic ways of approaching this that: injecting data into that $_SESSION['time'] variable, or making check.php pause after $time=time(); and before $time+20!=$_SESSION['time'].

Looking for injection vulnerabilities in PHP, I only found CVE-2006-3016 (PHP 5.1) but it contains very few details and they'd have to run a very old PHP version anyway. Last year someone also reported a session injection vulnerability, but it seems not to be applicable. This avenue does not seem very feasible.

This leaves the pausing trick. I was thinking of something like this:

Open a lot of connections and let them request eat.php with large $_POST['cookie'] values to make it take a lot of time to write all the sessions.
Request check.php, which will hang until step 1 is complete. Vary the amount of requests done in step 1 until it takes exactly 20 seconds.

This would require the server to do multithreading, since it needs to leave check.php in a sleeping state and perform a bunch of eat.php requests in the background.

The issue with this is that each eat.php needs to write to the same session, or it wouldn't block at all in check.php (since there would be no thread locking the session that check.php tries to read). But if each successive eat.php completion updates the $_SESSION['time'] value to something more recent, it is not going to have an old time value. So this does not work either. (It could perhaps work if PHP blocks on any session still being written to, then another session could be updated in eat.php and still leave check.php hanging, but this seems unlikely so I haven't explored the possibility.)

In short, we need more information and perhaps even access to a challenge environment. From my perspective, it seems impossible without another vulnerability (e.g. sending false NTP updates).

To answer your question

Yes, your proposed solution would probably work. Just one issue: how would you actually manage to make it do this? ;)


Cryptography in simple words anout one idea? I'm a student and have one challenge about cryptography. I need clear definition or simple definition to better understand cryptography and related security. I’ve been reading lots of material, seeing videos, but I think the encryption domain is too confusing and complex for me to grasp. So, I’m hoping there are simple answers to my questions.

Suppose I create SQL Server database (Angular and NodeJS as my front and back) and store all data with encryption so that the server holds all this data and no other person can use this stored information.

How I can use an encryption model so that this encrypted data  (user/pass/token) can be seen by an admin, but not seen (encrypted) by others?
If this data (user/pass/token) is “stolen”, will others be able to also see my encrypted data like an admin would? If, how can I prevent that from an information security point of view?

This is a very broad question. How the cryptography operates depends completely depends on the type of encryption used (a specially secure DB, a DB file encrypted, encryption using special SQL constructs or application based encryption. etc.). Then it also depends on the key system used, public key or secret key encryption and how the key management and access conditions are setup.

If you take a birds eye view then encryption doesn't make sense: to decrypt (and, for symmetric ciphers, also to encrypt) you need access to a secret key. So instead of securing your data you now have to secure a key. This key may however be generated in advance and is much smaller than the data. But more importantly it may have a different protection and may be restricted in access.

The more protected and least accessible the key is the more secure it is. This comes at a price of course. Say you'd use a passphrase or a private key on a special device. In that case you need to supply the key during booting of the DB, and you may need to provide continuous access to it without breaking the security measures.

So onto your questions:

  How I can use an encryption model so that this encrypted data (user/pass/token) can be seen by an admin, but not seen (encrypted) by others?

By encrypting the data in such a way that it only can be decrypted by a private or secret key held by the admin. Sometimes a data key is e.g. encrypted with the key of the admin, and that data key is in turn used to encrypt the data in the database (so you get a hierarchical structure where the security of one key depends on another, higher level key).

  I'm not sure I understand. Where is the encryption key being stored, and how is access gained to it? What is the encrypted data and its relation to user/pass/token?

Where the key is stored depends on the system. Hopefully it is stored in some kind of secure store, e.g. protected by the operating system. But it may also be a static key in the application code or stored in a configuration file.

Banks and such tend to store the most sensitive keys in HSM's (if the keys need to be directly accessible) or off-line (on an offline storage device that can be used by a hardened laptop). On smart cards and HSM's the keys can only be used, not retrieved (exported) except for back up purposes. Using the keys generally requires the user or system to authenticate to the storage device.

But books have been written about key management, and in the end you may need to read a few to fully understand how to handle keys.


Does routing internet traffic via VPN through a company proxy gain any more security? There is currently an ongoing discussion in our company about what security measures to put in place regarding workstation access to the company network and the internet.

Situation:

Employees have Linux laptops with encrypted SSDs
on these SSDs is the intellectual property of the company
Employees have unrestricted root access to these machines
AntiVirus is installed and running

Goal:

Have protection against theft of the intellectual property of the company while still being able to work from anywhere in the world

Current idea:

Use VPN to tunnel all network traffic (including internet traffic) through the company
Do not allow direct internet access via VPN but rather enforce that a proxy server has to be used.

Question:

Does the additional proxy server for internet access provide more security than it (potentially) costs in the effort? (additional client configuration effort programs and services, ...)

Laptop <-> VPN <-> Proxy <-> Internet   vs. Laptop <-> VPN <-> Internet

Brainstorming:

If the laptop is compromised (backdoor running). How does VPN protect the data anyway if the user has root access and can change network configuration (routes, iptables, ...) as he pleases. What additional security does a company proxy give?

Does the additional proxy server for internet access provide more security than it (potentially) costs in effort ?

If the proxy is just a dumb proxy then there is no additional protection. But usually the company proxy is actually a system which analyzes the traffic for malware or data leakage, blocks potentially malicious sites and might even do HTTPS interception to analyze encrypted traffic. In this case the proxy offers more protection than direct unfiltered internet access from the Laptop.

  ... If the laptop is compromised (backdoor running)....

That's not the main point of the proxy. The proxy is there to make infections harder in the first place. And it might also be used to detect and block typical C&C communication done by malware.

  ...  if the user has root access and can change network configuration ...

If the user is granted full access to the configuration of the system there is nothing technical the company can do to stop the user from deliberately violating the company policy of using the proxy. But the company can easily check who uses the proxy by looking at the proxies logs and charge users who don't use the proxy with violating the policy.


Yubikey PGP migration I am currently using a Yubikey 4 with my PGP subkeys on it.
My mainkey is stored within Kleopatra.

As I am planning to move over to a new Yubikey 5 I have asked myself if it is possible to still be able to decrypt emails with my new pair of subkeys generated for the new Yubikey?

The important question is how you generated your PGP key and subkeys.

As explained in the docs there are two ways:

Generating Keys externally from the YubiKey (Recommended)
Generating Your PGP Key directly on Your YubiKey

The first approach is recommended. You can use a live distro such as Tails to generate your keys on an airgapped (without networking) computer. Then you make backups of your keys to removable storage like a USB key or a hard drive, that you keep in a secure place.

The other option is to generate the keys directly on the device. This is very secure but the major drawback is that you cannot backup the keys. If you lose or destroy the device you lose your keys. With this approach, migration is not possible. This option should be avoided unless you know that your key is going to have a limited shelf life.

So if you chose option #1, it is quite easy. You don't need the old YubiKey. Start your live distro, reimport your private keys from the external storage, and you write them to the new YubiKey with the keytocard command.

To answer the question: in order to retain access to your mails you must keep the current key (and subkeys). But the hardware itself does not have to stay the same, it could be another YubiKey or a smart card as long as you have that external backup.

If you really must change your PGP key: in theory you could decrypt files and reencrypt them with a new key,  But with E-mails this is complicated. They are probably stored in a mbox or pst file. Even if they are available as standalone files (on an IMAP server for instance), it's not the whole file that is encrypted but the mail body. The headers are still in clear. AFAIK PGP cannot just decrypt the encrypted part while keeping the rest of the file intact. There is no easy solution I'm afraid.

However, I did a test with Thunderbird. I chose an encrypted message, selected the whole message source (Ctrl-U) and copied it to a file. Then using gpg -d <the file> from the command line I was able to read the mail after entering the passphrase. But you don't have the headers and all that. What you get is a stripped-down version. It's not something that you could reinject to the mbox file for instance.


Safely remove original file after encryption My application encrypts a file, and the result is written to a different one. How do I safely remove the original one (C++)?

Update. Wow! The problem is more complicated than I thought of it...

1) My application's purpose is to encrypt files from user's hard drive. I may not require all the data to be piped, as I actually do not know which source it can come from. ANY files - not just browser's downloads or result of any kind of processing. So, piping is not for my case.

2) When I was writing my question, my main concern was whether shredding (or overwriting, as I called it before) does destroy the data or not. Now I see I was right, and the data is far from being sure to be destroyed.

3) Does shredding really damages hard drives?

So, does shredding still remain the best choice in my case or not?

The most secure way to do this is to not have the unencrypted file on persistent storage in the first place. Pipe the unencrypted data directly to your encryption program directly from whatever program that generated/downloaded the data.

You'll also need to take care that you use the OS API to mark your memory area as non-swappable (e.g. with mlock on Linux). This ensures that the program wouldn't be paged out to disk by the virtual memory manager. Depending on your requirements, you may also need to take care to discard any sensitive data before the computer goes into suspend or hibernation.

Note that shredding a file may not actually overwrite the unencrypted data on some storage devices like SSD due to write balancing.


Is there data on the most common password strength requirements? Many websites have different requirements for a strong password (beyond simple length I mean). Anecdotally, I think these requirements are common:

Password must contain a mix of upper and lower case letters
Password must contain at least one number
Password must contain a special character like ()*&^%$£"- etc.
Password must be longer than 8 characters

I'm wondering what the most common requirements set by everyday websites are. Obviously this is impossible to answer definitively given the number of websites on the internet, but I'm wondering whether anyone has collected some amount of data gathering the modal password strength requirements? I was not able to find this from Googling.

... but I'm wondering whether anyone has collected some amount of data gathering the modal password strength requirements?

A Second Look at Password Composition Policies
in the Wild: Comparing Samples
from 2010 and 2016 from Usenix 2017 has collected password policies and strength requirements from many web sites. In this paper you'll find also links to related papers.


HTTPoxy - What about HTTPS_PROXY when dealing with HTTPoxy vulnerability? fastcgi_param HTTP_PROXY ""; is the soluntion, but why didn't they also mention HTTPS_PROXY? I have a HTTPS website, not HTTP.

Should I also add fastcgi_param HTTPS_PROXY ""; or not?

Stop changing the title.

Even if the context is missing I think you are referring to the httpoxy vulnerability where it is possible for an remote attacker to set the HTTP_PROXY environment variable using a HTTP Proxy header. The base of this vulnerability is that in a CGI environment the HTTP_xxx environment variable is set if the HTTP header xxx exists. Since this only affects HTTP_* variables and not HTTPS_* variables it does not affect HTTPS_PROXY.

Apart from that both HTTP_PROXY and HTTPS_PROXY are only relevant for requests done by the CGI script and is not related to how your site gets accessed.


How secure is using CRAM-MD5 for email authentication, when not using an SSL connection? Background: My current server-provider tells me it's no problem to store the passwords in plain-text in the database, saying he has to do so because they use CRAM-MD5 for email authentication. My brain disagrees. But something tells me that storing passwords in a database in plain text format might not be the only security issue that comes up here and I'm not even sure if CRAM-MD5 can still be considered to be "secure" nowadays.

Whatever feedback you can give me - from an InfoSec point of view - about "using CRAM-MD5 for authentication while talking to an email server without the use of an SSL connection" will be highly appreciated. Thanks in advance.

edit : For a cryptographic point of view, check https://crypto.stackexchange.com/questions/8391/what-are-the-potential-security-impacts-of-using-cram-md5-for-emails-when-not-u

CRAM-MD5 requires that the server knows the actual password, not just some image of the password by a hash function. So if the server has to support HMAC-MD5, it has to store the password in plaintext. (The server can encrypt the password, but since it also has to know the encryption key, that doesn't help.)

CRAM-MD5 was designed to avoid having the password transit in cleartext. It gives some amount of protection against a passive attacker. If the attacker can eavesdrop on the communication but not inject messages, then all she gets is a challenge C and the value HMAC-MD5(P, C) where P is the password. There is no better method to find the password from this information by brute force. Brute force is however a concern with passwords: at least a slow function should be used, and exposing the hash should be avoided anyway and should be treated as a compromise.

Instead of a human-chosen, memorable password, the “password” (more precisely a shared secret) stored on the server could be a slow hash of the human password, as noted by Adnan. This would preclude brute-force attacks from the MD5 hash, so it would provide better security against passive attackers. (However, anybody who does this is using non-standard tools, and is presumably serious enough about security to use SSL.)
CRAM-MD5 only authenticates the authentication step and not the rest of the session. So an active attacker who is able to impersonate the client can let the authentication happen, then cut off the client (or send it modified data) and send his own commands in the session. Specifically, the attacker has to be able to receive TCP packets intended for the client. Alternatively, the attacker has to be able to receive TCP packets intended for the server, or send fake DNS responses that cause the client to talk to the attacker instead of the server; such an attacker acts as a relay between the client and the server during the authentication phase, then can keep talking to the server. None of these attacks involve a compromise of the password, by the way, other than through brute force as above.

Using CRAM-MD5 over SSL would solve this authentication problem. SSL provides a secure session (i.e. the participants can't change during the session), and authenticates the server to the client (assuming the user won't blindly accept an invalid certificate). CRAM-MD5 brings the third part of the authentication problem: authenticating the client with the server.

CRAM-MD5 over SSL is fine if the password is a long enough randomly-generated string — long enough to resist brute force. If the password is a randomly-generated one, there is no reason not to store it in plaintext on the server, it's just a key. CRAM-MD5 is bad if the password is one that a human can remember, because most human passwords can be cracked by brute force and are valuable beyond that one server as they are often reused.

If using SSL, there is little value in using CRAM-MD5 as opposed to having the client send the password over the SSL connection. There is a small advantage in that if the client inadvertently sends the password to a server impersonator, the password itself is not compromised immediately (only if cracked — though note that a server impersonator can send a constant challenge and therefore build a table (rainbow or other) of HMAC-MD5 values over plausible passwords). Where the password is a random string, this can be an advantage (the attacker can't use the value sent by client to impersonate it unless the server happens to send the same challenge as the attacker, which shouldn't happen). Where the password is a human one, there is no such advantage (as the password can be cracked anyway) and having to store the password in plaintext is a definite disadvantage.


If I protected myself from POODLE am I also protected against DROWN The POODLE vulnerability exploited a weakness in SSLv3. The newer DROWN vulnerability exploits a weakness in SSLv2. Part of my protection against POODLE (for my webserver) was to disable SSLv3 and earlier.

So am I already safe from DROWN?

POODLE is an abuse of a flaw in SSL 3.0. You are technically protected against POODLE if you disabled support for SSL 3.0.

DROWN leverages a flaw in SSL 2.0. You might be technically protected against POODLE, in the sense explained above, and still be vulnerable to DROWN.

Of course, SSL 2.0 has other flaws and it was already deprecated / forbidden; it has been so for a long time. The advice for POODLE was often worded as "deactivate everything that is older than TLS 1.0" and this includes SSL 2.0, but, honestly, SSL 2.0 should have already been deactivated, killed, and its corpse dumped at sea, long before POODLE. If you had to wait for POODLE to disable SSL 2.0, then you were already very very sloppy. There is no upper limit to sloppiness, so you are encouraged to test whether your server still accepts SSL 2.0. Just in case.


one-way hash with PhP onto MySQL database (NOT for password) My users (researchers) will be storing where their website is on a mysql database on my server.
Ideally I want to hash the locations so that when the researchers' participants submit their data to my server, I can confirm whether the website they came from is registered on my MySQL database. If so, I want to save their data to a specific location that reflects which website they were participating at.
My problem is that when I use Php's password_hash, it returns different values during each hash. Thus, to verify the location I think I would need to loop through my whole mysql database to check if the website the participant is submitting from matches one of the rows of the list of websites.
So am I right in thinking there are 2 options:

Keep using Php's password_hash, and loop as described above? I haven't found an elegant way to validate the participant's hashed version of the location to the original hash stored in the mysql database.
Use an alternative Php hashing solution that produces a stable hash each time (is there a recommended way to do this? I've seen warnings about md5 and sha)

The reason I want to do the above is that I would like to reduce the chance that a malicious user could dump the database and then use it to systematically interfere with all the websites listed.

Hashes
Your issue is that password_hash is designed for passwords and so always assigns a random salt - this is why you get a different hash everytime.  You want to use just a hash and skip the salt, which password_hash won't let you do.  You should probably just use plain ol' SHA256 which PHP can provide for you via the hash function.
A Caveat
I don't quite understand the background of what you are doing, but there is a good chance that this entire idea is a non-starter.  Here's the dangerous statement:

Ideally I want to hash the locations so ... I can confirm whether the
website they came from is registered

You should know that there is simply no way to confirm where the data came from.  Absolutely none at all.  HTTP/browsers/the internet provide absolutely no way to tell for certain what website a particular request came from, especially since you can't even guarantee that a request is even coming from a browser in the first place.
You should probably make sure you understand the full implications of the above before you go much farther.
Brute Force
You asked about the risk of someone guessing a hash.  You probably don't have to worry about that.  The hash generated by the SHA256 algorithm is (not coincidentally) a 256 bit hash.  This means that there are 1e77 possible hashes.  This makes it statistically impossible for a user to guess a hash for any reasonable number of websites.  From the description in your comments, it also seems unlikely that they would be able to bruteforce your plain text values, although that is harder to guess from here.
However, keep in mind that these values are not actually secrets.  Anyone who is on one of these sites would be able to see the hash going back and forth, and so can easily find it once they are on the actual site.  It sounds like the hash is kind of like an API key, but if it is sent/known by JavaScript running in the browser, then that means it is completely public.  Once again, make sure you understand the full implications of that and are okay with it.  In short:
If someone visits a website, takes the hash, and then starts doing [evil] with it, what is the worst that they can do?
Make sure you are okay with the answer to that question!


A practical .NET Remoting Architecture exploit If you were to demonstrate a .NET Remoting Architecture vulnerability with a practical attack, which one would you choose?

I've read J. Forshaw's white paper on Breaking .NET Through Serialization (PDF), Googled thoroughly, and now I want to implement a working exploit of a .NET Remoting service. It does not matter where the service is hosted. It can be ASP, IIS, Windows service, or whatever.

DoS attacks - Given the cross technology nature of these frameworks (they C#-VB-C...) they generally are hard to secure the connection "ports". Therefore if you can enumerate and find the connection points you can often times flood them or just keep them busy and create a DoS attack by starving the "receiving" end of the framework. It is generally not hard to do, and unless a LOT of care has been put into the architecture and secured properly, then this is a low-hanging fruit.
Resource Starvation Attacks:

a. Proxy Resource Attack - Generally given the proxy schemes schemes implemented by these frameworks, there is generally a loosely bound proxy that is needed that is not explicitly destroyed when resources are set-up and taken-down. This allows for ways that an attacker can script ways to blow up proxy resources create starvation scenarios.

b. Physical Resource Attacks - The serialization mechanisms used to inflate/deflate objects can at several points create physical resource attacks. You can create object bombs - large objects that consume resources extensively shutting down or starving the system; or in the case of recursive xml serialization you could create both processor and memory resource consumption by having xml processing that ties the system up.

Code Injection

a. Mutation - This is where you mutate original code or objects but injecting new code into them. Each language has its own ways and guards to overcome, but generally doable.

b. Collateral - This is where you mutate or inject code into secondary languages, such as inject new SQL into database interactions, or push out new Javascript in web scenarios.