user authentication by decrypting a random blob Normal user authentication is done by comparing "hash"-values. A simple example of this:

The user password is hashed with PBKDF2 on the client using a salt (the salt is the hash of the user password concatenated with his username). That result is then sent to the server where it is again hashed with some unique per-user random hash value and stored in the database with the unique salt.

Now, is it more/less secure if I associate a user account with a random BLOB of data encrypted using as key the hash of the PBKDF2 output concatenated with a unique salt?

So instead of matching a hashed password to prove who you are, you now decrypt some random BLOB to prove who you are. What are the implications? It is more computationally intense to decrypt a BLOB? Are there any security downsides?

What are the implications if the BLOB is not random, but we use the username?

Thanks for you explanation!

The most basic authentication scheme looks like this:

Client knows password.
Client shows password to server.
Server is happy.

Password hashing is done only to counter a secondary threat: that some bad guy succeeds at having a peek at the server files or database, through some illicit but common way (SQL injection attacks are usual). We don't want that bad guy to immediately learn all the user passwords. That would be inappropriate. To avoid that, the server will not store the passwords themselves, but only some values which are sufficient to verify a password. This is where hashing occurs. The server hashes the passwords, with a slow and salted hash function, so that the envisioned attacker with sharp eyes will at least have to perform some substantial work for each password he will recover.

But that hashing is entirely a server business. The client does not see it. From the point of view of the client, the protocol is just "show the password". How the server decides that the password is the correct one or not, is completely irrelevant to the client.

The basic protocol is usually sufficient because it will be played within SSL (aka HTTPS in a Web context), which ensures that the client has some a priori guarantee that it is sending the password to the right server, and nobody else can spy on it. We need something like SSL anyway, to prevent the connection from being commandeered once the authentication has been done. So we might as well use it and just show the password to the server.

