How to analyze and pick a good crypto related lib

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
Make sure the code is properly maintained, now and in the future. This is probably the most important point.
What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.


Best practice for securing user credentials once they reach the server using Basic Auth + SSL

You need to store a hashed version of the password in your database. Upon receiving the password from the wire, you recompute the hash and check that it matches the stored version.

This shall be done this care. This answer explains it all.


I wouldn't consider any certification or course to be sufficient preparation for a hacking competition, assuming you're talking about the kind of Capture the Flag competitions that tend to run at conferences. They usually don't focus on any particular aspect of information security, but rather a broad range of technical skills.

At the last conference I attended, their CTF covered the following stuff:

Network capture analysis.
Web application penetration testing.
Reverse engineering.
Remote service vulnerability discovery.
Custom exploit development.
IPS evasion (only trivial rules, though)
Basic cryptanalysis.

This isn't the kind of stuff you can learn in a week (or a month, for that matter) at a course. Whilst the focus is on testing the technical skills of participants, a huge part of the success factor is intuition and experience. It's about having a breadth of experience in a variety of topics, with sufficient depth in some to craft complex solutions to problems.


How can storing a userId as client-side-sessions be safe?

While unencrypted, Ninja sessions are signed:

  A Ninja session is a hash of key/values, signed but not encrypted by default (see next section to enable encryption). That means that as long as your secret is safe, it is not possible for a third-party to forge sessions.

So integrity is ensured for the sessions. The warning you quoted is talking about confidentiality.


How do I check who a public PGP/RSA key belongs to?

If the key owner provided his or her actual email adress when generating the keys you can read it from the public key.

For an asc keyfile you could simply use

gpg [file]

It should also be displayed when importing the key into Gpg4Win.

Source


apparmor: How to enable dbus feature of apparmor ('dbus mediation'), in the linux kernel?

The dbus mediation in apparmor requires cooperation of the apparmor userspace, kernel and dbus daemon. All parts must contain the necessary support or dbus mediation will not be enabled.

From your description the apparmor userspace and the dbus daemon should support dbus mediation but your kernel does not. Currently dbus mediation requires an out of tree patch providing fine grained mediation for af_unix sockets that Ubuntu kernels are carrying as a sauce patch in currently releases.

The upstream kernels (including the just released 4.20 and next release 4.21) do not yet have support for fine grained af_unix mediation. Several prerequisite patches have landed in the recent 4.18, 4.19, and 4.20 kernels and the upstream apparmor project is hoping to have fine grained af_unix mediation land in 4.22


What is the difference between SSL\TLS vs certificates?

Are digital certificates part of TLS protocol implementation?

Certificates are used for authentication inside TLS but they are by themselves not part of the protocol specification. Certificates are a concept not an implementation so they are not part of the protocol implementation either, although using certificates for authentication is part of the protocol implementation.

  Is the padlock green icon on my browser has to do with TLS use or digital certificates?

Both. It signals a successful TLS connection against a trusted site where the trust comes from the certificate. Note that this trust does not mean that the site is secure by itself or that it will not harm you, it only says that the browser connected to a site which provides a certificate matching the URL, i.e. the expected site and not some man in the middle.

  If I use a service like Let's Encrypt to issue a certificate for my web server, how can I determine the TLS version used?

The used TLS protocol version is independent of the certificate.


If a login/session cookie is stolen,does changing the password void it?

It really depends on how the server is implemented; you cannot count on either behaviour. For some servers, changing the password will invalidate the cookies; for others it will not.

On a typical server, there is a database with a table of users, and another table maintains the mapping of cookie values to user identities. With such a setup, changing the password alters only the first table, and it would take some extra effort from the programmer to also prune out the cookie values from the second table, which map to that user. Programmers are allergic to effort so chances are that in such a site, changing the password does not invalidate the cookie.

But some other sites merge the two tables, so that each user has one active cookie value, in which case voiding it upon password change is quite easy (a few extra characters in the SQL statement); then there is a roughly 50% chance that the programmer thought about it and bothered to add the few extra characters to his SQL statement.

Of course, Gmail cannot be assumed to be really "typical". So anything goes. You might want to try it:

Log in with your Web browser.
Close your Web browser (the process, not just the window).
With another, distinct browser (or from another computer), log in and change your password.
Reopen the first Web browser. See if it is granted access without entering a password.

Then you will know.


These estimates are very crude and, arguably, don't make sense.

Asymmetric cryptographic algorithms, like RSA and ECDSA, are based on mathematical structures, and breaking them requires unraveling that structure. Generally speaking, the difficulty of doing so raises with the size of the underlying objects (i.e. the "key size"), but not in an easy, simple, exponential rule.

A lot of efforts have been expanded into making some "strength estimates" to be able to compare RSA key sizes with ECDSA key sizes, and also key sizes for symmetric algorithms (like AES). It is very hard to even define properly, because breaking a RSA key through integer factorization with the best known algorithms for that task (General Number Field Sieve) requires not only a lot of computations, but also handling an awful lot of data with access patterns that are not amenable to serialization and parallelism -- to say things plainly, you need a computer with a really large amount of very fast RAM (we are not talking mere terabytes here). This does not compare directly with, say, AES-key breaking, which needs a lot of CPU but has no need for RAM, and is embarrassingly parallel.

Nevertheless, some smart people still have produced estimates, and there is a nice Web site that presents them and let you tweak the parameters. For instance, if you look at the NIST recommendations, a 2048-bit RSA key is deemed "somehow equivalent" to a 112-bit key for a symmetric algorithm, while a 3072-bit RSA key would rate as a 128-bit symmetric key. Symmetric keys are just bunch of bits with no special structure, so an n-bit key means "can be broken in effort 2n-1 on average" (by enumerating possible combinations of n bits until the right one is found). Therefore, per the NIST estimates, RSA-3072 is deemed to be about 65536 times stronger than RSA-2048 (because 128-112 = 16 and 216 = 65536).

Other equations yield different results. The method explained in RFC 3766 rates RSA-2048 as equivalent to a 103-bit symmetric key, and RSA-3072 up to 125-bit. Now these estimates would imply that RSA-3072 would be more than 4 million times harder to break than RSA-2048 (2125/2103 = 4194304). Let's also note that RFC 3766 says that RSA-2048 is then half a million times weaker than what NIST says it is.

I can also be said that a simple statement such as "RSA-3072 is X times harder to break than RSA-2048" can make sense only if you can quantify the hardness of breaking RSA-2048 and RSA-3072. The quantification is: how much money would it take ? And, right now and also for the foreseeable future (i.e. within the next 40 years), the only sane answer is "forget it". No amount of money on Earth, even with all the existing money taken together, will buy you a RSA-2048 key break or a RSA-3072 key break. This is simply out of reach of our technology.

This does not mean that RSA-2048 will be forever unbreakable; it only says that if (or when) it is broken, it will be through a qualitative enhancement (an algorithmic breakthrough) whose characteristics are, by definition, totally unknown.

Correspondingly, any assertion about RSA-3072 being "10 thousand times" stronger than RSA-2048 are mostly unsubstantiated speculation. Or, at best, a mathematical extrapolation from existing data points, raised to levels that make no physical sense.


A virus or a trojan are pieces of code which automate an attack, and propagate more or less automatically (the terminology is a bit sloppy). First there must be a vulnerability which can be exploited to run malicious code on the target. There are many kinds of vulnerabilities, including a gullible user who will "open executable attachments" (the core principle of many a trojan), but there must be some. Then, the virus/trojan/malware brings it up to a higher level through automation.

With a vulnerability, the attacker gains some control on one car. Most attackers will stop there, because they are car thieves and don't want to take the control of any other car than the one they are standing next to. Even more so, they don't want to steal a car which is "too much damaged", be it mechanically or logically.

A car virus, "infecting" a lot of cars, would allow for large-scale heists, e.g. plunging a whole car-loving country into pedestrian chaos, or blackmailing authorities with the prospect of killing random drivers (gee, when I write that, I almost hear the voice of Bruce Willis cracking jokes while shooting villains). While this would be a great Hollywood scenario, I expect massive car-stealing to occur first. We will get warnings.

A redeeming property of cars is that they are not electronically centralized, not in the same was as a smartphone. An iPhone has a single big CPU which does everything. A car has dozens of small CPU, each responsible for one or two tasks. Though they are linked together, they still have a lot of autonomy. A remote exploit on a car would probably allow for shutting it down, or blinking lights, but not override everything. Car manufacturing regulations are also adamant: come what may, the driver must still be able to brake by heavily pushing on the pedal, even in case of a total collapse of electronics, e.g. after having been hit by lightning. The hand-brake, also, is supposed to be entirely mechanical, with no electrical part. As long as these properties are maintained, you cannot be abducted by your own car, even if it has "automatic driving" abilities.


I'm quite sure you will be able to recover  "some data" from the magnet stripe - likely even all the data that's on there. However, you won't be able to withdraw any cash with a copy of that stripe because nowadays use the information on the chip, which is much safer as it is much harder - close to impossible, I would guess - to copy that. The only thing you could hope for is a store with an old terminal, but then you have to give your copy of the card to a person...

As for the chip, if you don't have the means of an intelligence agency or something like that, you won't be able to repair it. (The chip is not just a "data store" that is to be read but a device that can answer cryptographic challenges.) Same thing should apply for contactless payment.