Nevertheless, some other protocols have been designed, in which the raw password is not shown to the server. Motivation is either distrust of the security guarantees provided by SSL and its digital certificates, or just disregard of the risks of hostile hijacking (the protocol is played "in the clear" and it is just assumed that attackers are passive only -- a singularly optimistic stance, verging on the naivety, but it was much more common in the late 1980s and early 1990s). These are challenge-response authentication protocols. Your proposal with the "encrypted blob" is of that kind. The server sends a value to the client (the challenge) and expects the client to process it in some way which involves the password (that's your "decryption"). The server verifies that the client properly responded to the challenge.

In general, challenge-response protocols are not a good idea. They have the following drawbacks:

The main benefit of a challenge-response protocol is to avoid showing the password to a fake server. But showing the password to a fake server occurs only if the client accepts to talk to a fake server in the first place, meaning that the transport medium can be subverted and allows replay attacks and men-in-the-middle. This is bad news. The overall situation is rotten and should be fixed in a much more thorough way than using a challenge-response protocol. Wearing a lifejacket is good, not being on board the Titanic is better.
The server must have a way to verify the response to the challenge. It is very hard for the server to avoid storing something which is password-equivalent. For instance, if the challenge is "you, client, decrypt this blob !", then the server must have encrypted some data to produce the challenge blob; otherwise, how would the server know that the decryption worked ? And to do the encryption, the server must know the encryption key, i.e. the password, not a hashed version thereof. You have lost the benefits of slow and salted hashing. Keeping the server's database invisible from the attackers becomes critical again.
If the server is fake (and you are using a challenge-response protocol instead of just show-the-password precisely because you deem it possible that the server is fake), then that fake server will still learn a value which is deterministically computed from the password, i.e. something which is sufficient to mount an offline dictionary attack (the bad guy tries potential passwords at the full speed of his GPU, on his own machines). That's not good. (Speaking of which, your suggestion to use the "hash of the user password concatenated with the username" as salt is not a salt at all, because of this determinism.)
A client who responds to a challenge is a client who can compute. This does not map well to a Web context. In a Web context, client code is Javascript, and Javascript is feeble; it is not good at computationally intensive tasks.

These drawbacks can be fixed, with another tool: mathematics. Maths are great. They allow a more recent and considerably niftier class of authentication protocols, called password authenticated key exchange. These protocols allow for mutual authentication (the client also gains some guarantee that it talks to the right server; they resist offline dictionary attacks (even a fake server, or a fake client for that matter, does not learn anything which would be sufficient for that), and the best of them avoid having to store server-side some password-equivalent data. The most oft-cited PAKE protocol is SRP. SRP has the additional benefit of being integrated in SSL/TLS, which is good because even with the best authentication protocol in the world, you still need something to protect whatever data you will send afterwards.


Using HTTPS GET from app to server When developing Webpages, they say you should use POST for "destructive" actions, and GET for actions that only retrieve information.

Is the same true for apps? Is it a total no-no to use GET for sending requests from an iPhone app over HTTPS to a Web server for actions such as:

Creating games
Updating scores
Sending messages

(None of the actions are actually "destructive", none of the server functions DELETE anything, though some UPDATE things like high scores, which may be considered destructive since they overwrite stuff.)

I have backups in case of data loss, but I'm asking regardless of this.

The point about "destructive GET" is that attackers may make some victim users unwillingly send such "GET" requests. This is simple: the attacker just has to include, on his Web site, an <img> tag pointing at the target URL. The victim's browser will then perform the fateful GET.

That normal requests come from an application, and not a browser, does not change this fact. The problem is not from where normal requests come, but what abnormal requests can do.

What you could imagine is to make your application add some application-specific HTTP headers, which the server verifies, and that a basic Web browser would not set in a normal GET. But then, you do not really have a "normal GET" any more. It seems simpler, safer and less hackish to simply use POST requests for anything which may be destructive (including data updates); or, even simpler, POST requests for everything. If the client is a custom application, it should have no reason to prefer GET requests over POST.


Is there any way to prove that VPN doesn't collect data? Assume scenario that I'm running a company where we offer VPN service, and people nowadays are rightly concerned if some particular VPN provider is trustworthy or in other words that their traffic is not collected, so I was thinking if there is a way for proving that VPN service is 100% safe and that it doesn't collect their traffic.

For me, one good example was a Signal, when FBI demanded user data and basically they didn't have so much to hand them.

No, there is no way for a VPN provider to prove they don't record any data. They have to process your original traffic at some point and can't prove afterwards that they deleted it without any copies.

Let's say you use the VPN to hide your communication with a plain HTTP website from your ISP. Here, the VPN doesn't magically create an encrypted tunnel between you and the website. It only adds encryption between you and the provider. Your request to the website will eventually leave the provider's infrastructure in its original form and could be recorded by anyone on the way. Since the provider has to handle your data, there is no technical way for them to not (temporarily) know it.

So, you can only either end-to-end encrypt or trust the brokers on the way. Other anonymity solutions such as the Tor network solve the trust problem by routing traffic over multiple nodes of which the majority is expected to be trustworthy and assumed to not collude with each other.

That said, just because they can't prove it doesn't mean there are no trustworthy VPN providers. When choosing a provider you should research their reputation, the jurisdiction they operate in and read about how they intend to keep your privacy and claim to handle your data.


Is it possible to use an open collection of default SSL certificates for my browser? Browsers and Operating Systems come with a set of default SSL certificates for well known organizations, such as root certificates from CAs.

I understand that the trust model is as follows: I pick (actually my software's developers pick for me) a few major certificate authorities and decide I trust them. While I hardly ever go to the sites of these CAs, the sites I do go to use certificates that are dependent on the CAs, such that I automatically trust any certificate descended from a root certificate that I trust.

However, I actually trust the sites I visit more than the root CAs. So, I don't want to use this tree-based model. Instead, I would like it to be my personal responsibility to individually verify and store the certificate of every site I visit. I understand that this may introduce risks since my own resources for detecting compromised certificates are limited.

It seems like I could do this today: I can delete all my root certificates, and just start adding exceptions for every site I visit (assuming that I decide to trust them). However, this would introduce a very frustrating adjustment period where my browsing is frequently interrupted by having to constantly add exception for sites I browse frequently.

I further imagine that this impracticality can be easily solved: Many sites I visit are uncontroversial, trustworthy, straightforward cases like Google, StackExchange, news sites and so forth. If a few random strangers on the internet all agreed that a certificate is the legitimate SSL certificate for www.cnn.com, I could believe them and just use the certificate they gave (what are the odds that these people have compromised the certificate of CNN and at the same time conspired to fabricate an apparent consensus in favor of the forged certificate?). So, there could be a crowd-sourced online repository of common, uncontroversial sites so that I can simply download their certificates in bulk every year or so and massively reduce the number of exceptions I need to add. Obviously, sensitive cases like my bank would not be included in this repository - I would manually vet that certificate myself after careful consideration.

This would eliminate my need to trust root certificates, and eliminate the risk of compromised or malicious CAs. In exchange, the new risk is that there happens to be a very concerted operation to poison the repository with forged certificates of an inconsequential site that has been compromised just as I download my certificates for the year (I can further compare those to the ones I already have and scrutinize unexpected changes). The impact on usability is negligible: After installing my browser, I just need to download a zip full of certificates and dump them into my certificate cache. I would now need to personally decide whether to trust obscure or sensitive sites instead of automatically trusting them through the root certificate, but perhaps that is not such a bad thing.

Is this sort of model possible? Does such a repository already exist? Are there important flaws that I have failed to consider?

Note that I am interested also in implications of long-standing security problems. For instance, I think it is interesting to consider the implication of adopting my above proposed scheme, given the possibility that my root CA and my bank have already been compromised and have been so for several years.

The model you're talking about is Certificate and Public Key Pinning.  The primary flaw is maintainability; it's the traditional hosts-versus-dns issue with the added burden of making sure your manual updates are trustworthy (because if you don't pay attention there, you haven't gained anything).

It also may be harder to manage support for it in your commodity software.  I note that Firefox seems to have added something for it.  Chrome has had some pinning since Chromium 13, although it's not clear to me that it's a user-accessible interface.

In short, it's a good idea, not trivial to set up, harder to maintain over time.  It makes sense in certain limited scopes of highly sensitive trust relationships (your bank is a good one), but not as a general way of life.


How to acquire security advisory for CentOS? I've been seeing security advisory number like CESA-2017:1842, and after search I could only find some of them in mailing list archives such as this.

Is there a website like https://usn.ubuntu.com or https://access.redhat.com/security/ that dedicated to the announcement of CentOS related vulnerabilities?

AFAIK, whatever applies to RHEL should apply to respective CentOS release. Read more here on the similarity part (https://unix.stackexchange.com/questions/27323/is-centos-exactly-the-same-as-rhel). [1]

Also best way to search for CVE is to go to https://cve.mitre.org/ and search for CVE List with keyword like "CentOS". e.g. (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CentOS)

Edit: In the provided first link, an answer mentions "CVEs (Common Vulnerabilities and Exposures) are not tested on CentOS, and it is expensive to test them properly." I didn't got any source to verify this claim.


Any tools like PuTTY for manually stepping through network communications? Are there any tools that would allow me to "manually" step through the network-stack processes of a device connecting to a network and communicating with other devices? Similar to using PuTTY to manually mimic a web browser through sending and receiving manual GET/POST requests, headers, user-agents, cookies, etc.

I'm trying to find a "simulator" tool for understanding the network stack/OSI model. I understand them generally, but am looking for a hands-on tool that allows one to step through the processes of what a network device does automatically behind-the-scenes when coming online to a new network (sending broadcast packets, responding to ARP, etc).

The problem with what your asking for is that there isn't a 1 to 1 mapping of the OSI layer to actual implementations. The OSI layers are really conceptual more than physical. In reality, the demarcation between the various layers is very blurred, which makes it near impossible to implement a tool which can break things up and break them into specifric layer operations. I have seen some simulators used for teaching purposes, but don't know of any which are free or open source. Being simulators, there is only a limited amount of value in them anyway.

My recommendation would be to use wireshark to monitor traffic and then perform some standard activities, such as an http and https session, a telnet/ftp session, sending a email message, ping, traceroute etc. You can capture the traffic and then use wireshark to inspect what is going on. As a tool, it is very powerful, but like most powerful tools, it can take a while to learn. However, the interface and filtering options are pretty good and it provides a good way to 'zero in' on various levels of the network traffic.


RSA blind signature vs signing a hash My understanding is that the key feature of a blind RSA signature is that the signer is unaware of the contents of the message being signed.

How is this different from simply hashing some data and feeding that hash to the input of the RSA signing function?

Since the signer only knows the hash of what they are about to sign, it accomplishes the same task - the signer is unaware of the contents of the actual message.

What is the rationale behind introducing blind RSA signatures, rather than using the method described above?

According to the Wikipedia article for Blind Signatures:

  Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify.

The principle of unlinkability exists (among other reasons) to protect the anonymity of the message's author. Imagine that 4 people each give a blinded message to the signer, which the signer provides signatures for. At some later date one of the messages is revealed. The signature should prove that A) the message is un-altered (integrity), and B) it is one of the original 4 messages (authenticity), but it should not be able to tell which of the original 4 it is (anonymity).

If you used "signing a hash" as a form of Blind Signature, then the signer (or an attacker recording their network traffic) could remember which hash came from which person, and then once the full message is revealed, you can compute its hash, compare it to the hashes that were submitted, and know which author wrote it, thus de-anonymizing the author.

Some applications or use-cases may not care about unlinkability, in which case signing a hash is a fine way to do a Blind Signature. But if you do, then this scheme is no good. For example, Blind Signatures are commonly used in election systems in which the inability to trace a revealed ballot back to the person who cast it is a requirement of the system.


Man In The Middle Attack On File Uploads I am using a web service (call it X) which allows files to be uploaded to AWS S3.

The way it works is that an initial call is made to X which then returns a list of file descriptors and also meta information which should be injected into the web form as hidden fields that the user is presented with to choose a file to upload. One of these hidden fields is the url of the S3 bucket where the file will be uploaded to.

When the user chooses a file and clicks submit the file is sent as byte streams to the S3 location.

I see two security concerns here:

The url which is returned from calling X and then set as a hidden field in the form could be hijacked and substituted for another url of the hacker's choosing
I am not sure if this is possible but the byte stream from the user's browser to the S3 bucket could be diverted?

Is this paranoia or actual real security concerns?

actual real security concerns?

This depends on whether or not the application is properly secured.

Is the url served via a secure connection (HTTPS)?
Are all common security headers set, especially strict-transport-security?
...and other important headers, like X-Frame-Options to prevent clickjacking?
Does the web application have a proper CORS policy/configuration=
Is the web page secured against XSS (no vulnerable javascript frameworks used, X-XSS-Protection header properly set)?
Is the form submitted via a secure connection (HTTPS)?
Is "Service X" trustworthy?

When all of the above is true, and/or set up correctly, I don't see why this shouldn't be less or more secure than having the url already pre-set in the web application.

It would be preferable if service X was under the same control of the owner of the web application itself, since things like "trustworthyness" may change over time.

Just make sure that the application doesn't allow arbitrary upload urls for assets. I've seen that before, that webpage APIs allowed the user to specify the upload-url path, making it possible to create signed upload- and even download-links.


Hypothetical Scenario: How will an Ubuntu computer fare? Imagine, for instance, a wireless network with four to five devices connected. Some are android phones, some are Windows computers. The attacker (Alice), a world-class expert from a nation-state's intelligence agency, gets a head start and has unlimited access to the network and all of the machines for as long as she wants beforehand, but must leave the premises and conduct her attack remotely during the scenario. When our scenario begins, Bob is tasked with two goals:

Do not allow any passwords or encryption keys to be stolen by Alice.
Do not allow Alice to load any malware onto the new machine.

Bob's privacy is not important. All that is important is these two goals. The new machine is a standard installation of Ubuntu 16.04 LTS, with full-disk encryption and encrypted home directories for all users. It has been introduced to the network for the first time. Bob is a very savvy user and is resistant to social engineering attacks. If Alice can cause Bob to fail at either goal in 24 hours, she wins. Otherwise, Bob wins. In your opinion, who will emerge victorious?

Whilst obviously its impossible to state definitively without knowing the capabilities of the specific nation state attacker in question, I'd be betting on Alice every time here.

There are a load of ways that a nation state attacker could attack this kind of setup.  The obvious approach with physical access to the network in advance would be to take control of the default gateway router/firewall and ensure that it's possible to intecept all of bob's Internet bound traffic.

Then :-

a) Possess a trusted root CA certificate and use it to MITM all SSL encrypted traffic including browsing.  It seems very likely that high-end nation state attackers have either copies of root CA keys which are trusted in browsers used by Ubuntu, or have an intermediate cert signed by such a CA.

b) Use one of their inevitable stock of 0-days to attack whatever browser bob is using at get access that way.  If you look at the results of things like pwn2own private groups have 0-days in popular browsers, so it's kind of inevitable that nation states have the same or better access. Heck you probably wouldn't even need the root CA as most standard browsing will hit some non-encrypted sites that can be easily MITM'd

Frankly I doubt a standard user with any stock OS would stand any chance against  a nation state who had significant interest in getting access to their data.  The shadow brokers releases showed one likely small part of their capabilities.


Risk of allowing the string "xss" in query string A former employee, put the following in our "global.axas"

if (url.Contains("xss")){
response.StatusCode = 404;
response.end();
}

I get he was trying to prevent cross site scripting, but other than example where people put alert('prevent xss');, what is the risk that he was trying to prevent?

The reason I'm asking is because we encrypt some data and the encrypted string contains the "...xss.." string, which is preventing the application from working as expected.

That is just cargo cult security filling no real purpose.

Any attacker who finds an XSS vulnerability could easily bypass that. Actually, probably they will never run into it the first place since there is no reason to include the name of the exploit in the payload. But if I discovered that any URL containing XSS resulted in a 404 I would be encouraged to explore more, since it is a sign that the people who wrote the application didn't know what they were doing.

While it provides no security, it does impact usability. There are a thousand different situations where you might legitimately have XSS in your URL (e.g. if you are base64 encoding anything).


How does SQL injection work through URL? I wonder how SQL injection works through URL with SQL in the parameter. Assume I have a database with a table named mytable. When I get an ID from method POST I put it in this query:

SELECT * FROM `mytable` WHERE id='POST[id]'

Even if the user puts SQL like:

SELECT * FROM 'mytable'

It became something like this:

SELECT * FROM `mytable` WHERE id='SELECT * FROM 'mytable'

So it just returns:

  You have an error in your SQL syntax.

So how does this kind of attack work? How can the attacker change the query without causing a syntax error?

The point of SQL injection is to modify the query where the variable is.

Let's use the query you wrote as an example. If the variable id contains something like this and isn't sanitized properly:

' OR 1=1#

It would return every single row because it has been modified to this:

SELECT * FROM `mytable` WHERE id='' OR 1=1#'

The trick to avoid the syntax error is to comment the rest of the query (The character # does it in this situation.


What would cause a server to only send over 1 SSL certificate to a client? We have a secure server that seems to only be sending over the identity certificate. Running the hostname through Qualys says that only 1 cert was provided. The intermediate had to be downloaded on the fly. This is not a problem for browsers but we have a custom app which uses an SSL library to connect to these servers that can't build alternate paths or download certs on the fly. We have double checked and the server does have the proper certificates installed. Has anyone ever ran into this?

You have to configure your server to provide the chain certificate. How precisely to do this depends on your server.

For apache, you need to add to your config:

SSLCertificateChainFile /path/to/intermediate.crt

For IIS (and most other Windows-native stuff), you have to import the intermediate certificate into your server's "Intermediate Certification Authorities" certificate store.

For applications that don't support chain files in the configuration, you can append the intermediate certificates to your certificate file:

cat intermediate.crt >> mysite.com.pem

Be sure to only include the needed chain certificates and not the root certificate, as that would result in a "contains anchor" message. It would still work that way but it is not technically correct.


oracle weblogic vulnerability I searched for Oracle Web logic vulnerabilities and found this vulnerability:
Oracle WebLogic Server Cross-Site Scripting and Manipulation of Data Vulnerabilities (http://secunia.com/community/advisories/51501)
I want some sample attack scenarios to test My web site against this vulnerability, Any Help?

Well if you're the owner of the system the simplest way to confirm that your application is not vulnerable would be to ensure that the version number is higher than the affected ones.

Beyond that if you're actively looking to exploit this issue to test for its presence the text explaining the first issue is actually pretty descriptive.  To test that you'd likely need to use a proxy such as Burp or OWASP ZAP, then browse to the affected URL, look for the parameter they mention in the description and modify it to inject HTML, something like

"><script>alert(1)</script><"

could be a good starting point.

For the second one unfortunately there's less details, so harder to establish. My typical approach would be to put the CVE number into your search engine of choice and see what comes up.


Web redirecting to porn site My company missed to extend a domain name by few days, so it went to grace period. From what I know, if it went to grace period, people would still be able to access my website. However, the site was actually showing a porn site with domain name header. My boss quickly paid the domain names and few minutes after that the website is back. This creates catastrophic situation between company and users and I should be able to explain this to the users.

After days of research, I'm unable to find what in the world why the site was showing a porn site. So here is my conclusion so far: The developer used OpenX v2.8.8 to show ads, maybe someone has hacked it using XSS or CSRF attack. The URL is still connected to our domain but with subdomain of OPENX.

My question here:

Was the site hacked?
If it was hacked, I need to know why it could be hacked?

Note: I can't disclose the site name for the sake of security.

While multiple vulnerabilities exist in OpenX, there just isn't enough information in this case to tell for certain if your site was hacked or not.

It appears from what you said that the company from whom you bought your domain simply redirected your DNS records to a porn server after you stopped paying. And then when you paid again, they redirected you back. That would indicate that your original site and server was not actually affected at all.


How to use http-get-form in THC-Hydra? I've been messing with Hydra (Brute Force) to solve the "Damn Vulnerable Web App"
brute force section but the problem is when I use http-get-form it said:

Warning: child 1 seems to have died, restarting (this only happens if a module is bad)

And the brute force command is:

hydra 192.168.100.15 http-get-form \
      "/dvwa/vulnerabilities/brute/#:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect" \
      -l admin -P /root/Desktop/wordlists/test.txt -w 30

I can't find out why the module is bad.

hydra -l admin -P /root/Desktop/wordlists/test.txt dvwa http-get-form "/dvwa/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect."


Open-source alternative for CryptGenRandom? Let's say that for some reason I don't trust CryptGenRandom.

Are there any open source software Windows entropy collectors to get cryptographically secure random numbers from for seeding purposes?

I'm looking for a software alternative here - I very well know I could hook up a physical RNG to my computer, however this can't be used in general for software packages shipping to users.

The simple answer is that if you don't trust CryptGenRandom() then you are doomed. Indeed, CryptGenRandom() is provided by the operating system, and if the OS is hostile then there is very little you can do to defend against it. An hostile OS can inspect all your RAM, log all your passwords, send all your data to external third parties.

The less simple answer relies on a subtlety, which is that you may mistrust CryptGenRandom() while not actually supposing that the OS is hostile. Maybe you consider that CryptGenRandom() is simply flawed, by accident and not by malice, and delivers randomness of poor quality, while no other component of the OS actively tries to cheat on you.

In that case, it becomes sensible to augment CryptGenRandom() with some extra entropy. Entropy comes from physical events and the OS is ideally placed to gather physical events; applications are in a much less ideal position for that. Nevertheless, some people have tried. For instance, there is an applicative entropy gatherer in GnuPG (at least in version 1.4.14, look for the rndw32.c file).

The correct way to gather entropy is to take all the "events" (e.g. "key X was pressed at time T"), concatenate them together, then hash the whole lot with a proper hash function like SHA-256. Then use the output as seed for a cryptographically secure PRNG. In particular, don't shun CryptGenRandom() completely; call it to get some bytes of output (say, 16 bytes), and add that output as an "event" like all the others you gather. The beauty of the hashing is that even if the event is flawed in a malicious way, it cannot lower your resulting entropy; it can only contribute positively (at worst, it does not contribute significant amounts of entropy).

The hard part of random generation is not obtaining entropy; it is estimating how much you got. An hardware event is "useful entropy" exactly inasmuch as any potential attacker cannot predict its contents. For instance, an attacker observing the network may predict the exact moment your machine receives an incoming packet, with precision down to, perhaps, the microsecond. If you time that event with nanosecond precision (Time Stamp Counters are convenient for that -- Windows calls them "performance counters"), then you may consider that each incoming packet yields 10 bits of entropy (because 210 is approximately equal to 1000, which is the ratio between microseconds and nanoseconds). It is all relative to a specific physical context; making a one-size-fits-all RNG in pure software thus necessarily implies a lot of overkill.


Anonymous but not unique hash? For a website I am creating we have to store a user id for people that do a test without creating a account. The user id has to be the same for the user if he does te the test 2 times but should also be anonymous, by which I mean not retracable to the person. The only purpose for it is that the ID is the same in the export for a user that does the test more than 1 time.

I have tried thinking of a way but can't get my head around it.

One way to achieve this is to generate UUID's on the server and set a cookie. That then becomes the ID and the client manages it without further need of input from the server.

UPDATE: Just to clarify, using this method stores nothing at all about either the user nor the client, it is in no way identifying other than knowing that it is likely the same cookie comes from the same source. Using a UUID ensures, like a hash, that the number is unique without needing any complex algorithms or user information that might compromise identity.

Really not a security question though.


Shared hosting mail server, Thunderbird and encryption In spite of much searching on the internet, I can't really get an adequate understanding of this topic, perhaps because it combines multiple elements. As a result, I'm really worried about the state of my e-mail security.

The website/mail server is hosted on a shared Apache server. E-mail is POP3 and secured only by password. I access my e-mails through Thunderbird, which first time round warned me that I have an insecure mail server and that e-mails sent are wide open to prying eyes etc.

The question is: Can I do anything or should I avoid using that e-mail address?

How does encryption (e.g. via Enigmail) work? Will it protect me in this set-up? Does it only work if the recipient also has encryption software?

It strikes me that there are perhaps two different but related concerns:
1. Security of the shared hosting mail server.
2. Security of e-mails sent via the mail server.
While I should surely be concerned about number 1, my main priority right now is number 2.

Assuming the server supports SSL/TLS (i.e. it has a valid certificate), it is possible to protect the email communications between the server and the user with SSL/TLS. This is especially important for the password - without this the password will be sent in the clear. But that won't protect the email communication between your server and other servers (assuming you send emails to other people that don't use the same server you use) or between the other servers and their users. For more details see Can I expect my e-mail to be routed securely?.

For this you need some form of email encryption. For email encryption to work both the sender and the receivers of the email must use compatible email encryption software and must share public keys. I believe Enigmail is OpenPGP compatible and should be compatible with any other OpenPGP compatible software.

As you note another concern is the security of the emails at rest - i.e. on the server. This is a greater risk in that an attacker who breaches the server will have access to all emails that are on the server including historical emails. An attacker who can read the communications between a user and the server can only read current emails. For the same reason it is most critical to protect the password than to protect the emails in transit - an attacker with the password can read all of your emails, including your future emails. Details on how to protect an Apache server can be found here.

For a great analysis and recommendations on how to secure emails, please see the NIST Guidelines on Electronic Mail
Security.


What is a 'safer' way to write down passwords? Many times people write down their passwords on paper.
Instead of them writing it in plain text, what techniques are there to make things more difficult yet not too much of a pain for the password owner to decrypt?

The idea is not too prevent a security expert from decrypting it, but just to make it harder for someone who finds your password written on paper.

You could think up some easy pattern, trick or algorithm that you can do in your head and then keep it secret. An example would be in the TV series The wire where they would have pager numbers where to decode they would have to 'jump over' the 5 of the keypad, so 789 would become 321.


How Secure is Storing Cryptographic Information into the CPU Register instead of RAM I read about Tresor / TreVisor / Armored.

How Secure is Storing Cryptographic Information into the CPU Debug-Register over storing it into the RAM?

And why is it currently not much used?

I know that this will mitigate a Cold-Boot-Attack which is one of the ways to "break" a Full Disk Encryption but what are further uses?

As far as I know is the Programming of this functionality not so much more complicated as "normal" use of the RAM.

An answer obviously depends on the kind of CPU you are talking about.

For example, with general-purpose registers on a modern x86 CPU, you have several problems:

CPU registers are mostly 64 bits wide. To store a cryptographic key of decent size, you'd need at least two registers. This is a problem because the number of registers on x86s are very limited (it's even worse with older x86 CPUs)
CPU registers are the main "work area" of a CPU, so you can't store a cryptographic key there for longer periods of time because there is basically no protection/isolation in effect - any register, except some special purpose registers (which, however, are needed for correct functioning of the operating system/task switching etc, and therefore can't be used to store cryptographic keys), can be accessed by anyone who can get the processor to execute a few instructions. This isn't true for memory, which can be protected from access by unauthorized programs.
On operating systems which support multitasking (so, basically every current OS), when a task switch occurs, all the register contents are saved to RAM when a task is preempted and reloaded from RAM when the task is given the CPU again. This happens dozens, if not hundreds of times per second. So your cryptographic keys would end up stored in memory anyway. They might also end up swapped out to disk when a page that stored a currently stopped task was swapped out to disk to make room for another process.

Edit: As your followup comment and my repsonse to it explains, you can work around some of these problems using special purpose registers which are usually unused. However, there are still problems that don't seem to make this worthwile:

Your OS must cooperate - if it happens to use these special-purpose registers for the purpose they were actually designed for, your keys get overwritten, and your data may be trashed without you noticing it.
You're still only protected against cold-boot attacks (assuming no state actually leaves the CPU, which isn't so easy to guarantee due to task preemption) and against low-privilege attacks that can't get access to ring 0. When your kernel gets compromised, your keys can still be easily stolen with just a few simple CPU instructions. It might be even easier to steal them in that case, because you'd know exactly where to look for them. So you're not adding any security except against cold boot and maybe some DMA attacks (when an unprivileged program stores keys in RAM, other unprivileged programs can't read them, either).

I don't know how prevalent cold boot attacks for key extraction actually are in the wild. I'd assume state-sponsored special ops teams, plus your occasional gadget freak might pull them off. But I'd worry much more about compromised OS kernels than about cold boot attacks.


Is listening to an audio stream through Tor (using Tails) hazardous? If someone were to listen to a SHOUTcast server through Tor using VLC (not just downloading the M3U playlist through the Tor browser, of course, but while running Tails), would it put their security in jeopardy? I'd think it would be a pretty straightforward connection, just like downloading any random MP3 files and then listening to them, but I know what an issue, for instance, watching videos with Flash is.

I've found this Is using player like VLC safe alternative to Flash? on Tor Talk which basically says that if VLC happened to have an exploit and you were using it to watch Flash videos, you'd be badly off; But, how much of an issue is VLC's track record, really, and are there more secure alternatives? Most importantly, listening to a SHOUTcast server's stream wouldn't be pertinently different from what's discussed in this thread, right?

Watching videos using Flash is hazardous to your Tor security because 1) Flash can access servers directly rather than going through Tor, and 2) Flash has more holes than a block of Swiss cheese.

Listening to audio has the same risks: if your audio player ignores Tor and connects directly to the SHOUTcast server, it can reveal your IP address; if it has security holes, a malicious stream could be used to attack your computer.