Thanks for the comment: I'm referring to the situation in the European Union, namely EC-cards, which are most common over here.


You guessed well: revocation is asynchronous. When you revoke a certificate, this becomes really effective only when the last pre-revocation CRL expires. If you issue CRL that are valid for one year, then a revoked certificate may still be trusted by other systems for up to one year.

One should envision CRL as a damage containment feature: with CRL, you can have an explicit boundary on how long the compromise will impact your systems. Long-lived CRL are easier to issue (since you do that less often), but correspondingly take more time to contain the damage. This is a trade-off.

The only mitigation, within the context of an X.509 PKI, is to issue CRL more often, with a shorter life. However, since your root CA is offline (and that's, all other things being equal, a very good idea), issuing a CRL implies a manual operation, hence costs. I am aware of two workarounds:

You could make an indirect CRL: while the root CA is offline, the power to sign a CRL could be entrusted to a distinct, online system with its own key pair. X.509 has support for that, with relevant extensions (see this answer). Unfortunately, indirect CRL are not well supported by existing software.
One could make the root CA half-online. In a setup that I have helped develop and is currently deployed in production, the "offline" root CA produces a CRL on a weekly basis, and sends it over... its audio output. The idea is that the "line out" plug is physically one-way, so even if there is a wire going from that plug to the "line in" plug of another (online) machine, the root CA can still be considered to be "offline". Moreover, a visual inspection can easily notice that the wire is in the right plug (the green one).

This solution requires some software to encode the new CRL as sound, and decode it back on the other end; the simple code I wrote offered very bad performance (about 300 bits/s), but it was very robust, and the weekly CRL is very short (since it is, under normal conditions, completely empty). Since there is no acknowledge (the link is really one-way), the sender must send the same file repeatedly, again and again, with a recognizable header for synchronization, and a checksum for error detection (for a CRL, you could verify the signature; that's as good as any checksum can get). That way, you can have an offline root CA and still get automated CRL publication on a weekly basis (it could even be daily).

(My initial design called for an actual speaker and a microphone, but that could prove problematic in a noisy environment, and server rooms are very noisy. People with some electronics skills could build a circuit with a LED and a photodetector. Yet another way is to use a twisted-pair ethernet cable with only one pair connected, but this may fail to work with ethernet interfaces that try to do medium detection; and it is harder to visually check, since you have to unplug the cable to check the wiring.)


Do large online software companies limit employee access to company information?

The basic rules that the big companies follow aren't very much different from the rules/recommendations by popular infosec standards (e.g. ISO27k):

Segregation of duties - separation on services provisioning, development process, or any other part of IT services, so different people are responsible for the various components/stages of service delivery, development, provisioning, etc.

For example - one team is responsible for hosting/systems provisioning, another team is responsible for product development, a third team is responsible for storage/databases, etc.

Overall, no single person has access in a way that may lead to the whole process being compromised. However, this measure alone is not sufficient for obvious reasons (didn't help in the case of Ed Snowden).

Least privilege principle - as you already mentioned, any employee is provided with the minimum credentials necessary for them performing their duties.

This is another measure that on its own won't help completely eliminating the risk of ex-employees or current employees from compromising the integrity, confidentiality, or availability of the information (again, didn't help in the case of Ed Snowden).

Have good asset management program - know who has access to what. Having a current and clear picture of who has access to what can help in the next stage.
Account lifecycle - have processes in place that run when employees leave, ensuring their credentials are revoked.
Encrypt! And have a solid key management process.
Look after the intellectual property (IP) - as much as software patents are debatable, and lawyers aren't the people I'd like to rely on, having the company's IP secured definitely helps (patented, registered or otherwise copyrighted).
Background checks. Small businesses can't usually afford proper background checks, but the big ones definitely do their homework in this department.
Run a data leak prevention program (a mix of solutions, procedures and monitoring).

These are just some of the basics that would limit any potential risk of damage that an employee (or ex-employee) can cause by using their insider knowledge. You can't erase what employees know (e.g. system architecture, protocols, etc), however the folks that typically have access to the keys of the castle are not just starting their careers, so any potential traits that would make them less-than-trustworthy would show up during some of their previous employment cycles, or during their probation.

No organization can eliminate the risk completely, but following common sense approach, combined with strict adherence to infosec standards can save you a lot of trouble in the long run.

With regards to specific measures within large corporations, each one is a bit different, since there are substantial differences in their culture, in their governance and their general risk apetite. There's no silver bullet, and they still need a good incident management process to respond to whatever they have missed :-)


This issue has been fixed in the latest release (2.3.3.1).

The challenge sent was not the one displayed.

In the future, please take the time to send us a bug report on github: https://github.com/lgandx/Responder

We'll fix it asap.

Thanks!


Is there a typical step-by-step A-Z process for testing a Web site for possible exploits?

The OWASP guide is the closest thing to a defined methodology, most testers operate using gut feel and experience imho.  I like that OWASP methodology, but I do think it misses a big chunk of testing around application logic flaws.

If you are looking for a starting point to develop your own internal methodology, take the OWASP one, remove areas that are not relevant to your testing, and adapt it.

I believe that the Penetration Testing Execution Framework (PTES) will be one to watch.  It is still early days, but I look forward to seeing what the output of that project is.  This can be found at http://www.pentest-standard.org


There are plenty of places that have Wi-Fi systems riddled with problems and if you are using them a lot, I would say - NO that's not enough by a long way.

My reasoning is that HTTPS is hard to get right and relatively easy to break. In addition, you are still leaking a fair bit of information when browsing over HTTPS.

Apart from the usual protections (anti-virus, etc). Running the latest OS fully patched. Using full disk encryption. That is the starting point. BTW, if using Windows, do yourself a favour and make sure it is W10 latest version.

Next up is hardening your browser. Firstly get a great ad-blocker - too many drive-by attacks now come via rogue adverts.

But the thing you should most invest in is a VPN solution. This is really the only realistic way to retain a good level of security when travelling a lot. Run your own or buy a decent 3rd party solution but that's the need.

If you are travelling to certain locations and have high-value data on your PC, even that may not be enough. In those locations you need a hardened VPN solution that kicks in before login. You should also ensure that you never walk away from your PC with it left in standby or on the login screen.

Oh, one other thing. Check local laws before you go. I think everywhere in Europe is OK but in some other countries, it might be illegal to use some of that technology. Also be careful if you take the same laptop from Europe to the USA. US Border staff are notorious for demanding access to laptops and that could put you at odds with the EU data protection laws. Better in those cases to empty all data from the laptop (with a secure delete program) and then securely download it (via VPN of course) when in-country.

Enjoy your travels!


Acquiring remote forensic image from EC2 instance

An EC2 system is relying up on Elastic Block Storage (EBS).  Then you can take an EBS snapshot of the system, and download this image.

You now have a full disk image locally, and you could run the instance it within a VM,  or whatever.


What does the question mark in nmap output indicate?

If Nmap isn't able to identify the service based on the signature of its response to the probing it falls back to port identification. It checks the port against a list of known port-service pairs.

So the question mark indicates that the identification was based on the port number rather than response signature.

You can find the full list in nmap-services


You can insert a subquery in place of the injection point. For starters in case of mysql

Select concat(version(),user(),database())
Select grantee from information_schema.USER_PRIVILEGES

Also check out for sql-map tool


Both are same kind of attacks. The difference is Eavesdropping could be in any form (Physical to logical), where the sniffing is more electronics/network related term.


What is the use case for antimalware manual scans?

There are lots of reasons why you would want to manually trigger a full system scan.
No real-time scan is going to be perfect, and it can be easier to detect some malware when it is not running. So, if you suspect you might have malware, you can manually update the software and trigger a scan instead of waiting for the scheduled scan or hope it is picked up in a real-time scan.
You can also scan a portion of your system, like a directory or mounted storage media.


Are there any feasible ways to block the stunnel utility at the network level?

Since you exclude SSL interception (i.e. no certs can be installed) and also exclude any kind of traffic pattern analysis there is not much left. What could be tried is analyzing the TLS handshake itself:

TLS stacks and also applications using TLS often leave a usable fingerprint in the ClientHello, i.e. which protocol version, which ciphers are offered in which order, which extensions are used and which order etc. Nothing new and lots of information can be found about this. Of course, a client could in theory replicate another clients ClientHello perfectly to hide itself.
Similar passive analysis could be done for the server side. But the variety of server configurations which are reflected in the TLS stack is much larger than on the client side, so this is probably not as effective as analyzing the ClientHello.

To make it clear: this is just heuristics. It can cause false positives and it can fail to detect stunnel instances. This is especially true in complex networks with a variety of different clients and only few time to manually analyze if a specific uncommon fingerprint should be allowed in general, to a specific target or should be blocked.


How do I prevent XSS in direct access to AJAX/JSON APIs?

Setting content-type to plaintext or JSON and not HTML?

If the API returns JSON, then you should the content type to application/json. Apart from just being correct, this will also stop any XSS issues. If a user navigates directly to an API endpoint in their browser, the browser will just show the raw JSON and not try to render any HTML or run any scripts.


Security risk of leaving bluetooth on all the time on an Android 10 phone

I'm not very sure of how Android 10 changes things when it comes to threats related to leaving your Bluetooth on, but there are many already discovered attacks which can lead to leaking of your sensitive data or even losing control of your bluetooth device (Not just your phone).

Some of these attacks are -

Bluejacking -
This type of attack entails unsolicited text messages, mostly advertisements that people usually don’t want to see. With Bluejacking, leaving your Bluetooth on exposes you to aggressive (and very ineffective) marketing tactics, but it doesn’t pose a threat to the device itself.
Bluesnarfing - Unlike bluejacking, bluesnarfing is an actual threat to your security. Using this method, criminals can break into people’s devices and gain unauthorized access to their data. They can see the text messages, steal contacts, and most alarmingly, get their hands on people’s passwords. Successful bluesnarfing results data and identity theft.
Bluebugging - When criminals gain access to a person’s’ contacts, they can use them to send text messages and place calls from the phone without the user being aware of it. That way, they can spread bugs and viruses to a lot of people at once and break into hundreds of other devices.
BlueBorne - The most dangerous attack since it is not limited to just your phone. More precisely, they can take control of the device, infect it with malware, or steal data. But it’s even more unnerving that BlueBorn can affect all vulnerable Bluetooth devices within an area without anyone ever noticing that something’s wrong.

You can read more about them here


Can Apple technically intercept iMessage messages

If you make use of Apple's iMessage service then you are implicitly trusting Apple, as they wrote all the code that you are running and therefore could make it do anything they want it to.

So either you believe their statements, in which case iMessages are encrypted end-to-end and all is well, or you don't trust them and you should probably not use iMessage.


If I understand your question, you do not actually need to authenticate the users, you just need to make sure that the client web site considers them to be authenticated.

Your basic approach looks correct to me. The client website just needs to sign the user's token which includes whatever information you need (user id or whatever).

The main vulnerability would be somebody using an old identity or some kind of replay attack. So, you want to have some kind of time stamp or sequence number to make sure that authentications are new sign ins, not recycled ones.


How can the private key be obtained in PKI without alerting a third party?

Ardi does not obtain his private key from the PKI. The PKI obtains Ardi's public key from Ardi.

Ardi owns a public/private key pair: a public key and a private key that "dance together" (they are two mathematical facets of a single object). The public key is meant to be public. The job of the PKI is to publish the public key, and offers some verifiable guarantees that a given public key is indeed Ardi's public key -- i.e. that the corresponding private key is under exclusive control of Ardi. In all of this, Ardi's private key never leaves Ardi's computer.

(To be complete, there are PKI models where the CA insists on generating the public/private key pair, and transmits the private key to Ardi through some one-time secured channel. This is a valid model for keys meant for encryption, because it allows the PKI to make a backup of private keys to avoid risks of data loss in case Ardi's computer burns down. However, the "normal" PKI model is that the key pair is generated by the key owner, the private key never being seen by the CA or anybody else.)


Verifying physical address via a verification service provider. Are there any threats?

Without knowing what your service does, it could very much be a breach of privacy.

Suppose you are building this to verify parts of an identity in the healthcare industry.  Suppose it's for a very specific purpose -- e.g. verifying addresses of patients in certain conditions or under-going certain procedures (HIV/AIDS patients, abortions, etc). If someone were to intercept that information they could conceivably find those people and harrass them.

Or maybe your service sells something, and your competitors can intercept address information. They could start advertising to the addresses, which is an indirect violation of privacy (the person at the address didn't necessarily allow anyone else to get their address from you).

I would consider this a breach of privacy.


Why do X.509 certificates have "Key Usage" attribute?

Strictly speaking, a key should not be "multipurpose". Distinct key usages call for incompatible key life cycles. The Key Usage extension is a formalism of this fact.

For instance, keys which are used for signatures and authentication could be lost with relatively low consequences: if your smart card is destroyed, you can no longer sign, but no data is lost; you just need to be issued a new smart card (this is inconvenient, but no security breach occurred). But you do not want people to begin to encrypt data with that signature-only public key, because in that case you need to make backups of the key, to avoid data loss upon key loss -- the smart card will strongly oppose to backups, by construction. The Key Usage extension documents the idea that a signature key is to be used for signatures only because it won't be backupped. Conversely, an encryption key will normally be escrowed somewhere, and thus you do not want people to consider it as binding if it is used for signatures: this would allow whoever has access to the escrow/backup system to sign "in your name". There again, the Key Usage extension protects against that.


Is it required to have the same Domain Name and Common Name for SSL Certificate?

The domain of the URL must match the subject of the certificate. In former times this could be either by setting the domain as CN of the certificate or by having the domain set as a subject alternative name. Support for CN was deprecated for a long time (at least 17 years, see RFC 2818) and Chrome browser will not even look at the CN anymore so today you need to have the domain of the URL as a subject alternative name. Note that there can be multiple subject alternative names and thus the certificate can be used for multiple domains.


What are the problems that Chip card technology solve? and what are the problems EMV solve? Are the separate things?

A chip card (or smart card) is generic term for cards containing a microprocessor. You can think of it as a highly embedded computer. They might even run their own operating system.

EMV on the other hand refers to a certain standard for these kind of cards for payment transactions. Note, however, that smart cards can also be used for different applications, e.g. they are used quite heavily in the Pay-TV sector - at least here in Europe. Another field of application is the corporate environment, where smart cards may be required for logging into some services.

Smart cards are usually used for authentication. More specifically you prove to the other party that you are in possession of some sort of secret. The advantage over purely passive hardware (e.g. a magnetic stripe) is that the secret itself is never revealed. It is only used as a basis for all sorts of (cryptographic) operations, e.g. digitally signing a transaction. Furthermore these cards are usually built in a way that they can't be tampered with, at least not without spending a lot of time, money and effort.


Using smart cards for email encryption and SSH

I'm really keen on what the Yubikey Neo does because it has so many open / generic modes (such that I've bought two), including presenting a CCID interface, OpenPGP supporting application on the card, and offering open source and specification U2F support.

I think what you're ultimately looking for is CCID + a card with the appropriate applets. OpenPGP cards may be enough for this.


Because even if you've secured your private key with a strong passphrase, the passphrase is the only protection of the key.

And since the encrypted key is only one part of an equation (your passphrase is the other half) it only needs enough computation power to bruteforce "crack" that key.

So, the key is as valuable as the passphrase to it.


Scanning private IPs from outside network

Not using a VPN or some other way to be connected as if you were local the answer is no but not because of a limitation in Nmap or any similar tool. The primary reason this won't work is because the IP range you are talking about, 10.0.0.0/8,  is considered a private internet address range per RFC1918 which is not supposed to be routed over the public Internet. In almost all cases this means it will likely be Null-Routed by all the Internet Service Providers routing traffic between your location and the potential target IP's and you will get "no route to host" warnings at best.

https://tools.ietf.org/html/rfc1918

That said there are many situations where networks are misconfigured and some connectivity leaks out a very short distance. I've seen this on small providers of metropolitan Ethernet networks and also with misconfigured MPLS networks but these were technically local connections to where I was and not something that could have been reached over the global Internet at large.


How to check if our clients were compromised by security breaches in other web applications?

Web security guru Troy Hunt has a site called have I been pwned? which checks an email address against those associated with a number of breaches. The passwords gleaned from the breaches are not retained there, so it's useful for determining if an account may be affected but does not disclose what the passwords or hashes were that were stolen.


Theoretical and practical limits on adblocking

Taken to the extremes it could deteriorate into an arms race which the client (person reading the site) could always win.

Yes the publisher can check that the reader is showing their ads, they can examine the DOM and return is the ad is visible.

Then the adblocker could modify this call to all ways return true to the publisher.

Then the publisher could require the client to return a hash of the content and the DOM model.

Then the adblocker could calculate this hash itself.

Then the publisher could do a advertising CAPTURE to ensure a human has read and understood the ad.

Then the adblocker could outsource solving of captures either to low paid human contractors or AI.

Etc etc.

As the adblocker is in control of the client it would be hard to defeat. Well before this level has been reached it will become uneconomic for one or both of the parties to continue.


Whats the probability of a personal computer being hacked?

If you properly follow the recommendations and standards that you've mentioned here, you should be reasonably safe, as long as you also keep your software up to date. It's arguably more important to install updates for PDF readers, Adobe Flash, Microsoft Office, etc. than the OS updates, because those are where most day-to-day attacks are focused.

A few other suggestions:

Use a sandbox for read-only stuff, like opening PDFs. That way, even if a document is malicious, the chances of your machine getting compromised is significantly reduced. Sandboxie is nice.
Send any suspicious PDFs through VirusTotal. It has some specific exploit detection tools that it runs on PDF documents, which are very good at catching suspicious documents even if the exploit vector is not yet known to AV vendors.
Don't ever assume that your AV will catch malware. Studies over the last 5 years or so tend to show that each AV software package catches around 30% of malware. Aggregate tools like VirusTotal have better results, but it's obviously infeasible to run every file you download through it. Keeping your AV up to date helps, but technology is not a panacea.
Protect any sensitive documents with TrueCrypt. It won't prevent malware from stealing files from a mounted volume, nor is the password screen invulnerable to keyloggers, but it does reduce your chances of having important stuff stolen as long as you don't open the volume whilst infected.
Make regular backups. Getting owned is, sadly, a fact of life. If your machine gets infected, the only way to be sure is to nuke it from orbit and start over. Even worse, ransomware might corrupt your documents and demand a large fee in order to recover them. The cost (time and money) of implementing backups is far less than the cost of recovery when you lose all of your data.


Automated tools for applying formal methods to verify security policy in existing software

Wrote about formal methods and security many years ago here -- http://www.tssci-security.com/archives/2007/11/23/formal-methods-and-security/ -- the basics of which is how to apply old-school Orange Book standards to modern software.

If I had to rewrite that blog post in 2015, some of the updates I'd add are that SMT-based model checkers have become a lot more diverse, integrated, and advanced than the simple ones I outlined (SPIN and JPF). These pages should lead you towards some of these advancements -- http://kind2-mc.github.io/kind2/ -- http://smtlib.cs.uiowa.edu -- http://www.persistencelabs.com/research/

DARPA is working on a Crowd-Sourced Formal Verification (CSFV) project here -- http://www.darpa.mil/program/crowd-sourced-formal-verification

While I'm all for automation, it would be interesting to hear more about the problem domain to make secondary recommendations around manual testing. Is this for e-commerce web and mobile based authorization problems? Which domain(s) are involved?


False acceptance rate in biometric authentication for sensitive information

Apple Touch ID has an FAR of 1/ 50,000  while Face ID has a FAR of 1 / 1,000,000

https://support.apple.com/en-us/HT208108

Android also insists on having an FAR of not higher than 0.002% (1 in 50,000). (Source: Android 7.0 Compatibility definition document)

A company called Eyeverify has a very relevant blog on this topic. They too seem to suggest that an FAR of 1 in 50,000 is good enough and they have clients in the banking sector.

https://www.eyeverify.com/blog/ceo-editorial-a-call-for-payment-grade-industry-standards


How can I delete a password and lock the account in one step?

You may want to try:

usermod -p '!!' root

usermod with the -p parameters takes the raw value to bet set as encrypted password in the /etc/shadow files.

The traditional usage of this parameter is to give to usermod an already encrypted password, but it accepts also the '!!' flagging the account as locked.

In the end, this command will remove the current password and leave only the exclamation marks setting the root account as locked in the passwd way¹, all in one move using a safe and standard command, thus fulfilling the request.

¹: According to this discussion, there is no established standard on the way to lock an account. So usermod -L uses only a single exclamation mark (!) in front of the hashed password to lock it, while passwd -l uses two (!!).


How do I convince others of the importance of password management?

Your wife is not using LastPass because she has better things to do, not because she's incapable of realising its utility.

You would think that once people properly understand the risks they're exposed to (which requires a serious amount of education), they would automatically start to comply with whatever security advice is thrown their way. Well, this assumption has been proven wrong multiple times. See Herley's 'So long and no thanks for the externalities', which has a couple of examples of wasteful security, and Beautement and Sasse's 'Compliance Budget' for a general theory of how humans behave with regard to security.

In economics of information security, there are several examples of people willingly taking risks because it saves time they need for other tasks, or because they perceive potentially negative side-effects to complying (such as being locked out, or embarrassed in front of someone else).

Hence, rather than insisting on your wife doing what you think is good for her, identify her needs, her priorities, her worries and her actual problems. Then, deploy a tool that does work for her (if there's any) and work with her to make sure she knows how to use it and perceives its utility and limitations properly.

For instance, I don't use password managers because I use some of my accounts on so many devices that I have to know the passwords, because I have some passwords that have to comply to such silly policies and be changed every other day (and I hate having to resync my passwords on each device), I don't trust online password stores the least in the world, and because some of my devices are targeted often enough that I don't want them storing many passwords. Most of these problems I have are probably addressable one way or another, but I don't want to lose a day of work setting up processes that go against my habits. And yet, I'm a security engineer. In conclusion, most users will prefer appropriateness and value to security in most decision-making situations.


Can UNIX Domain Sockets be locked by user ID?

I currently assume that a connection to that socket originated from a process that is running on the very same server

Correct. Filesystem sockets must be read by a process that has access to the file.

  Can I also assume that the only users who can access that socket are me, and root?

Yes. Since me is the only user with permissions, they are the only ones who may enter that folder and view the socket. root, of course, is root.


After trying successful SQL injection why the result isn't getting displayed on the webpage?

There are possibly two issues with your attempt that cause it to fail:

Syntax for MySQL comments to the end of the line --  requires a whitespace or control character following the double-dash:

  From a “-- ” sequence to the end of the line. In MySQL, the “-- ” (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.4, “'--' as the Start of a Comment”.

PHP’s mysql_query function does only allow one single statement:

  mysql_query() sends a unique query (multiple queries are not supported) […]


In your specific case, there's a different answer: never carry sensitive data through a border.

Border agents almost always have enormously wide legal powers to search devices on their own, and are very happy to utilise them when asked to by intelligence agencies.

In fact, if you expect to be subject to a targeted attack by an intelligence agency, I would go further and advise you to not even carry an empty smartphone through a border, because of the risk that it is taken away, compromised, and returned to you.


Does the password manager store the passwords in memory if I lock my computer?

For as long as it is in "unlocked" state, a password manager will need to keep in memory "something" that will grant it access to the secret data.

Depending on the architecture of the password manager, it can be a number of different things:

Pure client-side software could keep the whole database (unencrypted) in memory. This is acceptable from a security point of view because the security model of these software is that it will not attempt (too much) to protect against root-level compromise of the computer where they run.
Another method for client-side apps is to keep the decryption key in memory and decrypt the relevant data as needed. This is usefull if the secret part of the DB is large: only decrypting the information when needed helps cleaning it up afterward and ensuring it doesn't end up in the swap file (if applicable).
An additional approach is to keep the data in memory but encrypted with a session key and decrypted when accessed. This allow for a quick way to "clean" the memory when locking the system (just remove the session key)
Distributed apps can keep an access token in memory instead. That access token is then used to retrieve the relevant data from the server. Typically, a second key, which must be kept in memory, is then used for decrypting the result.

In addition, password manager apps can remove all encrypted information from memory under some condition. These conditions can (and usually do as an option) be triggered when you lock your workstation.

In the end, the actual answer depend on what software you use and how you configure it.


Security impact of using a public password for free WiFi

After some discussion with @epeleg in chat, I think I may have a more thorough and (hopefully) clear answer.

TL;DR: The protection afforded to a Wi-Fi network by encryption with a PSK is directly proportional to the complexity of the PSK, and the effort taken to safeguard that PSK.  For any environment, this requires striking a careful balance between security and usability.

Lowest Security/Easiest Usability: No encryption.
Highest Security/Hardest Usability: WPA2-AES, high-complexity PSK, MAC address filtering, Wireless Intrusion Detection/Prevention System.  Require user & device registration for access to PSK and addition to the MAC filter.

If you intend to provide free WiFi as a service to the community, the balance is probably somewhere in between these - and likely leans toward the former solution.  However, even the latter of the above options is very doable if you are willing to put in the effort.

Still, protecting a "free WiFi" network by any means doesn't so much prevent attacks outright as it does make them more difficult.

Encrypting network traffic on the WiFi connection is always more secure than sending the traffic in the clear.  While not impossible, it is very difficult and time-consuming for an outsider to translate WPA2-encrypted traffic into cleartext.  However, most encrypted SOHO and "Free WiFi" networks must rely on a passcode, or Pre-Shared Key (PSK) to protect the encryption mechanism.

The amount of protection offered by implementing a password in any system will always vary in direct proportion to the password complexity, and the effort taken to protect that password.  Wireless networks are no exception.

To try to simply express how this relates to your "Free WiFi" situation, I'll give a few possible configuration scenarios and the benefits/drawbacks of each:

Scenario:  Your network is left fully unsecured.  Anyone within range of the AP can just hop on and enjoy the free WiFi.

Benefit:  This is the easiest for anyone to use and requires practically no administrative overhead.
Drawbacks:  This is the most vulnerable network of all.  All traffic that does not otherwise use an encryption protocol (such as HTTPS) will be sent in the clear.  This network is easy to sniff, spoof, and otherwise manipulate to the benefit of even very inexperienced attackers.

Scenario:  Your network is protected with a strong PSK, using WPA2 for authentication and encryption.  You have posted the SSID and PSK in a publicly viewable location.

Benefits:  The data on your wireless network is encrypted, and nobody can read the data or connect to your wireless network without the PSK.  This network is also fairly easy for the end-user to join, and requires little to no administrative overhead.
Drawbacks:  Having the PSK publicly accessible in this manner makes it trivial for anyone within range of the network to just grab it and hop on.  Attackers will not likely be much deterred by this method.

Scenario:  Your network is protected with a strong PSK, using WPA2 for authentication and encryption.  You have posted advertisement of the Free WiFi service in a publicly viewable location, which includes contact information for potential users to obtain the password.

Benefits:  The data on your wireless network is encrypted, and nobody can read the data or connect to your wireless network without the PSK.  With this method, you have personal contact to one degree or another with every user - this helps to somewhat disenchant them of their sense of anonymity on your network.  This may help deter some would-be attackers who would rather move on to a less secure network, than go to the trouble of contacting someone for your PSK.
Drawbacks:  This requires that someone is available within a reasonable amount of time (include the timeframe in your advertisement) either via phone or e-mail to give users login credentials.  Users may also circumvent this measure by simply passing the PSK peer-to-peer.

Scenario:  Your network is protected with a strong PSK, using WPA2 for authentication and encryption.  You have posted advertisement of the Free WiFi service in a publicly viewable location, which includes contact information for potential users to request access.  You have also implemented a user and device registration process which includes an Acceptable Use Policy, contact information for registered users, and MAC addresses for all devices.  You have also implemented MAC address filtering on the AP, and monitoring/logging services on the network.

Benefits:  The data on your wireless network is encrypted, and nobody can read the data on your wireless network without the PSK.  Nobody can connect to the wireless network without both the PSK and a registered MAC address.  With this method, you have the ability to see if/when your network is being inappropriately used and by whom.  You also now have an agreement in place which informs your users that inappropriate use will not be tolerated, and which may absolve you of some legal responsibility if such use occurs.*  Potential attackers would much rather find an easier victim than go through such a thorough process, especially when they read the clause of the AUP that mentions monitoring is in use.  Users will not easily be able to circumvent the device registration by simply passing along the PSK.  You can also revoke a user's access if necessary, by de-registering their MAC address(es) and/or changing to (and distributing via registered user contact info) a new PSK.
Drawbacks:  Of all these scenarios, this requires the most administrative work.  This will require that someone is available within a reasonable timeframe to perform the complete user registration process - gathering personal information, gathering device information (helping users who don't know how - and most probably won't), archiving the paperwork, and registering new devices with the network.  To be fully effective, it will also require that the logs be checked on a regular basis for suspicious activity and/or having some form of IDS/IPS in place.  Attackers who obtain the PSK will easily be able to spoof the MAC addresses of other registered devices to either bypass the device filter, or pose as that device's user on the network.

In all scenarios, there are a few things that should be kept in mind:

By providing unconditional Free WiFi, there is always the possibility that you may be allowing a malicious user onto your network regardless of what registration or PSK distribution process you put in place.
For all PSK-secured WiFi systems currently existing (WEP, WPA, WPA2) there are known attack vectors that allow an authenticated user to sniff the traffic of other users on the network as if it were in the clear.  (Provided, of course, that the traffic is not encrypted by other means such as HTTPS.)
Make sure the administration interfaces of all your network equipment are protected by strong, non-default passwords which are not similar to any PSKs you distribute.
Depending on your local jurisdiction, you may be held liable for the actions of those who use your WiFi network.*
Your contract with your ISP may not allow promiscuous sharing of your Internet connection.

Lastly, to address your final query:

  Can a hacker do more damage on a wifi network that has no password then he can on a network that does have a password that the hacker knows ?

When it comes to unconditionally Free WiFi networks, it's not so much a matter of how much damage the attacker can do as it is how easily he can do it.  I hope I've clearly addressed the latter, above.

*I am not a lawyer, and this is not legal advice.


A partial list of things to think about:

Do you support multiple connections at one time? What happens when you get a new connection request while another is pending? What happens if you get more connections than you're expecting? If you (or VERTX or Java, without your knowledge) dynamically reserve memory can too much be reserved (stack smashing: execute arbitrary code)? What happens if a client breaks the connection before you respond: do you properly clean up?

What happens if the client gives you too much or unexpected input? If you have a 1024-byte String to hold the requested URI but the client requests a 1200-byte URI, where do those extra characters go (buffer overflow) (not just the URI but any data the client gives you, like User Agent)? What happens if the client requests ../../../etc/passwd (path traversal; I know you don't intend to open files, but...) or non-ASCII characters (did you reserve 3 bytes because the string has length 3 characters, but they are all 2-byte unicode characters)?

Is there any sort of input that might get handled by the libraries you use in a way you don't expect (e.g. maybe VERTX sees a URL request for file:///etc/passwd and decides to handle it for you)? Or the opposite problem: are you close enough to the physical layer that you need to handle things like fragmented packets?

What happens if the client's IP address is spoofed to make you send replies to the wrong computer (relay attack)?

What happens when you decide none of these issues affect you now, then next year you use this platform as a base for another feature but forget to re-run your security analysis first?

Stretching your question a little: what happens to your users if the appliance is hacked by other means and your HTTP server is replaced with something that serves malware? Do you need to support HTTPS to protect your users? Presumably you have ssh enabled so you can manage the server (install new versions of your server, etc.): is that (or the console or whatever other method you use for maintenance) properly secured?

It takes a little bit of work to listen on privileged ports (below port 1024) without being root. You might make your life a little easier if you can listen on port 8000 (maybe have your load balancer redirect port 80 to 8000 for you).

Protection: defensive coding (like checking lengths of incoming data before copying it), know what's going on in the libraries you're calling, re-use already-debugged code, code reviews, static source analysis, testing.


Dsquery is just a tool to query the active directory, it by itself isn't malicious or leaking personal info.
What happens is that this tool queries the active directory, which is Microsoft's database to manage windows devices and users in a centralized location. Your IT administrator configured a naming policy, if that naming policy contains private information this is not an issue with the tool or active directory, this is an issue with the security policies in your organization.
The active directory is open for query to any standard user. There are a few different use cases and they are there by design: checking file permissions, getting data about emails in outlook and even presenting the right user name when you log in.
Assuming this is private info I suggest mitigating by changing the convention, you can use multiple other identifier which aren't private like a distinct naming convention or a different ID number which isn't private.


Creating an application in which all user content is encrypted

This depends entirely on what you need the application to do, exactly what data needs to be protected, and who is permitted to view the data.

In the simplest case, where your application is merely an indexing system for documents and the document metadata can be stored in the clear, you can use client-side encryption to protect the document itself: the encryption key never leaves the user's computer, so it's not possible for anyone else to read the document.

In the extreme, you'll need to look into homomorphic encryption.  This permits you to operate on encrypted data without knowing what that data is, but it's incredibly slow, and so cutting-edge that most of the security implications are currently unknown.

Your needs probably lie somewhere in between; you'll need to define your problem better before you can decide what solution to use.


Can the `system` function pose severe security threats on a shared hosting server?

The PHP system call simply relays commands to the command line of the OS.  If you don't have command line access to the server you're renting, then you can see the obvious concern with allowing that command, as now you as a developer have access to the command prompt.

However, even if you do have command line access, incorporating the 'system' call into PHP code can do even more damage, as it exposes the command line to any insecurities your web application may have.  Suppose I'm able to carry out an injection or XSS attack on your web application - if I can successfully carry out such an exploit, the probability that I can send commands directly to your web server is extremely high.  Once I'm there, I have entirely compromised your individual web server.

So, in a nut shell, yes, the system call can be incredibly insecure without properly sanitized inputs.


How does authentication work if the password provides a different salt on every login?

The premise of your question is incorrect. A different salt is not used every time the password is provided.

This is how password based quthentication works:

Upon registration, the user sends her password to the server. The server generates a random salt, and stores the salted hash and the salt.
Upon login, the user again sends her password to the server. The server retrieves the stored salt for that user, rehashes the password with it, and compares it to the stored hash.


Are SSH keys and PGP keys the same thing?

Yes, the same RSA key pair can be used for both (Open)SSL and OpenPGP/GnuPG.

The monkeysphere project contains a tool to convert RSA keys in PEM format to the one defined by OpenPGP, pem2openpgp. For converting the SSH key pair into the PEM format, there already is a comprehensive answer in Converting keys between openssl and openssh.


How important is user acceptance when deciding whether to deploy biometric authentication?

The answer depends upon, among other things:

the specifics of the situation where usage of biometric controls is
being considered,
the type of biometric control being considered
and how invasive it is,
the target population for the control.

Administrative staff having to submit to a retina scan every morning to gain computer access would likely invoke greater resistance than the security administrators would in having to use a fingerprint reader to gain access to a sensitive area.

User resistance could be reduced by taking steps to address accuracy and privacy issues, as well as issues regarding potential health risks that may exist with more invasive controls.  And whatever control is being implemented should be usable by everyone - not everyone may have fingerprints for example. The key is awareness and training.  Staff should understand what is being implemented, why it is being implemented, and what is being done to address their concerns.


Make sure you and the device are connected on the same network. Also, the application needs to be running in the background. Did you launch the app on your Samsung S7 after your started the exploit? I think the android app is called "MainActivity".


The initial authentication process is carried out either using a pre-shared key (PSK), or following an EAP exchange through 802.1X (known as EAPOL, which requires the presence of an authentication server). This process ensures that the client station (STA) is authenticated with the access point (AP). After the PSK or 802.1X authentication, a shared secret key is generated, called the Pairwise Master Key (PMK). The PSK is derived from a password that is put through PBKDF2-SHA1 as the cryptographic hash function. In a pre-shared-key network, the PSK is actually the PMK. If an 802.1X EAP exchange was carried out, the PMK is derived from the EAP parameters provided by the authentication server.

This was extracted from here, which is teh IEEE 802.11. Look at the bold part.

To answer to your question, 1000 pmk/s is the same as 1000 k/s

I can suggest to you to use hashcat for GPU or genpmk/cowpatty to use rainbow tables. aircrack only supports CPU.

Anyway, if you use GPU you should get much more ratio than using CPU if your graphic processor is powerful. The best way as always is to test. :)


Is it possible to push a device from a private WiFi in order to decoy it to a public WiFi?

By placing your Wi-Fi interface which supports packet injection into monitor mode, you will be able to issue deauth (deauthentication) packets.

Deauth packets can be crafted via the Aircrack-ng suite. This can be done by the following:

 aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:AE:CE:9D wlan0

which instructs interface wlan0 to send one deauth packet for the following AP and client, as instructed with the MAC addresses.

With this in mind. Different OSs respond differently to disconnecting from a Wi-Fi network. Some may automatically reconnect to the last network, while others may automatically connect to a recognised network based on signal strength. If the signal strength is the scenario, then this became very simple. The signal strength of your Pineapple Nano must be greater than that of the Wi-Fi AP. The signal strength is based on where the client (the neighbour's laptop) is situated. Merely having the Pineapple Nano closer to the client will cause it to reconnect to the Pineapple Nano's public (rogue) network instead of the private Wi-Fi AP.

Such that, if the client's signal strength for the Pineapple Nano is greater than the Wi-Fi AP, then the client will connect to the rogue network, else the attack failed.


Is this code vulnerable to Reflected XSS?

Yes, this code is vulnerable, but not to XSS. The subdomain variable's value can indeed be controlled by an attacker, but that variable is only used to set the href parameter of a CSS stylesheet; which won't accept JavaScript code. However, controlling this value does still allow CSS injection.

The stylesheet's href is prefixed by /, but an attacker can still point it to an arbitrary page by adding another slash to form a protocol-relative URL pointing to the attacker's server. (E.g. //evilsite.com/payload.css.) This would allow the attacker to get complete control over the site's appearance, if not it's functionality, which could be used to trick users into taking actions they wouldn't otherwise take. (For example, add a banner telling users they need to reset their password, then style the user settings page to make their public profile description field look like the input box for "current password".)


can ssh passwordless public key authentication be ok if combined with a VPN?

This is a typical defence-in-depth question. Why do I need X if I already have Y and Z in place?

The common answer is that your security is usually as good as its weakest link. In your case, your one and only security mechanism appears to be your VPN. This is your strongest and weakest link. In your opinion it is enough protection and no additional protection is necessary.

Perhaps you're right. It might be good-enough. At home, I only have one lock on my door. I know two locks would be stronger, but the cost/hassle of installing another lock, and having to use two keys is not worth it for me. I don't have much worth stealing anyway. But if my lock or your VPN get compromised, then we're left with little or no protection. The VPN security can be compromised in a variety of scenarios, some of them are as trivial as someone accidentally making a stupid configuration change that leaves your VPN open for example. Also, even if the VPN is 100% waterproof, an employee might decide it's a great idea to plug in a wireless router to your network so they can use their iphone more easily, leaving a chance for getting into your network without the VPN. It of course depends on your organisation, the setup and so on. The basic principle is the same.

You'd have to consider the strength/weakness of your protection against the cost/worth of your data. Then add in the 'residual cost' of adding and managing another layer of protection, and see if it's worthwhile for you. Installing another VPN gateway - so you have two VPNs - might be costly and inefficient. Adding passwords to your ssh private keys might however be easy and cheap enough to be worth it.


Generate a wordlist using John the Ripper

crunch is a password generator that can do some of what you may be looking for.

crunch 8 8 -t ",@@@@@%%"

is a command that will generate a set of passwords that are exactly 8 characters long following the provided template:

, generates an upper case character
@ generates a lower case character
% generates a digit

You probably want to set various options to crunch to limit the output.  For example, a small test of only four characters, like this: crunch 4 4 -t ",@%%" generates 67600 words.

See man crunch for more details.


there are 7 layers in the OSI reference Model. a Network Firewall can protect you against attacks upto Layer 4. there are still 3 more layers out there that are unprotected. so, no matter what you do with those two routers, there will still be a big gap in securing your infrastructure.

Also, Since you believe that you were already hacked, the attackers may have left a back door too.


Am I exposing myself to attacks when running my test server while connected to a commercial VPN?

as long as you access it over 127.0.0.1, localhost, or any domain that will resolve to localhost (because those are routed over the loopback interface and not through your VPN) and you have the proper protections you listed (which means it will be available locally only and not over the VPN) you will be ok.


How to prevent malware to know when removable devices are plugged in

Computers are not good at detecting evil. Meaning that you cannot make an automated test which can tell you if some software, which detects USB device plugging, is "malware" or "not malware".

As long as a machine:

currently runs malware (i.e. is subverted);
and can detect at all that a USB device is plugged;

then the malware can see the USB device and do everything that it wishes to do on it.

To prevent malware on a given machine from noticing that a USB device is plugged, then, you only have two possibilities:

Remove the malware from the machine.
Don't plug the USB device.

From your description, what you are trying to do is analogous to the following: when a hospital is on fire, how do we arrange for the flames not to notice when a new patient enters, so that the flames don't actually incinerate him ? This ridiculous metaphor is meant to illustrate the idea that you might be trying to solve the problem by the wrong end, with predictably suboptimal results.


Is a 43 character GPG (symmetric) passphrase as secure as a 256-bit key?

In some versions of GPG, the default KDF is PBKDF-SHA1, which will result in a 160-bit key, I am unsure what the default KDF is for each version, however their website man page says it is RIPEMD-160 (for the current version I assume).

You can change the default to the more secure SHA512 using the command --s2k-digest-algo SHA512, which should result in a hash value truncated to whatever key size the encryption algorithm uses, 256-bits in the case of AES256.

Since you are using a full entropy random password, you should not require iterations or salting, and can use just a straight hash if you desire (mode 0).


Certificate Chain - intermediate and root certificate - installed required?

In short: the intermediate certificates have to be sent within the TLS handshake (needs proper configuration of the server) and only the CA local at the client will be considered as trust anchors.

In detail:

  ... see that it does not have the issuing ca (intermediate ca's public key), will it automatically download those intermediate cert (e.g. COMODORSAAddTrustCA.crt) from my webserver ?

No browser will download the certificate from your site. If intermediate certificates are missing in the TLS handshake some browsers might try to download the certificate from other sites but you should not rely on it. Google Chrome on desktop seems to do it, other browsers not.

  or it will prompt the end-user (using the browser) whether he/she wanted to install those certs?

No, there will be no prompting. Just an error that the certificate cannot be validated.

  ... will my webserver send the root cert over and the browser will prompt whether to install the root cert or not?

No. It would be stupid if a browser would trust any random root certificate send by a server, because then man in the middle attacks would be simple. Even prompting will not help much because most users will just click through any dialog they don't understand. Browsers will only trust the CA shipped with the browser or provided by the OS and explicitly  installed CA. Installing a new root is more complex and usually involves that the user explicitly downloads, installs and trusts the CA certificate.

  How do I see what are the root certs that are already installed in the browser?

There are lots of information about this on the internet. Just follow the links from the search for "view root certificates browser". Note that the actual ways depend on the browser and OS.


Identify encryption algorithm for .enc files

You can identify:

a) metadata embedded in the encrypted file by many encryption tools - including algorithm name and mode

b) several old, weak encryption algorithms (so weak, that it's possible to detect them by patterns or by statistic analysis in encrypted file - for example Caesar Cipher, but also many more algorithms used in 20th century even for military purposes)

c) what algorithms were possibly/impossibly used to encrypt the data, based on the encryption key structure (sizes of individual parts of the key, or simply metadata embedded in the key file)

Unfortunately that's all.

If you have "raw" encrypted file, without any headers, then you can try to analyze the internal key structure, and then try to decrypt the file using all algorithms that use decryption key with the same sizes of individual parts.

However, it's also possible, that your encryption key is not "raw" but just an input data to some transformation, eg. PBKDF2. If so, it might be impossible to decrypt your encrypted file without knowing all details about used encryption mode.


What is the correct way to make a password salt?

With a language-independent approach, it's highly recommended to use well-vetted and time-tested techniques to securely hash your passwords (or any crypto-related issues, for that matters) instead of coming up with your own.

Why? Because you, by definition, is one brain. Most of the time, one brain doesn't catch its own mistakes until it's too late. Three brains is better, and four even better. Such libraries can have anywhere between tens to thousands of people working on them and/or trying to break them.

Since you're using PHP, I'd recommend using libraries that have little learning curve and they do everything for you (generating the salt, hashing, and verification) like PHPass. If you have the luxury of coding only for PHP 5.5, then you can use PHP's own API for that (check password_hash).

Finally, to answer your question directly, if you just want generate a 64 character long hex string (a gigantic 256-bit), I recommend using something like this:

$salt = bin2hex(openssl_random_pseudo_bytes(32));

Note: While 256-bit is fantastic, I think it's a bit too much for a salt. I recommend going with 128-bit (16 bytes), which will produce a 32 character long hex string.


Interesting question.  My thoughts on this are that obscuring information is helpful to security in many cases as it can force an attacker to generate more "noise" which can be detected.

Where obscurity is a "bad thing" can be where the defender is relying on that obscurity as a critical control, and without that obscurity, the control fails.

So in addition to the one you gave above, an effective use of obscurity could be removing software name and version information from Internet facing services.  The advantages of this are:

If an attacker wants to find out if a vulnerable version of the service is in use they will have to make multiple queries (eg. looking for default files, or perhaps testing timing responses to some queries).  This traffic is more likely to show up in IDS logs than a single request which returned the version.  Additionally fingerprinting protocols aren't well developed for all services, so it could actually slow the attacker down considerably
The other benefit is that the version number will not be indexed by services like Shodan.  This can be relevant where an automated attack is carried out for all instances of a particular version of a service (eg. where a 0-day has been discovered for that version).  Hiding this from the banner, may actually prevent a given instance of the service from falling prey to that attack.

That said, it shouldn't ever be the only line of defense.  In the above example, the service should still be hardened and patched to help maintain its security.

Where I think that obscurity fails is where it's relied on.  Things like hard-coded passwords that aren't changed, obfuscating secrets with "home grown encryption", or basing a risk decision on whether to patch a service on the idea that no-one will attack it.  So the kind of idea that no one will find/know/attack this generally fails, possibly because the defenders are limiting their concept of who a valid attacker might be.  It's all very well saying that an unmotivated external attacker may not take the time to unravel an obscure control, but if the attacker turns out to be a disgruntled ex-employee, that hard-coded password could cause some serious problems.


Heartbleed client side attack: What can the attacker obtain?

Vulnerable clients are less of a problem than vulnerable servers.  The major web browsers don't use OpenSSL for security, and most non-browser clients (eg. database interfaces or email programs) are rather picky about which servers they connect to.


How come a controlledly generated password is more secure than a purely randomly generated one

Many sites have complexity requirements. One advantage of the check boxes is to guarantee your password will actually be accepted by the website that you are generating it for. Another reason is psychological. People will believe the password is less susceptible to guessing if it has these character requirements. Realistically, a password with 80 bits of entropy that is completely random and a password with 80 bits of entropy that has these requirements are both strong enough that guessing or a brute force attack should never be an issue, even if for no other reason that the attacker will get enough passwords that running his brute force machine for another few years just to get the last 0.25% of the password hashes that he stole broken isn't worth it.

Edit:
I'd like to emphasize that determining how much entropy a password has is not so much an exact science as it is an approximation. As discussed in one of the links in Jedi's answer, different password generators have different algorithms for this, so if KeePass says one password "beats" another in terms of calculated entropy, but the difference is only 1 or 2 bits out of 30+ total bits then there may not really be an advantage of choosing one over the other. Of course with very small passwords a single bit may be significant, but I hope everyone reading security.se keeps away from obviously horrible passwords.


This feels like an instance of the XY Problem.

The short answer is:

Your external applications Bind to your Service.
This requires permission from the user, set with the permission tag.
You use this secured channel to establish authorization (e.g., share a secret key for use in a symmetric key scheme).

In general, this is how you provide information from an app, and then control access to that information.

The longer answer:

You're using the socket to communicate information from your Service to other applications, but this isn't really the "Android-y" way of doing things. Android has a system for inter-process communication using something called Intents. That's getting a bit away from the security-specific question though, so if you're hung up on the Android docs, feel free to ask on StackOverflow!

The upshot is that this system of Intents and Permissions is Android's tool for limiting app access. Note that this differs from the traditional desktop model (which is based on users, rather than applications), because mobile development is aimed at a single-user use case.


Is "real salt" the same as "initialization vectors"?

A salt and an initialization vector are mostly the same thing in the following sense: they are public data, which should be generated anew for each instance (each hashed password, each encrypted message). A salt is about being able to use the same password several times without opening weaknesses; or, if you prefer, preventing an attacker from sharing password attack costs in case the same password could have been used on several instances -- which is all what precomputed (rainbow) tables are about. The point of an IV in, say, symmetric encryption with CBC, is to tolerate the use of the same key to encrypt several distinct messages.

The name "initialization vector" hints at a repetitive process over a given internal state, the IV being what the state is initialized at. For instance, the MD5 hash function is defined as repeated action of a compression function which takes as input the current state (128 bits) and the next message block (512 bits), and outputs the next state value; at the beginning, the state is initialized to a conventional value which is called "the IV". In that sense, most "salts" used in password processing are not "initialization vectors". But this is a bit of an overinterpretation of the expression.

Still, naming things is mostly a matter of Tradition. A "salt" is a kind of IV which:

is involved in some processing of a password;
should be distinct for each processing instance (it cannot be a fixed conventional value);
only needs uniqueness ("it is not repeated"), not uniform selection among the space of possible salts (although uniform random selection is a good and cheap way to get uniqueness with overwhelming probability, assuming that the salts are long enough).

The particulars (how the salt/IV is exactly inserted and at what point in the algorithm) are a red herring.


Publishing a private key as a way to revoke it?

The idea of simply publishing the private key works only if the private key is definitely not in use anymore. Apart from using forward secrecy for encryption it means that the key was never and will be never allowed to be used for digitally signing something (i.e. proof of authorship, proof of trust relationship...), because otherwise everybody could just take this private key to impersonate someone and claim that the message has been created by the other one before the private key was published.

Also, revocation by publishing the private key means that the owner still has access to the key. This is not necessarily the case if his computer was stolen or compromised by the attacker, but this is definitely a case where the owner wishes to revoke the key.

While one might probably construct a system were  guarantees about not signing can be given it looks like your specific system has not this property, since there is actually signing involved to have some web of trust. But in any case it would be better if revocation would be possible without relying on such restrictions in the first place.

One way would not to publish the private key itself but a revocation message which was signed by the private key and can be verified by the public key. This is kind of revocation message could be created at any time, for example immediately after creating a new key. It could also be kept separately from the key and replicated to many places so that in case the private key got lost it would still be possible to revoke it by publishing such revocation message.

And this kind of pre-created revocation message is actually used in practice. To cite from the GPG manual:

  After your keypair is created you should immediately generate a revocation certificate for the primary public key using the option --gen-revoke. If you forget your passphrase or if your private key is compromised or lost, this revocation certificate may be published to notify others that the public key should no longer be used.


Bypassing hidden SSID and MAC filtering "protection"

If you don't broadcast the SSID it takes some monitoring of traffic with Kismet, but it will eventually pick it up. The more traffic actually going across the wifi, the faster it will identify it.

Mac filtering can be bypassed multiple ways, by being patient, or by flooding a device with garbage.  The second can be done with a jammer and a directional antenna, or through various techniques detailed elsewhere.

Spoofing a mac address is trivial, and once done (if time is not a factor) one simply waits till the device disconnects and connects in it's place.


Well, to this question anyone can give you a 100% sure answer.

But, the most probably action your pro-tech dad took is generating a task (maybe as a program or as a shell-script) that auto-executes every x minutes looking for mac-changing programs. So if this program/script detects any MAC-FAKING process executing, it sends the restart/shutdown comand.

Try taking a look on the processes, tasks, etc... to see if there's something strange/new running.

You can also try to find the modifications by date.

Hope this will help.


Are encrypted databases secure against all attacks?

An encrypted database protects the database against attacks on the filesystem or storage. If someone manages to get a shell on the server, or gets the credentials to the SAN storage, they cannot make a copy of the database and run with its data.

On the other hand, the applications need access to the database, so they must have the credentials and the encryption keys for it. If an application can access the data, so can an attacker.

If the application is vulnerable to SQL Injection, an attacker can extract data from the database even if the database itself is encrypted.


Secure touch kiosk system without updates?

No. Even if the user cannot do anything by itself, there is possibility by cooperation of a web site (that the hacker made itself), would be able to escape the kiosk mode. This with the addition that Chrome, upon detecting a security problem, will usually prompt the user if he want to proceed. If both the end user and website is malicious, then the malicious user will just proceed through.

I would suggest using a Linux Kiosk distribution instead. There is Webconverger, and there is Proteus. The advantage is that these can be run in "live mode", and use a write-secured USB memory (For example, https://www.kanguru.com/storage-accessories/flash-blu30.shtml ) where you flip the write protect switch, to prevent writes to the memory.

When you use such a solution, you combine this with a simple timer, that Cuts the Power to the kiosk, lets say every night when the location where the kiosk is placed, is closed. The advantage is then, that ANYTHING that a malicious individual may have done to the kiosk, is instantly cleared out and the device is guranteed Clean every morning.

If you for some reason MUST use windows 10 with Chrome, there is a possibility to run this in write protected mode too.
This can be accomplished here:

How to enable on Windows 10:
https://msdn.microsoft.com/en-us/library/windows/hardware/mt572001(v=vs.85).aspx

How it works:
https://msdn.microsoft.com/en-us/library/dn449416(v=winembedded.82).aspx

Then when this are activated, you can turn on the Write protect switch on the USB memory without problems. Then you can apply the timer function as I describe, that will reboot the computer each night.


Session Identification Hashing - How to make it more Secure and Robust

A lot depends on what it is your trying to do and what the risks are associated with session hijacking. Generally, if you have a real need to ensure the session is actually owned by the right user, you would add additional checks, such as username and password etc.

The EFF has been doing a bit of work on how you can do browser fingerprinting to track people. It is possible that this work may provide you with some ideas/pointers on how you could increase your fingerprinting techniques.

See PanoptiClick


Is the master keypair in OpenPGP ever used for encryption, or just signing?

In the OpenPGP format, public keys are distributed with signatures; every key is signed by another key. A "master" key is a key which is signed by itself. The signature includes some flags which tell what the signed key may be used for; these are described in section 5.2.3.21. Thus, a key intended for signatures only will be distributed with the flag "This key may be used to sign data" but not with the flag "This key may be used to encrypt communications". What you consider as the "master key" will be flagged "key meant to certify other keys" but will not be advertised as fit for encryption, even if the underlying key type mathematically allows it (e.g. RSA key).


How to find an appropriate SELinux type to prevent "permission denied"

I had a similar issue sharing an X unix socket. While sharing regular files with flags z or Z is possible, it fails with unix sockets. I have discussed it here:

https://unix.stackexchange.com/questions/386767/selinux-and-docker-allow-access-to-x-unix-socket-in-tmp-x11-unix

The best general solution I found was to set docker run option:

--security-opt label=type:container_runtime_t

Be aware that this probably disables all SELinux protection for this container.

(Though, if you want to share /var/run/docker.sock you already give up all possible protection of the host, not only SELinux. Are you sure you want that?)


ISO 9564 Approved Encryption Algorithms for PIN, why symmetric block ciphers?

The reason ISO PIN blocks are used instead of a hash is related to the structure of the payments industry.

The diagram above shows the simplified data flows for a PIN transaction.  The ISO PIN block is sent to the Merchant Acquirer bank.  The Merchant acquirer bank decrypts the PIN block and forwards it to the card association, which in turn forwards it to card issuing bank.

In order to use hash based authentication, the merchant acquirer bank would need to know the plaintext PIN.  The merchant acquirer bank would then hash the PIN (and any associated salt and metadata) and compare the results with the value received from the merchant.

The problem with the above approach is the the merchant acquirer bank would need to know the PIN codes associated with every card it could possibly  process.  The card issuing banks are willing to confirm if a given PIN is valid, but do not want to share their entire PIN database with every merchant acquirer bank.

It would also be possible to send the hashed PIN to all the way to the  card issuer bank.  However, there would need to be some way to authenticate that the PIN block was generated by a particular PIN entry terminal at a particular merchant.  Without authentication, an attacker could replace a merchant pin pad with a counterfeit device that emitted the raw PIN.  The attacker could then hash the PIN and send it on for processing.

Any authentication solution would require a mechanism to authenticate the keys used for authentication.  Secret MAC keys are not used since it is impractical to share every PIN terminal key with every acquiring bank.  Asymmetric signing keys could be used as part of a PKI, but PKI technology was not widely used in the 1980s when encrypted digital payments first become common.  Adding a PKI to the existing data flows would require substantial changes in the end-to-end data flows.  Since the benefits of changing are marginal at best, the industry is unlikely to transition to any hash based authentication scheme.


When is IP blocking OSI level 7 only and what is the purpose of doing so on multiple locations?

OSI layers do not care where the check happens, but at which layer the information used in the check reside. If the check is doing whitelisting by IP address only it does not matter where the check is configured, because the decision is always purely based on the IP address, i.e. OSI layer 3.

But, depending on the setup and the validation code the check might actually not test against the real source IP of the client but against a claimed source IP. This would be the case if the check was done against the IP address from the X-Forwarded-For or similar HTTP header in the request. Such checks could be done in PHP and probably .htaccess and this would be a check based on information at the application level, i.e. OSI layer 7.

  And can one or all of this methods be bypassed with some kind of IP spoofing?

Bypassing checks based on layer 3 information (IP address) can obviously only be done if you can spoof the layer 3 information. While using a spoofed IP with UDP is easily doable using a spoofed IP address with TCP is nearly impossible because of the 3-way handshake, sequence numbers etc. See also Is it possible to pass TCP handshake with spoofed IP address?

Spoofing layer 7 information (X-Forwarder-For) is easily doable with a custom client.


can a backdoor executable be used on an occupied port?

If there's not an application listening on the port that you want to listen on, then you can use those ports. If not, you can make an outgoing connection which should make the firewall less of a problem (especially if you try to connect to a common port like 80 or 443).


How large RSA-keys could the worlds combined computer power factorize in reasonable time?

The current record for RSA-breaking is 768 bits. The only known algorithm which is sufficiently efficient for these key sizes to be envisioned at all is the General Number Field Sieve. This algorithm consists in two big parts, the sieving and then some heavy linear algebra.

When GNFS was first used to crack a 512-bit RSA key, the sieving was the bottleneck; it requires lots of machines with amounts of RAM which were non-trivial at that time. However, for bigger keys, it is the linear algebra which becomes the bottleneck, because it is not easy to parallelize, and requires one really big computer with a lot (a lot) of fast (very fast) RAM.

With all the computers on Earth, you could do the sieving for a 1024-bit factorization effort; all it takes is some thousands of computers with a few dozen gigabytes of RAM each. However, for the corresponding linear algebra, all these computers would amount to nothing. Instead, you have to build a new, special purpose computer with a new architecture.

For instance, consider the biggest supercomputers in existence. They are all accumulation of many microprocessors -- they are CPU-oriented supercomputers, very good at number-crunching on tasks which can be made adequately parallel (many computations per data transfer unit). For the second half of GNFS, you need a RAM-oriented supercomputer, better at data transfers between CPU than actual computations. The theoretical architecture for such a computer has been studied, and we have some good reasons to believe that it is technologically feasible, but it would still be a very substantial effort, beginning right at the chip foundry step.

Summary: even with a botnet controlling all of Earth's computers, you would not crack a 1024-bit RSA key. With all of Apple's cash, you could probably build a special-purpose machine which can crack a 1024-bit RSA key (but good luck with doing that discreetly: you cannot spend billions of dollars without showing up, at least, on economic statistics). For bigger keys (e.g. 1536 bits or more): don't even think about it.


Prevention of user's passwords being stored as plain text in bash history

You can't, and you shouldn't try for the following reasons:

Imperfect technical ability (semantics)
Imperfect technical ability (centralized logging)
Alternate vectors (process table)
Best practices (teach correctness)

Imperfect technical ability (semantics)

Let's assume you actually want to have a history file - it exists for a reason; helps you remember commands you typed, repeat commands by reference, etc. etc.  In this case, you want to remove passwords that you've mistakenly entered.  How do you do that?

You could have a plaintext list of passwords that you scan for within bash history files.... but then you have a list of plaintext passwords on your system.

You could look for commands like 'sudo' and 'su' and try to remove things after them... but the thing that's going to happen is someone will type 'sudp' by mistake, then type in their password to the prompt, and your filter won't notice it because of the very typo that led to the password exposure.

In short, the computer isn't smart enough to filter out inappropriate password entries; that's a semantic meaning problem.

Imperfect technical ability (centralized logging)

In bash 4.1, they introduced the ability to copy everyone's history logs to syslog.  This was a legitimized version of functionality that people had been hacking, patching, and scripting into bash (and other shells) for years.  If anybody else administers your machine - say, the IT group at work - then you may not have control over whether your command lines are being logged, quietly, without you ever knowing.

It's not just bash.  The auditd daemon on Linux can be configured to log commands and arguments:

# grep oops /var/log/audit/auditd.log
type=EXECVE msg=audit(1443795447.953:2387443): argc=6 a0="sudo" a1="oops" a2="i" a3="typed" a4="my" a5="password"
#

That's a system-level setting, operating via the kernel, completely unrelated to whatever shell you use and regardless of any history settings you may have chosen for yourself.

Alternate vectors (process table)

Anything you type on the command line may show up in the process table, which is why tools that use passwords require them to be entered interactively.  If you mess up (as in the sudo example above) and enter them as arguments, they're there for someone to grab out of the process list - and it's not that hard for someone to script a harvester that grabs command lines out of the process table.

Best practices (teach correctness)

Each of these objections has caveats... "If I don't want to keep using a history file", "If my sysadmin is hands-off", "If no one is watching the process table carefully"....  But my definition of "best practices" is "stuff you do because you can't rely on other things going the way you'd like them to."  So best practices is simply to assume that any password mistyped where it shouldn't have been is compromised, to change it immediately, and to move on with your life.

Any "solution" you could implement is partial and prone to failures outside the user's detection sphere.  I'd rather not give people the false impression they're safer than they are.

I realize training people to do it is hard.  Heck, training people to do anything is hard, and security is doubleplushard.  But it's the right answer.


The Evercookie is able to track users using 15 different methods, and if parts are removed then it automatically recreates the missing data. Edward Snowden cited it as a method effectively used to track the otherwise untrackable TOR users. You could theoretically make a new virtual machine for each browsing session and delete it when done, but you'll still have to mask your IP address and prune your user-agent string to keep from potentially being recognized from your previous visits.

Practically, you need to balance your desire to browse a specific wab page against your desire to remain untracked. There's no way to automatically determine which parts of the JavaScript (not Java scripts) are being used for tracking and which are for functionality; you'd have to open each script and determine it manually for every page you visit. You can do a lot by disabling cookies by default, disabling scripts by default, and setting plugins as click-to-run, but you cannot get around the fact that many sites today force you to allow them to track you in order to access their content.

If you're blocking scripts by default, keeping googleanalytics scripts and cookies blocked (and, obviously, not signing into your google account) will generally be enough to stop google from tracking you. I don't have any experience with piwik, so I can't speak to that.