Tails mitigates the "direct connection" risk by setting its firewall to block outgoing non-Tor connections, but it does little to protect you against insecure programs.


Disk Wiping - How can I be sure I am selling some hard drives but my question is. How can I be sure that the information is gone?

Is there a good way to wipe the drives?
What are ways I use to attempt to recover the data to ensure that they are clean.

The wiki page for this has surprising amount of useful information here
Usually between 2 and 3 passes will almost guarantee the removal of data from the majority of the layers, but for some tools corrupted sectors can cause issues. Most companies will use shredding services there after to ensure there is nothing coming off of those disks, so as for re-selling them i'm not entirely sure how that will work ;).

Also to be sure you will be looking for digital forensics, there are degree programs surrounding this topic so don't expect to learn it in a day. The most common tool used is this one the sleuth kit, there are plenty of blogs around for tips and tricks when using it.
Happy hunting
edit dd the unix utility is also awesome for this sort of thing


Who first introduced the notion of attack graphs? I've been searching the literature and haven't been able to pin it down. The concept probably existed long before the name was coined, but who is the invention/introduction of attack graphs attributed to?
EDIT: Here is an image of an attack graph. It essential models dependencies between vulnerabilities in a network, describing how an attacker may exploit and progress through a network.
Source: http://www.isaca.org/JOURNAL/ARCHIVES/2012/VOLUME-3/Pages/Haruspex-Simulation-driven-Risk-Analysis-for-Complex-Systems.aspx

As the comments mention, it was Bruce Schneier in a 1999 publication:

Bruce Schneier. Attack Trees: Modeling Security Threats. Dr. Dobb’s Journal, Dec 1999.


How much entropy is required for a Grid Card? We're in the process of implementing multifactor authentification. One good candidate for this was the "Grid Card" - a small table with random letters and digits. Upon login, the user would be queried for the contents of a cell in the grid.

Example

For a typical user, the grid could look like this:

┌──┬──┬──┬──┐
│A9│64│UT│U4│
├──┼──┼──┼──┤
│K7│2C│4F│JK│
├──┼──┼──┼──┤
│3W│V9│V7│HH│
├──┼──┼──┼──┤
│TA│PN│KU│A7│
└──┴──┴──┴──┘

The Problem

In order to avoid ambiguous symbols, the total character set was reduced to 23 characters in total. With a 4x4 grid with two letters each, I assumed the total entropy of one query to be about 232, which is only 529. Is this enough for a secondary factor? If not, how can its security be improved?

I assumed the total entropy of one query to be about 232, which is only 529

The computation is correct but what you show is the number of variants which is not the same as entropy or password strength. This would instead be about 9 since 29=512.

  Is this enough for a secondary factor?

Probably not but it depends a lot on how this second factor is used. If the attacker can do unlimited guesses in a short time without any side effects then this is definitely not sufficient. If instead the first wrong attempt will result in immediate death of the attacker then even this easy to brute-force scheme might be too risky to even start with brute-forcing.

  If not, how can its security be improved?

The obvious ways are to increase the number of variants, i.e. put more letters in each grid, choose from more symbols (for example use small letters too), ask for more than only one grid cell ...

Apart from that limit the number of possible attempts to slow down brute-forcing. This might be an increasing wait time after each wrong guess or even a permanent block after a specific number of wrong attempts. Or increase the costs of each wrong guess by actually requiring more and more money to have another guess :)

What of these and similar proposals  is actually doable depends a lot of the environment where this scheme is used. It also depends on the value of the assets which should be protected by this scheme, i.e. the costs to break this scheme should be higher than what can be gained as result so that breaking the scheme is not attractive. This means that another way to deal with the problem is to limit what the attacker can achieve with a single correct guess.


Can an attacker detect if I have a TARPIT enabled? Last thing we want to do is provoke an attacker and offer them challenges or puzzles indirectly to give them a flag to stay and continue to hack rather than move on to other hosts.  If possible, I do not wish to let the attackers know that my iptables rules have TARPIT enabled for certain ports.

If I do not know that TARPIT is enabled, in most cases, as a user, it just feels sluggish or unresponsive and after a while, I'd imagine I'd just give up because the server is probably running slow or has a very slow hardware.  I think last time I've tried to nmap on my TARPIT enabled host, it just reported that port was open, but did not slow it down, so from the attacker's point of view, it's business as usual.

Although it is more for the sake of concerns, from academic point of view, I am also curious to know if the endpoint has TARPIT enabled or not, and what one can do to make it less obvious.

According to http://www.netfilter.org/projects/patch-o-matic/pom-external.html "Connections are accepted, but immediately switched to the persist state (0 byte window)...".

Since the window is send to the peer in the TCP packet a knowledgeable attacker might deduce from a packet dump that your system is either permanently overloaded because all connections stall immediately or that it is running some kind of tarpit, in which case the attacker might probably easily find out which ports are not protected by the tarpit. Most script kiddies instead will probably do not understand what's going on and just give up.


TLS handshake proof of private key posession At what stage in below TLS connection setup did the server prove to client that it possesses the private key corresponding to its public RSA key.

I have used TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Cipher suite to successfully setup a server client mutually authenticated connection. I am just curious how it works. I have a rough idea about Diffie Hellman key generation(I believe it is independent of authentication, and just for generation of secret to create symmetric key) but I could not understand in below sequence diagram, where did the server prove its possession of private key(I know that only private key decrypts what public key encrypts, but any hacker could send a copy of public certificate of any server)

There doesn't have to be any explicit proof of possessing a private key.

When you present a client with your certificate, the client will respond by encrypting data with the public key present in the certificate. If you don't have the private key, you will not be able to decrypt what the client sent hence the connection will not move forward. @adam86 pointed out that my answer was not clear. What I meant was that up untill you have a Diffie Hellman key exchange, the messages are encrypted using the public key. Once a symmetric key(session key) is established, it is used for the rest of the session.

What a motivated attacker can instead do is create their own certificate and act as if they are the actual server (man in the middle). This is still possible in SSL/TLS.


If Java is inherently vulnerable to System.getProperty injection attacks, is it worth it to validate? In Java it's common to see code such as System.getProperty('line.separator') which is used to build Strings used for output, etc. It has been recommended by vulnerability scanners that it is advisable to validate this input by e.g. ensuring it matches \n or \r\n etc.

But I wonder, since Java itself is vulnerable to these within its own PrintWriter.printLn and possibly BufferedWriter.newLine() etc., is it now a best practice to validate System.getProperty('line.separator') within every program that issues new line statements? It seems overkill.

Is there some alternate best practice that would obviate the need to validate all System properties? E.g. is it sufficient as a best practice to review the privileges and commands at the sysadmin level rather than at the developer level? If not, why are vulnerability scanners taking these precautions now?

My impression is that this kind of validation at the code level is overkill in a standard corporate production environment where there are multiple levels of separation of duties and privilege lockdowns among dev/test/prod etc. This is just my opinion however, and I would like to hear others'.

Ensuring it matches a predefined pattern negates the point of having it.

From the oracle documentation -

  Security consideration: Access to system properties can be restricted by the Security Manager.

And also

  The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up. The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up.

So to be a risk you have to expect a malicious party to somehow inject a setProperties call into your running application. Unless you pass user input to a "setProperties" call (which is a terrible idea in general) this should not be a problem. If they can inject code then you have far bigger issues. If you are still concerned then use the SecurityManager.


Deep packet inspection of VOIP packets Some telecommunication companies in Europe and maybe in other parts of the world now want to charge their customers for the VOIP traffic (maybe some already are doing it), e.g. the use of Viber, Skype etc since it´s "free" to use in Android and IOS.

I guess they will use deep packet inspection to read the headers of the packets to figure out that it comes from services like Viber and Skype.

I want to discuss the security view about this and in what ways it is possible for a customer to bypass the packet inspection and what a telecommunication company can do to inspect the packets even if a customer tries to bypass the inspection.

This is what I know that will make a customer bypassing the inspection, and what a company can do to inspect the packets even if they are encrypted.

To bypass packet inspection:

Use VPN
Use a SSH tunnel
The developers of Viber and Skype adds SSL support into their application

To inspect:

Read packet headers to see from which application the packets are coming from
Read the time interval and packet size

What else can a customer do get around the inspection and what else can a company do to inspect the packets?

I couldn't find any articles stating this and  I highly doubt they would charge you for it (unless you are using their VOIP services instead of skype). The reason for this is that some providers prioritize this type of traffic on their network and some even have special separated networks (this only works for their VOIP phones/services).

You can't really encrypt voip itself with SSL. The reason for this is that VOIP uses UDP. SSL requires a stateful protocol like TCP. So a VPN tunnel would be the only option.

If they want to know if you are using VOIP you would indeed need to do DPI with IPv4. With IPv6 this isn't necessary as IPv6 has a special header field to identify the traffic.

Your best option would still be a VPN. I don't really know of any other ways.

EDIT

Bruno suggested you can also use DTLS at implementation level.


Buffer Overflow example - strcpy Practicing and learning buffer overflows by example.  I have a question of why a particular buffer overflow is not working with strcpy().  I can trigger the buffer overflow segfault with gets() in stuffing 8 or more characters.  My question is for 7 character input.  The gets fault condition is not triggered, but copying 7 characters into a buffer of 4 should trigger a segfault in the strcpy() line.  What am I missing?  Why isn't it triggering?

#include <stdio.h>
#include <string.h>
void pass_function()
{
    int length;
    char bufferA[8];
    char bufferB[4];
    printf("Enter password: ");
    gets(bufferA);

    strcpy(bufferB, bufferA);
    printf("Returning\n");
    return;
}

int main(int argc, char *argv[ ])
{
    pass_function();
    return 0;

}

First we must consider that built-in machine architecture decisions impact the way you exploit these issues. For example, in the classical writing Smashing the stack for fun and profit by Aleph One, we can see that an x86 stack typically grows downward (i.e. the base for the stack is the highest address, and as we push onto it, the stack pointer decreases in value)...

  Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel,
  Motorola, SPARC and MIPS processors.

So for example, assuming your compiler doesn't rearrange the order in which bufferA and bufferB are pushed onto the stack, Aleph One describes an architecture where-by bufferB actually has an address which is lower than that of bufferA. I'm pretty sure this explains your observations correctly; when you overflow bufferB, you're not actually overwriting the return address, but a part of bufferA (or some padding before bufferA). You could verify this by codifying your assertion, such that your runtime will validate it (by either succeeding or generating an error message), like this:

assert(bufferB < bufferA); // I'm asserting that in your case overflowing `bufferB` will result in modifications to `bufferA`.
assert(bufferA < bufferB); // You probably expect that overflowing `bufferB` into `bufferA` is impossible because of this condition... let's see which test passes?

You might need to #include <assert.h> to use assert.

Now having said all of this, there are many, many other issues standing in the way of successfully demonstrating a stack-based buffer overflow. Various protections have been created, such that the only reliable reproduction is typically referred to as a ret2libc attack, and that requires quite intimate knowledge of the specific hardware and OS configuration. As such, I recommend that after reading the paper by Aleph One (linked to above) and before attempting to reproduce that experiment, I highly recommend watching this DEFCON video entitled "(un)Smashing the Stack: Overflows, Countermeasures, and the Real World".

Once you've reviewed these two resources, I'm sure you'll have a much better chance of reproducing a stack-based buffer overflow.


Ipod Classic w/ torrented files My friend gave me his old iPod classic, but it's got a bunch of torrented music on it; I want to wipe it with Disc Utility or perhaps GParted and start fresh... because I don't trust torrented files.

Should I be worried about plugging it in? (Could malware transfer onto my machine?)
Is there a way to safely connect a USB device and sandbox it so it doesn't auto-run anything?

I have a Linux Machine running Ubuntu 16.04 and a OS X machine.

Should I be worried about plugging it in? (Could malware transfer onto my machine?)

You probably don't need to worry, but there's no real harm to being careful either. You don't say which operating system you are running, so it's hard to say much about what risks you might expose yourself to, but given that your system doesn't have autorun enabled, odds are reasonably low that any software-based malware would be able to transfer to your system.

If you have reason to believe that either you or your friend has been directly targetted by an active, relatively sophisticated adversary, then you should worry about things like BadUSB. In that case, however, you would probably know, or at least be able to suspect, that you are.

  Is there a way to safely connect a USB device and sandbox it so it doesn't auto-run anything?

You could download a live Linux distribution such as Tails, Knoppix, Ubuntu or some other alternative. Burn that to a CD or DVD, or copy it to a USB stick (the CD or DVD in this case has the advantage of being truly read only), boot from that (and make sure your computer's hard disk is not mounted, and unmount it if necessary; Tails might be best in this regard), and use it to wipe the iPod.

Again, unless you are worried about direct targetting by active, relatively sophisticated, adversaries, that should be good enough. If you are extra paranoid, open your computer and disconnect the data cable going to the hard drive, but I'd say that even with reasonable suspicion of malware, for 99.99% or more of users, doing so is overkill; simply making sure the file system on the hard drive is not directly accessible will almost certainly be good enough.

  I don't trust torrented files.

As long as they are limited to music files, and you don't attempt to play them, the probability of a compromise through that vector seems very small. Also, malicious music files would probably need to target bugs in specific player software, which points toward plain computer hygiene being a good defense: Keep good backups, and stay on top of software updates.


MSTG-PLATFORM-11: Prevent custom third-party keyboards on Android? The MASVS states in section "V6: Platform Interaction Requirements" MSTG-PLATFORM-11:

Verify that the app prevents usage of custom third-party keyboards whenever sensitive data is entered.

There are no references for test cases or similar and when I am thinking of Android it seems impossible, to force this behaviour. In my understanding, no third party keyboards should be permitted, when entering something like a password. That means, that when under Android you have a third party keyboard installed (Google Keyboard, SwiftKey, ...) every app fails this test.
How to you deal with this test case? When does an app pass / fail this test?

So this is an L2 requirement that only is relevant if your threatmodel asks for it (See MASVS introduction) (when eavesdropping at keystrokes or forwarding the information you enter would cause a real problem for instance).
In its current form/shape it seems only applicable to iOS.
It could be passed on android as well by just creating your own keypad for a pin for instance (Which was the original V9.1 requirement in an older version of the MASVS).
In that case you should be able to resolve accessibility issues as well by means of a proper custom keypad with assistance implemented into it.


What is the best way to generate keys in phpseclib? I am using phpseclib implementation AES and HMAC. But I dont know the best way to create random keys for these.
What is the best way to do?
Is there any built in function in phpseclib to create keys of the preferred length?

See the "Generating Keys" section of the Encryption documentation.

It suggests using the following code to generate a random key:

<?php
$key = \phpSec\Crypt\Rand::bytes(32);

For the sourceforge project, it appears that if you want a password-derived key, then you can use ->setPassword() on the Crypt_AES object.  However, the only generation of random data that I could find is the generation of a random number.  That is done through the crypt_random function. I would suggest just taking the necessary functions out of the other phpSecLib.  As it is MIT-licensed, this shouldn't be a problem from a license point of view.


Searching a tool to perform SSL/TLS handshakes and store data As the title says, I am searching for a tool, which can do the following:

Do SSL Handshake beeing given a list of IP-Addresses
Support SNI (in that case hostnames would be in the list, too)
Performance (scalable on list with multiple 100 million entries, do it in less than 2 days)
Collect and store all negotiated TLS overhead (TLS-version, TLS cipher suites, ...)
Collect and store all X.509 certificates (e.G.: in PEM format, I also need certs from the chain)
Support IPv4 AND IPv6

Note that I am not trying to DoS anything, it's just part of a study. I've already read about ZGrab, but the creators themselfes write:

  ZGrab tends to be very unstable

, which is not quite a good add.

I welcome any recommendations!

You can write yourself a script which uses openssl
openssl s_client -showcerts -connect ipv4:443 </dev/null
to connect to each ip you and grep all the required information.
The server certificate is the first certificate returned, and will be PEM formatted. The CA certificate is the final certificate returned, and is also PEM formatted.The output will also have the cipher and protocol used for handshake
For ipv6 use ncat. ncat -6 --ssl -v ipv6 443 and grep all the inforamtion.
If you want to enumerate all the ciphers that ip supports, you can use testssl.sh.I'm not sure whether ipv6 is supported.
As SNI is initiated by the client, you should already have the servername of that ip to get the SNI from the server. this question might help you

If you dont want to script your way through,check out Tenable Nessus(trial version available) or OpenVAS(opensource).Before you intiate a scan, chose only plugins related to information gathering, as some plugins actually attack the target and also simply consumes more time.


What alternatives do we have for Google's reCaptcha? reCaptcha has been getting some criticism over that it's tracking visitor data recently. What are the best solutions available? Is there one that has better privacy for visitors?

You can roll your own captcha. How well that works depends on how much work you put into it. You could, for example, create an image with a sum:

convert -background lightblue -fill blue -pointsize 72 'label:7+8=' label.gif

and expect the user to solve the sum. Note: 7 and 8 should of course be replaced by random numbers and the output filename would also depend on your web application. That will weed out all the simple robots. You can blur, add noise to the image, put other things in it et cetera.

If you make that more complicated (multiple images, which image contains an object, random style captcha etc.) you will be a bit more secure.

No need for Google's captcha, depending a bit on the rest of your service.

If you roll your own captcha, you should monitor its use. If it is solved multiple times per second from a single IP address (to state the obvious), you might consider making it more difficult.


What hacking risks a site has if it has no input boxes? I recently posted a question about recovery of website from XSS attacks, https://stackoverflow.com/questions/20759081/how-to-recover-a-site-after-an-xss-attack...

Doing a bit more digging online, i found that the site is vulnerable to XSS if it allows user to give input or in other words, have any sort of input box in the site (like search box, contact us form, post a feedback etc. )

Now, what i want to know is that :

assuming a site has got no input boxes, is it still vulnerable to XSS attack, if yes, then how?
apart from XSS, other hack-attacks a site can face if  it hasn't got any input boxes for user

I know, its a pretty broad question, i just need some heads-up on the topic to google for!!

P.S : i posted this question on Stackoverflow and then was told that this is a better platform to ask this question, SO question link : stackoverflow.com/questions/20783204/what-hacking-risks-a-site-has-if-it-has-no-input-boxes, and its my 1st question here, so please correct me for TAGS fo this question!!

Even though a site my have no input boxes, it will still process input. Examples of these types of input are:

HTTP headers.
Cookie values.
Query string values.
POST data.

If the site displays any of these values back within an HTML page, the values should be properly encoded to prevent XSS.

For example, if a page output the values of the User-Agent headers of all visitors in HTML to list the raw details of all the browsers that have been used, a malicious attacker could set their header value to be malicious JavaScript code and then visit the page that records the headers.

There are many attacks possible, please see the OWASP Top 10 2013 for some examples, none of which require input boxes to be used.


protection from Backdoor hacks from disgruntled developer/ employee I created a ecommerce site with a developer. He completed almost all his work but in the end we had some financial disagreements so our partnership ended in a bitter dispute. That developer threatened to hack my site using a backdoor. To cut long story short, that guy was able to buy products from site without even paying. He bypassed payment processor and bought products. Thankfully i didnt shipped any products to him. Btw i want to clear that i had installed mod security firewall and my server was fairly secure. I hired another developer and he did full code review and found hidden admin account. He told me that my site can be hacked again as he may have left some other backdoors.

So my question is, Are there any good practices that can be used to reduce backdoor damages/hacks.
The question is not too broad. I want to know basic security practices to protect ourselves from these kind of hacks?

For one, contracts. When you have someone develop something, make sure they can't legally add backdoor, so you can sue if they try something.
Log everything. Backdoors are hard to find in code but you can see where it is after he uses it.
Have another developer harden the critical parts of your system, that being checkout, order managment and payment processor in your case.

None of these will prevent backdoor access completely, unfortunately it is not possible to prevent completely. You should only collaborate with developers you trust.


Security in web sockets Scope: penetration testing of web server with critical information in it (user management).

I had an argument with my college about security in web sockets and I got stuck with him in one topic, which is the following:

Is it secure to let any inbound connection into the web-socket
without filtering the source of the connection?

Let me explain my opinion on that:

Only an authorized user (by a certain cookie which is on the server already)  can  connect to the web-sockets gateway (WSG) via
server S, then happens the handshake, 101, and the communication
starts.

His opinion is that:

Every user, no matter whether it has the cookie or not, can query the
web-socket gatewa y.

From my point of view, if we allow  any connection request to the web-socket gateway, it may result into:

Unrestricted flood.
Scans.
Exploitation of possible vulnerability of the server to extract sensitive data.

What do you think?

Websockets are not inherently less secure then "normal" web traffic. What you describe as possible attacks against the websocket server can also be used as attacks against your websockets gateway. And while you can check an authentication cookie early in the webserver and abandon the request if necessary you could also check some authentication information early in the websockets connection and quickly close the websocket if needed.

Still, if you already have a webserver which acts both as gateway or server for the web application and for the server and which has already implemented checks for authentication it makes sense to use the same authentication for both web application and websockets instead of implementing  another one specific to the websockets backend.


What is the equivalent European organization of NIST, especially in the Security Computer Division? What is the European counterpart organization to USA's NIST?

I want to check the European best practices and guidelines on computer security.
Does anyone know if this organization exists, and if there are available publications?

I need to check the policy role of some firewall but in general I want to know what is the de-facto standard organization to watch.

I live in Italy.

The appropriate organisation for Europe is ENISA, however as Rory points out there are also organisations specific to the sovereign states, which all have their own legislation regarding data protection and information security.


Attack vectors opened simultaneous wireless and wired networks I've seen some contention around the issue of whether or not wireless connections should be disabled in an environment where a wired domain and unregulated wireless network are both present.

What attack vectors and mitigation methods exist specifically due to to having both network connections active at the same time, more specifically if the default route is set to the wireless? I'm aware of the threats associated with wireless in general terms.

Edit (11/14): As far as I know, there are no significant risks to having both a wired and a wireless network connections open at the same time, beyond the risks implied by each one individually.

There are risks with having a machine connected to both an internal-only network and to the Internet: it partly defeats the purpose of having a firewall to separate your internal-only network from the outside Internet.  The purpose of a firewall is to have a single chokepoint that controls the security perimeter.  If you have a machine that's connected to both the inside and the outside, that machine now becomes part of the security perimeter.  For instance, if that machine gets compromised, now your entire internal network is exposed to the attacker.  For this reason, it's generally not recommended to connect machines to both networks.

If malware compromises this machine, the malware could set up a route like you mention -- but if malware compromises your machine, it could just directly start attacking your internal network without modifying any routes.

I want to emphasize again the importance of being clear in your mind about which aspect of the networks is relevant.  For instance, in this case, I think the "wired + wireless" part is not a concern, but "internal-only + Internet-connected" part is a concern (and "not-under-your-control + under-your-control" would also be a concern).  I don't know what you mean by "regulated", so I'm ignoring that aspect.

I don't think there's any need to go around creating/imposing some special restriction on your hosts to block access to wireless while they're connected to a wired network.

There is one mitigation I can mention to you, for consideration.  One organization I'm familiar with has two separate internal networks: one network for non-mobile devices, and a second network for mobile devices (laptops, smartphones, etc.).  The first network has full access to our internal servers, and only supported wired (not wireless) access.  The second network has semi-limited access to some (but not all) internal services.  It supports both wired and wireless access.  All mobile devices (laptops, etc.) are automatically directed to the second network (even if they connect via Ethernet, they are still connected to the second network).  The purpose of this mitigation is to reduce the spread of malware: empirically, sysadmins noticed that people would often take their mobile devices while traveling, get exposed to malware from some other network (e.g., at a hotel that doesn't have our firewalls), get infected, then bring their device back home and connect to one of the internal networks and infect other internal machines.  This isolated-network design is intended to slow down the spread of such malware.  Today, it might not be as effective or realistic, but it's something you could consider.  However, the best way to mitigate your risks will likely depend intimately upon your particular business and your particular situation.

My earlier answer to the original question:
This question is confusing.  It seems to me you are confusing/conflating several different concepts:

Communication medium: wired vs wireless.
Connectivity: an internal-only network (that can't reach the external Internet) vs a network that's connected to the Internet.
Administrative control: a network under your organization's control, vs one that is not.

These are independent features.  They're not tied to each other.  Your question seems to start from a faulty premise: it seems to equate, e.g., wireless with "not under your administrative control and connected to the Internet" while equating wired with "internal-only and under your control".  If that is truly what you were thinking, it is a misconception.  You can have a wireless network that is either under your administrative control, or not; and is either connected to the external Internet, or is not.  You need to analyze the effect of each of these aspects separately.

Each independent axis affects the risk in a different way:

A wireless medium is potentially riskier, because it enables eavesdropping, interception, and message injection by anyone who is within radio range.  This risk can be mitigated or eliminated by using proper security, e.g., WPA2 with a strong key.
Internet connectivity adds risk, because there is the potential that people visit a malicious site and get attacked (or otherwise are attacked by malicious entities on the external Internet).  This risk can be somewhat mitigated by using firewalls, endpoint protection, and device hardening, but only to a limited extent.
Use of a network outside of your administrative control adds risk.

So, what should you do?  You should figure out what your business requirements and needs are.  You should identify what the threats and risks associated with the networks are.  Then, based upon a cost-benefit analysis, identify controls to mitigate those risks so the risk is at an acceptable level, given your business's requirements and risk tolerance.  Saying anything more specific will depend heavily upon your particular organization and your particular situation.


Protecting an invitation to join the system I'm having a debate with a coworker right now about how to design an invitation system.  The idea is that the mobile app will be able to send an invitation link to, say, a Whatsapp group, and people from that group will be able to use the link to join our system and be automatically enrolled into a group on our system.  The coworker suggests the link format be along the lines of:
https://www.ourdomain.com/Register?groupId=12345

I said that this was insecure because someone could just change the group ID and register with our system (which is marketed as, amongst other things, 'secure'), having the system join them into any group they can guess the ID for.  This system is going to be used by medical professionals.  I suggested that the "group ID" should be encrypted, and he responded that there's no point because someone could just reverse engineer the app and generate their own encrypted group ID anyway.
I then suggested using a server-generated ID for the invitation ID, and storing the group ID in which to enrol the user upon registration in the server's database, to which he responded that that too could be hacked, and that it would just be harder.
What's the best practice for this sort of "invite link" in terms of security?  It seems to me that the coworker has a very blase attitude towards things, and that whilst technically the system could be hacked, it's still worth making it harder to hack.

A good solution would be to make the ID very long and impossible to bruteforce, for example providing 128bits of entropy (for example about 38 digits or 22 alphanumeric characters).
Then you also need some kind of PIN or password, because otherwise the link alone would allow an attacker to join the chat, and the link could be leaked in several ways (browser history, server logs, etc.). The PIN/password should be typed by the user in a text field on the page (not in the URL). The longer the PIN or password is, the more secure your system will be. However, long PIN/passwords are a pain to enter for users. You might be able to achieve good security even with short PINs and passwords if you implement a bruteforce detection system, for example, by monitoring failed login attempts and maybe block IPs when too many failed attempts have been made.
For even better security you might want to provide different credentials to different users, so if the password was leaked you would be able to identify the user who leaked it.


What about combining pkdf2 with scrypt? Possible Duplicate:
  Would it make sense to use Bcrypt and PBKDF2 together?

How does the following password hashing scheme look to you?

iterations1 = scrypt iterations required to spend 50ms on my hardware
iterations2 = pbkdf2 iterations required to spend 50ms on my hardware
ram1 = scrypt suggested default ram requirement
salt1 = urandom
salt2 = urandom
hash = scrypt(pbkdf2(password, salt2+pepper, iterations2), iterations1, ram1, salt1+pepper)
save(username, hash, salt1, salt2, iterations1, iterations2, ram1)

This solution was prompted by my reading of this article: http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html.

This is to allow me to take advantage of the great features of scrypt, as well as allowing me to take advantage of the time tested security of pbkdf2. Is it a reasonable approach? Do you think I should limit this to only use one of the two algorithms, or do you think I should only use 1 shared salt for both algorithms?

Combining dilutes your advantage. This slow-hashing business is about fighting the attacker on equal grounds, your CPU against his CPU; scrypt further equalizes things by optimizing the password hashing for the kind of hardware that you use (a PC) instead of letting the attacker optimize things on his side with non-PC hardware. If you spend half your CPU budget on PBKDF2, than that half is a bit wasted, since the attacker can thoroughly optimize PBKDF2 with a GPU.

See this answer for more analysis on the subject.

The article you quote seems to be of dubious quality. For instance, it badmouths bcrypt on the basis of alleged weaknesses on 3DES -- but bcrypt is not at all about 3DES, and there is no known attack of academic cost "80 bits" on 3DES either. I suggest that you do not trust that article too much.


How to verify data from localStorage on a server This is a cross-post from my Programmers.StackExchange post - I think this might be a better forum to ask this question. Admins - please delete either of them as you deem fit.

On my mobile app, I am storing the username of a logged in person, and downloading some data for the given/stored username. When the user checks for updates to his data content on the server, the server dishes out a delta of the content, based on the username. The app then updates its local display accordingly.

The problem is, since I am using localStorage, there is no guarantee that someone will not edit the username stored locally and try to request data meant for someone else.

What would be the best way of getting around this possible security hole? Please comment on this method that I am planning to implement:

Each time you login, a random string is generated and stored for future checking in a database, along with your username, and date/time of request.
Whenever a request to download data for a username comes in, it must be accompanied by the string from the previous attempt. Also, each fresh update for the client is accompanied by a new random string, which is stored in the database and the old one is deemed expired.
If the random string is not provided correctly, the user is logged out of the mobile app (as this could potentially be someone tampering with the app).

The advantage I see for this method is that I have an audit trail as well for later verification and forensics. What are the flaws and what could I do better?

You need to authenticate the user's mobile device (thus implicitly authenticating the suer).

I suggest that you generate a fresh, random 128-bit string (using a cryptographically secure PRNG), store that on the device, store it on a server-side database associated with the user, and use that to authenticate the device.  The device can connect over SSL and then send this 128-bit string to authenticate itself to the server.  If you are using HTTP, one very convenient way to do this is to put the 128-bit value in a secure, persistent cookie and use HTTPS.  The 128-bit string can be stored on the device permanently.  This way, the user never needs to log in again.

Alternatively, you could authenticate the device by having the device generate a fresh client cert, and then connect using SSL with this client cert.


What unique fingerprinting information can an iOS7 app collect? I'm interested in unique information that is beyond typical user knowledge or control.

As of iOS 7, users can easily protect local physical tracking by controlling radios (cell, WiFi, Bluetooth) in Control Center. There are also now explicit privacy controls for Location Services, Contacts, Calendars, Reminders, Photos, Bluetooth Sharing, Microphone, and Motion Activity, that require user consent for each app to access.

I'm particularly interested in the information an app (and its controlling server) can collect behind the scenes. IP address is an obvious one. Vendor ID and Advertiser ID are also out there, but there are ways to change those. Can apps access the device name or any other unique device identifiers (e.g., device phone number, MAC addresses)? Can non-updated apps still access deprecated identifiers such as UDID?

Without cookies, how are app makers and their integrated 3rd-party trackers fingerprinting users and devices? Especially concerning are technologies that allow others to track your activity across apps from different makers.

This is not a comprehensive answer, but as of iOS 7 the MAC address cannot be accessed anymore since the corresponding system calls return the same static value for all devices (see: https://developer.apple.com/news/?id=8222013a)


LastPass authentication grid hacked on June 15? I wonder how safe LastPass's grid authentication is. I take it that they have a copy of the authentication grid on their server. You are supposed to print the grid and carry it with you to any device that you're accessing LastPass from. If this grid was stolen (as plain text), what is its use?

As with any two-factor authentication (2FA) method, then you're back to essentially only having a password protecting your account. But with grids I'd consider the printout a greater security risk than the server getting hacked.

The thing that I find hilarious about grids as a 2FA method is that A) they are too complex to memorize, so you HAVE to have a physical copy, and B) they are super easy to take a photo of.

Some companies print 2FA grids on the back of employee badges, which means that I can turn on my phone camera, walk through the building and capture 50% of employees' grids. Dumb.


SQL abstraction layer : A preventive mechanism for SQLi? While performing a pentest for a Java based application I came across an SQL (actually HQL) error by simply putting a single quote in one of the request parameters and breaking the syntax of the query. But as the application made use of Hibernate Query Language as an intermediate layer between the application and the database, I was unable to directly access the database.

HQL does not support Union or time delay based controls which we generally exploit as pentesters. I was only able to extract all the entries from the table in question. Note that as the injection was found in a simple search functionality there was no confidential data in the table. I was unable to extract any database or system related information.

I have already looked at this question. My question here is, can using an abstraction layer like this be suggested as a preventive measure during the development phase of an application? Because in my understanding it can really minimize the damage potential of an SQLi vulnerability (At least in my given case where there is no real critical data in the database)

Am I missing out on something important here?

Using an abstraction layer is not meaningful prevention; applications that use such layers are still often vulnerable to SQL injection.

Sticking with your example of Hibernate, some ways to query are safe; some ways are unsafe. I've not actually come across an example like you describe that is partially safe, but it makes sense. I've come across several that are effectively direct SQL injection.

So, with an abstraction layer in place, you are still relying on developers to use the safe query API. This is not all that different to standard SQL interfaces (like JDBC) where there is a safe API (parameterised queries) and an unsafe API (dynamically building SQL). Either way, you are relying on developers to use the right one.

You might wonder, has someone invented an abstraction library that only has a safe API? If there's no unsafe API then there's nothing for developers to abuse. As far as I know, no such library exists, and this is because there are odd occasions that the unsafe API is needed. Remember that using the unsafe API is not necessarily a security vulnerability - the code may only be using data from trusted sources, or it may do its own sanitisation.

So the defences are:

Pick a good library, one with a safe API that is easy to use
Develop coding standards that mandate the safe API and train developers to use this
Perform peer review or static code analysis to enforce use of the safe API
Use penetration testing and WAFs as a final layer of defence


Creating accounts on sites with no security? I'm sort of confused about security on some sites. Here on stackexchange.com, for example, seem to have no security normaly, but as you log in or create an account, it uses keyexchange and an encrypted connection. However, on the site magicworld.se I noted that they use no encryption at all. Does this mean that a hacker with ease can find my password? Wouldn't that imply, that if I had used the same password on another website with security, a hacker could login to my account there?

Technically, they don't have "no security" - they are just lacking in encryption for connections. It's entirely possible that once the data reaches the server, it is stored in bcrypt hashed password fields, with full protection against XSS, CSRF and any other attack you can think of.

A lack of HTTPS connection just means that the connection between your browser and the server is not encrypted - as @Blub says, this could potentially allow someone with access to intercept or monitor your traffic to steal your password, or to change what you see (by intercepting the traffic from the server to your browser). This isn't ideal, especially nowadays, but for some systems has been considered an acceptable risk - there are probably limited uses for intercepting sites which don't have login areas, for example.

For sites with login pages, though, it's considered a more serious risk, since it can be trivial to intercept some kinds of traffic, especially when using open wifi points.

For StackExchange sites, you should be able to access them over HTTPS by adding the https:// protocol string to the start of the URL - this isn't default due to various issues with subdomains (Meta sites).

And, yes, if you use the same password on multiple sites, a hacker capturing your credentials would allow access to all of them. Don't use the same password everywhere!


How to store a file securely on the windows file system? Problem: I have a windows service running under the local system account. I have a blob of data that I want to store securely and persistently between reboots. I have decided to store it as a file( as opposed to a binary blob key in the windows registry?). Since I'm running in a service I cannot have user interaction to get a password and use something like pbkdf2 etc to derive an encryption key to encrypt the file which contains the data blob. I'm looking for the best possible way to store the file securely on the windows file system. Below is the set of assumptions that I have made on what I trust and what attack scenarios are important to be followed by a proposed implementation. It'll be great if anybody can poke holes and also suggest better alternatives.

Assumptions and attack scenarios: I assume the operating system ie windows to be trusted and secure. If a security flaw is found in windows and my secret/encrypted file is compromised, it is okay. If the admin account is compromised and the file is deleted, it's okay. However, other users without access to say windows\system32(which seems like one of the most locked down directories) should not be able to access or delete this file through code or UI. It would be preferable if the file can be stored in a location where even admin users don't have access but my service does but I don't know of such a location. Dumb admin users who delete system files are not a threat/problem. The main goal is to protect against trivial deletion and modification of the file through UI and user code.

Implementation: I plan to use windows DPAPI without using user credentials(because I can't in the local system account service) to lock it to a particular user. I plan to encrypt the file to the local system and also provide some entropy/service specific key to encrypt and decrypt the file. The app-specific entropy will be a guide plus some information that is hardware specific(such as firmware rev or other data that can be read off hard-coded hardware registers) and only my service have access to and no other software can access this information. I realize if the firmware rev is updated or hardware changed, decryption will not work but this should be a rare situation. An attacker can dump/analyze my service binary and figure out the guide but hopefully, the hardware specific information should be difficult to get to. If I do this, and place the encrypted blob In a file in windows\system32, only admin/higher privilege users allowed access to this through file system API/UI will be able to decrypt it using DPAPI(if they get the guide and hardware specific info that nobody should be able to get to) or read/write delete the file through code or UI. Storing the blob unencrypted in the registry should nearly offer the same protection against most attacks except that an admin user can modify the binary data/blob and can cause bad software behavior. DPAPI offers integrity protection so I chose this over simply writing to a secure-ish location in the registry which nobody other than admin users can get to.

Does this look okay or are there better ways to achieve this? Any other security holes to watch out for or think about? This is a fairly simple issue so I'd like to implement the simplest solution.

The most common scenario for services running independently of logged in users is to just use the file system protection provided by the OS.

Here, that means that the service has to be runned under a trusted account. A trusted account is something that only trusted users (and admins) can access. By the way, as you say in comments that you do not care of trying to defend against local admin, that should be enough. SYSTEM can be an acceptable account but (maybe because I use Unix as well as Windows) I think that a dedicated account can make things more clear. When an admin sees a folder owned by SYSTEM and accessible only to that, they could wonder what system service uses it, but when it is owned by an explicit account, the question vanishes.

Once you have choosen the account (local or AD), you only have to give access only to that account (and the admin account you use to configure that), remove all other permissions, optionaly give ownership to the specific account, and let Windows system protect the folder.


Guessing random bit with 100% accuracy I am soon to start my compulsory military service. I applied to the Cyber Warfare Unit of Finnish army. There was a test for applicants. Since the test is done the questions have now been published here: http://erityistehtavat.puolustusvoimat.fi/cyberchallenge.html
Here is question 4:

Two completely isolated programs get one random bit each from different hardware random number generators. After getting the bit each program guesses what the other program's random bit was. Programs can be different and use different strategies for guessing. After running them once, if at least one program guessed correctly, the author of the programs receives a prize.
Is it possible to devise a strategy that provides a 100% chance of winning the prize? If yes, explain the strategy.

I answered no because I couldn't figure out winning strategy. Was that the right answer or did I miss something?

There is actually a solution that will always succeed: Program A will guess the opposite of the value it receives, program B will guess the same value as the one it receives.

You can also think of that as such: A guesses that they will receive different numbers; B guesses they receive the same. One of them is bound to be correct. If you look at the following table (r for receive, g for guess), you will see that either A or B is always right (* denotes correct response):

rA | rB | gA | gB
0     0    1    0*
0     1    1*   1
1     0    0*   0
1     1    0    1*