Authentication steps when deploying to pipelines

It depends on the possible consequences of misusing of deployment permissions.
If user with deployment permission has left his computer for a few minutes unlocked, somebody can use it to deploy some bad (e.g. with known critical bugs) or even malicious application revision. If this  can cause a big money loss for your company, e.g. improper deployment activates Christmas discounts in March, then it may make sense to request authentication once again. If the potential problems are not critical, e.g. your web site provides whether information for normal users, then the current authentication can be sufficient and new authentication would give no essential benefits.


Yes, WebGL is indeed a potential security risk, though the magnitude of the risk is hard to assess and open to debate.  There are some tricky issues here.  The browsers have put in place some defenses against the security risks, but there seems to be some debate about whether those defenses will prove adequate in the long run.

One major risk is that WebGL involves running code directly on the video card, and exposing APIs that provide direct access to video card APIs.  The browser does attempt to sandbox this code (to a certain extent), and browsers do enforce a number of security restrictions designed to prevent malicious behavior.  However, many of these APIs and their implementations were not originally designed to be provided to untrusted entities (they were only usable by native applications, which are fully trusted), so there are concerns about whether exposing them to arbitrary web sites might enable web sites to attack your system.

There was one high-visibility white paper (see also the sequel) which looked at the security of the WebGL implementation in browsers at the time, and found a number of vulnerabilities.  They found some memory safety issues in several WebGL APIs, and also found some attacks that would allow one web site to read pixel data of other web sites (which could enable a breach of confidentiality).  See also this third study, which demonstrated the existence of these vulnerabilities on a number of browsers and web cards (at the time).

Browsers have responded to this with a variety of defenses: they have blacklisted video cards with known security problems; they have tried to fix the known memory safety problems; and they have restricted use of WebGL per the same-origin policy, to prevent a malicious web site from using WebGL to spy on users' use of other web sites.

There is some ongoing debate over whether these defenses will prove adequate in the long term.  Microsoft has taken the position that WebGL is too great a security risk and the existing defenses are not robust enough.  On the other hand, Mozilla takes the position that the defenses they have put in place will be adequate, and that WebGL provides important value to the web.  Ars Technica has an excellent round-up of the issue; and here is another press report.

P.S. I completely disagree with your statement about it being particularly a problem for open source web browsers.  That's a myth.  See Open Source vs Closed Source Systems, which already covers these arguments.  (See also Chrome vs Explorer - how to explain in plain words that open-source is better? for additional thoughtful discussion on this topic.)


Prereqs:

See this question for a rough overview of how OAuth works.

See this question for a rough overview of how public key SSL/TLS works.

See this question for a rough overview of how SSL certificates relate to identity.

The meat of the matter:

Public/Private key systems can be used to provide three kinds of services:

symmetric session encryption
asymmetric session encryption
identity verification (often coupled with authentication)

Technically, none of the above three services are required for an OAuth system to work properly - it's very possible to build an OAuth system which doesn't use public/private keys for anything, at all.

That said, OAuth systems will often rely on property 1 of public/private key systems to ensure that OAuth related communication is encrypted, usually by building communication protocols on top of existing TLS/SSL based systems. They will also often rely on property 3 to provide one-sided identity verification, usually by relying on external, built in browser components, which implicitly perform that function.


It may be your English skills, but TOR does not need a justification.  TOR was invented by the U.S. Naval Research Labs and the U.S. DARPA (see Wikipedia History) as a research project.  However though part of the U.S. Military, they publicly released the concept and its code, then a non-profit (the TOR Project) continued to develop and expand it.
TOR has many potential use-cases (not justifications).  Since at a 10,000-foot level of abstraction, it is essentially a multi-hop VPN, its most trivial use-case is to use it in situations where a public and free VPN would be useful (such as when using a free and open WiFi in cafes, airports, and hotels), but no VPN is available.  TOR is slower than a VPN, so its not an apples/oranges comparison of usefulness.
However, one of the stated project goals of TOR was to provide a level of anonymity of routing over the Internet (originally) from the client-side against a form of forensics/ investigation called "traffic analysis".  The concept was that even though the Internet packets were in-the-clear once it left a TOR exit node, those packets could not be traced back to the client-side originator.

So one possible use-case was that dissenters could use TOR to get past country-level firewalls to access foreign Internet resources.  Or use TOR within a country, knowing the country would see the traffic past the TOR exit node, but could not determine who actually sent it.  Of course that left the recipient of that traffic exposed.
So TOR was extended to allow for "hidden services", such that in the dissenters use-case, an TOR email server could be setup as a "hidden service", and both parties use that email server via TOR to send and receive private emails between them.  In that case the dissenters traffic never "leaves TOR", and the country never has an opportunity to see it in-the-clear.

However, both the original designers of TOR and the current sustainers of TOR really did not take into account what happens when the underlying network infrastructure of the Internet is totally eavesdroppable by country-level agencies.  Even though the TOR Nodes fluctuate, agencies of various countries have "mapped the TOR nodes" and remap it continually using TOR's own tools.

It is now possible for certain countries to know which clients and servers (by IP Address) have accessed a TOR entry node.  Indeed, network logging by ISPs, companies, and organizations (in this example a university in the U.S.) allow them to also know when clients and servers within their networks access a TOR entry node.

And of course, a country-level firewall can block all access to known TOR nodes that are outside their country, be they acting as entry, relay, or exit nodes.
There are even more recent developments that again have weakened the effectiveness of TOR, at least against country-level agencies.  These include Deanonymizing, bugs in TOR Browser,  TOR Hidden Services malware, and more.  However, the TOR Project is attempting to improve TOR to eliminate these new and advanced vulnerabilities.
So TOR today is still a possible technology that dissenters could consider using.  But like all technologies it has ever increasing risks in using it to achieve anonymity.  However, those risks vary by country in which a dissenter resides, depending on the Internet sophistication of the country's intelligence and investigative agencies.
If as in your question's scenario, the dissenter is already a "suspect" and his or her Internet connections are being eavesdropped upon already.  So TOR is neither helping or hurting that dissenter's anonymity; the dissenter is already exposed.

TOR would still offer confidentiality in the dissenter's use of the Internet, but so equally would a VPN, or using a web-site that uses TLS (though there are separate attacks against both VPNs and TLS).
And given the malware the country may be able to inject onto the dissenter's computer, their use of TOR (or VPN or TLS) may only give the dissenter a false illusion of continued anonymity and confidentiality.
And like that classic OPSEC tale of huge uptake of pizza deliveries to the Pentagon signals an imminent operation, indeed the use of TOR in particular (since it is not as common as TLS or VPN use) could trigger those monitoring authorities to assume the dissenter is actively up to no good.


You would presume the location where wordpress stores it's backups is either outside the locations served/accessible by the web server or that additional access controls are in place preventing access. Otherwise you're correct it is a really bad idea, that's made worse if the file names can be predicted easily.


Securing anonymous accessible URL with a GUID segment?

The basic solution is to encode a single-purpose semi-public password into the URL. Typically the solution looks something like this:

http://<base>/<content_identifier>/<auth_identifier>/<random_password>

So the <base> and <content_identifier> are whatever you want; they make the URL point to something for your site. The <auth_identifier> points to a corresponding authentication token in your database that indicates who authorized this URL, etc. The <random_password> bit is there to guarantee that the URL can't be guessed. It's just plain random. The authentication token in the DB stores the correct random password. You should be able to revoke or expire old URLs by updating (or deleting) the authentication token in your database. You should also be able to issue an additional unique URL after a previous one has been revoked (or perhaps at the same time as another). It's difficult to do this if your secret is a hash, since there's only one correct answer and therefore one correct URL.

If you're worried about secrets, you can encrypt the data before publishing it out in a URL and decrypt it before processing it. Typically that's overkill, but it all depends on what data you're exposing.

Note that your idea of encoding enough information into the URL to make it verifiable without the database means that the contents of the database cannot affect the validity of the URL. Specifically, you can't revoke it. Often that restriction proves problematic down the road.


Is NTP vulnerable to DNS poisoning or spoofing attacks?

I realize that this was asked some days ago; and this answer may languish at the bottom here. However, there are some simple 'system administrator' tips that need mentioning.

Yes, DNS hijacking and Man-In-The-Middle attacks do work against NTP as it is commonly deployed today. NTP is often / most often used across the Internet, without encryption (SSL), and without authentication.

And many companies under-invest in accurate time keeping. Accurate time keeping is required for many authentication protocols such as Kerberos, but it goes further than that, precise time is essential for fx post-attack forensics.

That said, in practice NTP isn't that common an attack vector. If you disagree, then please post links. :-)

In OP's case, the attacker subverts the DNS entry for a well-known NTP source such as pool.ntp.org. That's a valid concern. However an old and widespread best practice is to use many (5, 7, or 9) upstream NTP servers to guard against "falsetickers". With three upstream NTP servers the client can identify and ignore one falseticker; with 5 upstreams up to two falsetickers can be mitigated; etc.
A good sysadmin will also have considered BGP route diversity; network latency; and the stratum of upstream servers when selecting his upstream NTP servers. There are many NTP servers out there, both widely publicized services such as pool.ntp.org and lesser known local ISP NTPs, local university services, etc. This again provides some 'strength in numbers'.

  An interesting thought that occurs to me: if the resulting time change is small, this may be hard to distinguish from a correct NTP response.

Assuming a) you are following best practice and have multiple upstream NTP servers, and b) the majority of your upstream NTP servers have not been hijacked, then this isn't so hard really. OpenNTPd is known to use a simple falseticker detection (slide 20+).
AFAIK OpenNTPd does the following:

Calculate the median value of all NTP responses.
Find outliers, the NTP servers which deviate greatly from the median. Disregard these.
Using only the remaining NTP server responses, calculate the average, and use this value as the final result.

The reference NTPd is said have a more complex / more complete falseticker detection than OpenNTPd.


Have the recent Linux kernel USB vulnerabilities found by Andrey Konovalov been patched?

You can check yourself. Choose a random CVE - I chose CVE-2017-16538. It states -

  drivers/media/usb/dvb-usb-v2/lmedm04.c in the Linux kernel through 4.13.11 allows local users to cause a denial of service...

Now have a look at that file history in the repository -

https://github.com/torvalds/linux/commits/master/drivers/media/usb/dvb-usb-v2/lmedm04.c

Aug 20, 2017 media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*
Jun 24, 2017 media: dvb-usb-v2: lmedm04: remove unnecessary variable in lme2510_st…

So no - it doesn't look like that one has been fixed. As /u/Sonickyle27 showed many of them do have fixes but it looks like they haven't been accepted and merged yet.

Saying this there is technically the possibility distributions may have patched it themselves.


The drivers are from the phone's manufacturers, e.g if you have a Samsung phone, Samsung phone drivers will be installed on the computer. Microsoft has nothing to do with the phone drivers. As for the trust level, it really depends how much you trust your phone's manufacturer. If you are comfortable enough to send text messages or calls or emails etc. using the phone, then you shouldn't worry about the drivers.


Changing file extensions in PHP file upload to prevent code execution?

If your webserver is configured properly (ie it will not execute files with arbitrary extensions as PHP files) this approach will work against PHP code execution*.

Checking/changing extensions is also the correct approach (next to storing the files outside the web root). Checking mime types is unreliable, complex, and may be bypassed by an attacker.

You should use a non-existing extension or one that has no meaning in the given context (ie not .js, .html, .php, etc). Often, no extension is used.

* At least by directly visiting the file; the code can still be executed if the file is for example included and executed somewhere else


How do indirect, session-specific resource tokens increase security?

I will explain this by giving an example:

Suggest you have a list of objects in your database named:

Pear
Apple
Orange

You have a query which fills up a hash table stored in your session which maps the fruits you are authorized to have to a number:

1 => Pear
2 => Apple

You do not have access  to Orange. You then have a function which allows you to add fruits to a basket, so you choose a number 1 or 2 (this is the indirect object reference). Orange is not accessible in this session as it's not present in the hashtable (there is no number 3). With direct object reference you would have a function which just uses Apple, Pear, Orange rather than a number. So you could abuse the function (if no access controls are used) to add the Orange to your basket as well.

I personally do not see issues with direct object reference IF adequate access controls are in place. These access controls should be tested extensively. There might be more critical applications than others where this might be required, but imagine applications where there are thousands of users with each 100 or 1.000 options unique to them. Storing all of these in a session could have a significant impact on performance (considering the server will need to store this information for each client on the webserver).

Now to answer your first question: simply because it won't be loaded into the session. As in my hashtable example you simply won't have orange available.


URL Contains Sensitive Data - Alternative Besides Switching To Post?

It's difficult without a global overview to answer your question. If the only problem on your website was sensitive parameters are present in the URL: As you said, just pass the request as POST and not GET.

However : You need to check theses points :

Be sure communications are encrypted using TLS 1.2 or TLS 1.3
Your server must purpose only robust and non deprecated encryption algorithms. You can use this website to check it or this project if you need privacy.
Check for broken access control. You said that query string use the pattern userid=user123 : check that an attacker can't access to an illegitimate account changing the parameter of the request
Check for SQL injection. The pattern page=parameter (userid=user123) is often implemented on old web site and so more susceptible to be vulnerable. Be careful you can also inject in POST request and other ways

You need also check all TOP 10 OWASP recommendation but according to the information you gave, it's the first point I would check.

Conclusion

What are ways to solve this? Change GET method to POST
What about handling data in the url segments? I am not against the
idea of username appears in the URL. It's not a vulnerability if
access is controlled. Indeed if an attacker steal the computer it
could have access to the history and so the username. However It should
not have access to the password if security standards of storage
password are respected. Moreover, if an attacker steal a computer
which have not an encrypted hard drive, you will have more than the
username problem...

If you absolutely needs to solve this problem, you should encrypt
the user's computer hard drive of the application. In consequences,
if the computer is stolen (and turned off), data will not be available.


Is it possible to use Greasemonkey to hack a website?

GreaseMonkey (or Tampermonkey for Chrome) is a browser addon that allows you to inject custom JavaScript code in the browser on the client side. You have little to no control over it.

The good news is that none of these changes will affect the contents on the server side, or the contents for other users. So if you rely on the server for your validation/verification/signing in/e.t.c., then you have nothing to worry about. If, however, you rely on the client-side code to provide input validation and other kinds of restrictions, then you have deeper problems than GreaseMonkey. Almost all modern browsers contain features to allow the modification of client-side contents, they're mostly called Developer Tools.

My advice to you is to get a competent individual to assess the security situation of your website, and to help you protect it from future attacks.


Replace IPSEC VPN with Shadowsocks, is it secure enough?

Short answer is no. Purpose of shadowsocks is to obfuscate traffic so that Chinese GFW cannot recognize the pattern to bypass it. It is not designed for security purpose. In fact from security perspective, it is poorly designed.


In Tor, why are the middle and exit relays changed periodically but not the guard relay?

To answer your questions, please let me correct the first misunderstanding. If the guard relay is compromised, the whole circuit is NOT compromised. Guard relay can only identify the IP address of the client which established the circuit, but it cannot identify the server are you communicating with, nor the content.

This explains the guard design - here is the document about it - and answers your second question. To quote the main reason:

  If you choose new relays for each circuit, eventually an attacker who
  runs a few relays will be your first and last hop. With entry guards,
  the risk of end-to-end correlation for any given circuit is the same,
  but the cumulative risk for all your circuits over time is capped.

This means the following: let's assume an attacker controls one guard relay out of ten, and one exit node, and thus can do traffic correlation between them. If there are 10 users of the site, and they change the guard relay often, in a day they change all ten guard relays, and the malicious guard relay will know about all of them. But if the guard relay is not changing, the attacker will only know about one of them at the end of the day. This raises the cost of attack to an attacker significantly.

Now the first question. The main reason circuit changes (once in 10 minutes) is to prevent profiling. If the circuit is used long enough, a malicious exit node operator will be able to correlate your activities on different web sites and reasonably find out who you are, even though he wouldn't know your IP address. Changing the circuit prevents this.


Same sensitive info in HTML reply that was posted before

Your developers are right. If HTTPS is used from the client to the server processing the request the connection should be just as secure in both directions. If both communications are on the same SSL session the key used for the actual encryption should be expected to be identical.

However it does beg the question of why are you doing this? If the client has just sent the card details why do these need to be sent back in the HTML? Can this not be handled with JavaScript at the client end?

I'm also not fully familiar with the PCI data security standards but this may be in breach of those. I know for receipts there are limits.

The do's and don'ts guide reads -

  Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed.

To me sending this in HTML is a way of displaying it. There are also additional risks involving malicious code on the client.


Documented Best Practices for Reverse Proxy Implementation

NIST SP 800-44 Guidelines on Securing Public Web Servers is a good starting point, though it's no magic bullet (and it's a few years old now).

In my experience some of the most important requirements and mitigations, in no particular order, are:

Make sure that your proxy, back-end web (and DB) servers cannot establish direct outbound (internet) connections (including DNS and SMTP, and particularly HTTP). This means (forward) proxies/relays for required outbound access, if required.
Make sure your logging is useful (§9.1 in the above), and coherent. You may have logs from multiple devices (router, firewall/IPS/WAF, proxy, web/app servers, DB servers). If you can't quickly, reliably and deterministically link records across each device together, you're doing it wrong. This means NTP, and logging any or all of: PIDs, TIDs, session-IDs, ports, headers, cookies, usernames, IP addresses and maybe more (and may mean some logs contain confidential information).
Understand the protocols, and make deliberate, informed decisions: including cipher/TLS version choice, HTTP header sizes, URL lengths, cookies. Limits should be implemented on the reverse-proxy. If you're migrating to a tiered architecture, make sure the dev team are in the loop so that problems are caught as early as possible.
Run vulnerability scans from the outside, or get someone to do it for you. Make sure you know your footprint and that the reports highlight deltas, as well as the theoretical TLS SNAFU du-jour.
Understand the modes of failure. Sending users a bare default "HTTP 500 - the wheels came off" when you have load or stability problems is sloppy
Monitoring, metrics and graphs: having normal and historic data is invaluable when investigating anomalies, and for capacity planning.
Tuning: from TCP time-wait to listen backlog to SYN-cookies, again you need to make make deliberate, informed decisions.
Follow basic OS hardening guidelines, consider the use of chroot/jails, host-based IDS, and other measures, where available.


How safe is this "Multidimensional-Encryption method" (includes xAES, familiar from Unseen.is)?

An encryption patent is a contradiction in terms these days.  Nobody (in the large) is going to spend the effort to evaluate a patented method. At best, you would read the patent filing and determine that it's a cheesy version of something that exists and expose yourself to triple damages because you read a patent that should have been rejected based on an immense amount of prior art that should have been discovered, but wasn't because the filing is basically dishonest about this.


Should the average user care about DNS security?

The average user, in my opinion, shouldn't spend any time whatsoever thinking about DNS attacks.

First, it just doesn't happen on a scale that warrants such attention. When phishing attacks, ransomware, and password guessing are rampant, users are infinitely better off spending what little security motivation they have on preventing those.

Second, an attack involving a malicious DNS server realistically means you're connecting to a rogue access point. If you're using TLS for as many things as possible, you greatly mitigate the amount of damage that can be done in that scenario anyway. For anything that doesn't go over TLS, the problem is better solved by the developer of the application getting their act together, and unlikely to be solved by encouraging users to switch to something else.

So in practice I'd really say it boils down to "use TLS for everything", which insulates users from so much attack surface it's frankly absurd that there are still holdouts on this front. While it's not perfect, it at least greatly increases the difficulty of most attack scenarios and seriously hampers most non-targeted attacks.


Check certificate expiry along with Public key pinning

The usual public key pinning as done in browsers is done additionally to the other validations. But one could implement public key pinning in specific applications so that it relies only on the key or certificate. This might make for example sense when the application developer controls both client and server and the server uses a self-signed certificate for authentication.


Is creating a network bridge in order to connect a virtual machine to the internet insecure?

To be honest, as far as information security is concerned, any device connected to the Internet is vulnerable.

Microsoft is correct in saying so. Imagine a scenario where you have multiple internal network nodes that communicate only internally. You decide to open up just one port on one node in the network to freely communicate with the external internet. This puts your entire internal network in jeopardy. Imagine if a hacker could gain access to the one "open" machine and infect your internal nodes, escalate privileges and gain complete control over the network. Big risk. So you see, any sort of insecure communication between two networks leaves in open to attacks. In your case, your "virtual network" is at risk since you have now configured an 'external bridge' that  allows your  "open" hyper-visor to communicate with your "virtual network". So an attacker can tunnel thru your hyper-visor or attack those machines directly if the attacker finds a way.

Unfortunately, "bridges" are the only way to channel IP traffic from your visor to your virtual machines. Securing these bridges forms an incredibly important part of your security policy. Strong policies with port security mechanisms can help mitigate your risks.


Salts must be unique; that's their one and only job. You should strive, as much as possible, to never reuse a salt value; the occasional reuse is rarely critical but should still be avoided). With reasonably designed password schemes, there is no other useful property in salts besides uniqueness; you can choose them however you want as long as you do not reproduce the exact same sequence of bits. Uniqueness must be understood worldwide.

(With badly designed password hashing schemes, the salt might have some required additional properties, but if you use a badly design password scheme you already have bigger problems. Note that a salt is not exactly the same as an Initialization Vector for symmetric encryption, where strict requirements like unpredictable uniform randomness typically apply.)

A common way to have more-or-less unique salt values is to generate them randomly, with a good generator (say, one which is fit for cryptographic usages, like /dev/urandom). If the salt is long enough, risks of collisions (i.e. reusing a salt value) are low. If you use n-bit salts, chances of a collision become non-negligible once you reach about 2n/2 generated values. There are about 7 billions people on this planet, and it seems safe to assume that they, on average, own less than 1000 passwords each, so the worldwide number of hashed passwords must be somewhat lower than 242.7. Therefore, 86 bits of salt ought to be enough. Since we kind of like so-called "security margins", and, moreover, since programmers just love powers of two, let's go to 128 bits. As per the analysis above, that's more than enough to ensure worldwide uniqueness with high enough probability, and there is nothing more we want from a salt than uniqueness.

Uniqueness can also be ensured through other means, e.g. using as salt the concatenation of the server name (the worldwide DNS system already ensures that everybody can get his own server name, distinct from that of anybody else on the planet) and a server-wide counter. This raises some practical issues, e.g. maintaining a counter value which does not repeat, even in the case of an ill-timed server crash&reboot, and/or several front-ends with load balancing. A random fixed-length salt is easier.


If nmap reports a port is open, does that ALSO mean a service is listening on the port?

For a SYN scan of the sort you are performing, nmap defines an "open" TCP port as one where a SYN packet sent by nmap elicits an ACK packet from the target system.  Assuming that the firewall is configured sensibly, and that the TCP/IP stack is programmed correctly, an "open" port means that yes,

the firewall is permitting connections on the given port
there is a machine listening on the other end

and additionally

there is software on the other end listening for data sent to that port.

If you want a greater degree of certainty, have nmap perform a "connect" scan (-sT).  This is a slower technique that establishes a full TCP connection with the target, as opposed to the "halfway-opened" connection of a SYN scan.  If a "connect" scan says the port is open, it's open in any meaningful sense of the word.


ECDHE by itself is worthless against an active attacker -- there's no way to tie the received ECDH key to the site you're trying to visit, so an attacker could just send their own ECDH key. This is because ECDHE is ephemeral, meaning that the server's ECDH key isn't in its certificate. So, the server signs its ECDH key using RSA, with the RSA public key being the thing in the server's certificate.


Self-signed CA certificates - Can we throw away the private keys

The CA private key that belongs to the self-signed certificate is only used to sign certificates and, possibly, to sign OCSP responses or CRL's. So besides signing (future) child certificates, it may also required to establish the status of already issued certificates. If this is not expected to happen often then you could store the private key away on an offline device or two, and put those in a safe. Don't forget to securely wipe the private keys from the device that performed the signing, or keep that device itself safe. Note that issued certificates commonly have a shorter validity period than the root certificate; you may need to request subsequent certificates even for the same use case.

The device private key is required to perform device authentication. Of course, the other party first needs to establish that the device certificate is valid by performing verification (using the public key) and validation: checking the date, name and indeed certificate status. However, a certificate is public, it can be send by anyone. The device is only authenticated after it proves that it contains or has access to the private key that belongs to the public key within the certificate. So some kind of authentication procedure must be followed, which commonly requires the private key to sign some kind of challenge. The signature over the challenge can then be verified by the other party. As nobody should be able to create a signature over the - hopefully unique - challenge the device is then considered authentic, i.e. the identity of the entity is affirmed. This does of course mean that the private key needs to be available to the device each time the identity needs to be established; it can generally not be stored offline.

So no, you should not securely destroy the private keys while the certificates are valid.


2FA: Why not use dictionary phrases instead of numbers?

Yes you are increasing entropy but you are decreasing usability.

Firstly you need to get a good dictionary. Things you need to think about are accessibility (how readable is it? Are there b,d or q,p or cl,d or I,l confusions? You can't have click and dick in the dictionary)  Are the words easy to spell from memory? I can't spell 2/4 of the words you used and I have a BSc. You can't have any that are too technical or culturally insensitive (e.g.  Taiwan )

Secondly you say about mobile keyboard with autocorrect. Autocorrect goes wrong, you need to check every word in your dictionary will be in them for a long time (if bananas go extinct tomorrow will the word still be in an autocorrect in 30 years?)  and you are making it harder for those with full size hard keyboards

Thirdly you are cutting out everyone who doesn't speak the language, numbers work across all languages. There are very few other number systems used outside the 123 numbers.

Fourth how are you going to display them? A 6 digit number can be on a 6 digit 7 segment display, 4 words need at lest a 20 digit complex display or better. "But they can be on a phone" I hear you say, but there are places you can't have a phone because there are no wireless devices allowed (its hell on earth, never work in a place like this) and that would fragment the market to those with mobile devices and those without which leads into

Lastly it would fragment the market. For tech like this fragmentation is bad, we trust it because it has been tested lots and lots. Unless the old thing is broken or the new thing is 1,000,000% better than the original it will never take route. As it is we still have broken encryption methods now because they might brake something worse if removed and banks that still use something you know and something you know (2 passwords)

The improvement they could make to 2fa devices  is to be able to set how long the code is on the screen upto 60 seconds max (10 seconds per number for accessibility reasons) and have the box you type it into tagged as a number box so that soft keyboards show either the number row or better a number pad.


To find Kc from a SIM card you have 4 working ways :

(Credits to http://domonkos.tomcsanyi.net/?p=369)

BlackBerry Engineering Screen:

  pretty much on all of the BlackBerries you can enable the so called “Engineering Mode” which will simply show you the current Kc.

OsmocomBB Mobile App

  Download and install the app

  Upload layer1 to your phone
  Run mobile -i 127.0.0.1
  telnet 127.0.0.1 4247

  After that simply say:
  show subscriber 1 At the top you should see the
  Kc printed.

AT+CSIM Command

You need to send APDU commands to the SIM card via the modem (some phones allow you to do so):

  Sample run:

  AT+CSIM=14,"A0A40000026F20"
  +CSIM: 34,"000000096F2004001100BB010200009000"

  OK
  AT+CSIM=10,"A0B0000009"
  +CSIM: 22,"E0940FC09AEFA000009000"

  OK
  You find the last Kc used here: E0 94 0F C0 9A EF A0 00 and also the key sequence > number: 00

(From : http://openbsc.osmocom.org/trac/wiki/A5_GSM_AT_tricks)

Using a SIM-card reader/Smart Card Reader

You need a PC/SC cardreader and a software like SIMspyII. After insterting the card, you will have Kc displayed.

I just copied the information from http://domonkos.tomcsanyi.net/?p=369 to be sure the information will not disapear if the site goes down.


How to check if your Android app was updated by MitM?

Since your apps were downloaded from Play Store, you can check their latest update date by simply visiting their store page:

From Play Store app: tap 'Read More' on app's description, scroll to the bottom and look for 'Updated on'
From browser: look for 'Additional Information' on the bottom, there's 'Updated' date.

For your case, both RedPhone and Signal are developed by same developer and updated on November 2 (as of current writing). I think it's really a coincidence, since I observe that Play Store's update timing is arbitrarily random.

If you're still unsure, you can check the APK file's hash by submitting the file on Virus Total. You need root access to locate the APK (the path will look like /data/app/<package name>/base.apk. The package name can be found on Play Store link). Also, you need to ask the correct hash from the developer for confirmation.

Additional note: Even if it was a case of MitM, Android app can only be updated if it uses the same certificate to sign the app. Failing that will result in failed update (with error message "Application not installed. An existing package by the same name with a conflicting signature is already installed.", or INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES on ADB). This won't happen, unless the attacker is the developer (possible, but unlikely for reputable developer), or the attacker has the certificate (unlikely, and a critical issue for developer).


I wanted to comment on your question, but I don't have enough reputation for that.
You're discussing various things surrounding API and application security.
Maybe this article: https://dev.to/bearer/api-security-best-practices-3gjl could gives you some insights. If you apply these practices you should be pretty good.
Like you said, you can't be 100% safe and you have to weigh the risks. Most companies accept certain risks.


How to recover a lost zip file password?

If you haven't already looked at it there's a couple of sources I'd recommend for this.

John the ripper with the community jumbo patch supports zip cracking.  If you look at the supported modes there's some options (including the basic brute-force) for cracking zip passwords.
Elcomsoft have good zip crackers including guaranteed recovery under some circumstances
There are also some companies like this one who appear to have GPU accelerated zip cracking, which could speed things up depending on your hardware.

In terms of the approach it sounds like a dictionary based attack with mutation rules(so changing the dictionary with things like leet speak rules) would be the best bet, particularly if you've got the idea that the words would come from a specific domain.  Straight brute-force would likely not be a good idea as it tends to top out around 8 characters (unless you're throwing a lot of CPU/GPU power at it)


Comodo dragon gives me warning about certificates installed on my system

I just used another Comodo's product to scan my PC and find out this warning was a false positive about "microsoft ecc development root certificate authority 2018".
but anyway if you need to scan your installed certificate just like me you can use comodo free antivirus

Update:
Because I wanted to investigate more about this issue, as described in this article by Kent Chen I used sigcheck to list all my suspicious certificates. it was so much better than antivirus and showed me more certificates which I should consider for examining.
just download the sigcheck, unzip it and open PowerShell in that directory and execute following command

 .\sigcheck -tv


Is only using one IP address version (IPv4/IPv6) an availability risk?

As always: it depends :)

Because so much of the internet is still IPv4-only there is a kind of implied responsibility to have IPv4 connectivity yourself. There are however advantages to having both.

The world has a huge shortage of IPv4 addresses, which means that there are a lot of hacks like carrier grade NAT, NAT64 and DS-Lite going on to keep users connected to the IPv4 internet. That means that when your service is only available over IPv4 then your users might be forced to use those hacks. When the service is available over both IPv4 and IPv6 the user can just use IPv6 and get better connectivity to your service.

This is probably also the reason that big services like Facebook and LinkedIn see 15% to 25% better performance over IPv6: those users don't need to go through a central NAT box at the ISP and don't lose performance there.

And if those central NAT boxes get overloaded (they shouldn't, if the ISP invested in enough capacity, but...) then IPv6 users won't even notice.

So I'd argue that there is already a certain availability advantage to deploying IPv6, and it will become a bigger advantage every month. In countries like Belgium almost 60% of the home users already has Ipv6 access.


TLS header in content portion of HTTPS POST request hot handled well

There  is no such thing as a "TLS header line". "17 03 03" in your output just means the beginning of a new TLS frame with application data (type 23, i.e. 0x17, followed by TLS protocol where 0x0303 means TLS 1.2).

The output you show instead means that one client is sending the POST header and body within a single TLS frame while the other client is sending the POST header in one frame and the POST body in a second frame. This is probably caused by the first client using a single SSL_write which includes header and body while the seconds client uses a SSL_write for the header and another for the body. This is both a perfectly valid behavior and you could even split the payload into even more TLS frames. This also means that the server probably needs to do multiple reads to get the full HTTP message (header and body).

If the server has problems with this then the server is broken. Such brokenness is often caused by he server authors trying to write their own HTTP stack by just looking at a few HTTP messages, instead of using an established stack or properly reading the standard. The standard clearly says where a HTTP message starts and where it ends. And since HTTP is set on top of a streaming protocol it might be possible that multiple reads are needed to get the full HTTP message.  This is probably the reason why it succeeds with some properly implement server but not with your broken server.


Does RSA encryption always pad small amounts of data to some larger size?

Basically yes. That's how RSA works, as described in the standard.

On encryption, the input data is first "padded", i.e. expanded with some randomness and structure, and then turned into a big integer value m in the 0..n-1 range (n being the modulus). That value is then raised to the power e (the public exponent) modulo n, yielding another integer in the 0..n-1 range. The result is encoded into bytes with what the RFC calls I2OSP (big-endian unsigned convention). For a 1024-bit RSA modulus, you will always get a 128-byte result.

Similarly, a RSA signature, for a 1024-bit key, always has length exactly 128 bytes.

Mandatory reminder: no, you are not "encrypting with the private key". The whole notion of "encrypting with the private key" is a flawed analogy, which works only for RSA, and actually does not work for RSA, precisely because it completely fails at taking padding into account. You are signing. And, indeed, you use the -sign command-line flag. RSA is two algorithms, which happen to share some common mathematical structure, but not all of it; things will be clearer if you keep thinking about RSA encryption and RSA signatures as distinct process.


Is it safe to save customer information from Stripe? Do we need to be PCI compliant?

Taking advantage of a service provider, like Stripe, to store cardholder data is a way to simplify your PCI requirements. However, with any solution there are trade off and other requirements you must keep based on the solution you choose. Just because you use someone like Stripe doesn't mean you have no PCI compliance requirements. In the case of using a tokenization solution you need to protect the tokens from being exchanged for the represented data. This means, from a PCI perspective, the system storing the tokens shouldn't have the knowledge (meaning API keys and/or API Auth data) or the ability (no direct access to the API, etc.) to exchange the tokens back to card data.

After looking at the API docs from Stripe it appears they are pretty good about not allowing you to retrieve the credit card number from a token or customer. Looking at the official API docs on CARDS and CUSTOMERS, you listed, it shows that the actual card number is NEVER returned when a CUSTOMER or CARD object is retrieved. So the exposure is limited. Someone could still get valuable information about your customers that you don't want them to have. That is why PCI still requires you to protect the tokens as well as API keys as sensitive data and secure them accordingly.

The PCI guide for Tokenization should be pretty helpful and goes into more detail about what I mentioned above.

PCI DSS Tokenization Guidelines


Is it safer to "chown" the Applications folder on macOS?

Do not do this. It will be much less safe. You aren't giving the applications permission to run as admin. What's happening is that you are giving the Finder temporary permission to write to the Application folder. When you run it, it will be run under your account with your permissions. If you were to "chown" the Applications folder, it would make it much easier for some malware to write to the Applications folder without you knowing, potentially replacing some trusted program.

Just leave it be. It's much more secure the way it is.


How long does RSA encryption/decryption generally take?

I don't think anyone will be able to give you an exact number, since we know neither:

What you're encrypting/decrypting
How big the file is
Your key size
Use case
Computer specifications
Other factors like language used etc.

All of the above will affect the speed of the process. This site provides some numbers that you can use to calculate how long it might take. It also lists other alternatives.

Operation | Milliseconds/Operation | Megacycles/Operation|

RSA 1024    Encryption                  0.08    0.14
RSA 1024    Decryption                  1.46    2.68


I don't think that this should be a problem, for at least two reasons

you shouldn't need CSRF protection for framable pages. If the page had state-changing functionality which needed to be protected from CSRF, then it also needs to be protected from Clickjacking, so it shouldn't be framable in the first place.
you shouldn't need to be able to set new cookies in your iframe for the double-submit cookie prevention mechanism (any cookie that was previously set should still work, and there is no need to regenerate it).

But assuming that for some reason these issues do not apply, you could use one of the other CSRF prevention techniques,eg:

custom request header (ajax requests cannot be sent cross origin with custom headers unless allowed by the CORS policy)
verify origin header (or referer)
using a stateless encrypted token


Google have a list containing the MAC addresses and all the towers on a determined location. He can collect that data not only by the street view car, but from Android phones as well.

It's easy (for Google) to know the GPS coordinates of every cellphone tower on a city (or country), so correlating it with the data your phone sends is enough to get a very good idea of where you are.

Google already have a database (more or less) like this:

coordinates:tower coverage:MAC address

So, if you locate one MAC address on the list, you have the coordinates and the cell towers close to it.

Later, even if you have the cell phone disabled, your phone can connect using wifi, pass the MAC of the access point to Google, Google searchs its huge database, finds the MAC, and gets your coordinates.


I saw a news article about E-Z Pass fraud that people did by stealing E-Z Passes out of cars and replacing them with fakes, but does anyone know how secure the devices’ protocols are?

Let's assume you do clone the RFID tag. It certainly isn't tied to the payment information, as you change that through the web interface. It's tied to a toll-authority account and vehicle.

At least here E-Z pass is an RFID system and with OCR on the license plates, and high def camera shots on the face of the driver. You can run through it once every six months or year or whatever and they'll send you a nasty-gram. With a cloned tag, you could flip the plate by the time they'd catch you -- you'd be on your merry way. But, it's probably not worth it. From The Chronicle

  Now, HCTRA has its own high-tech specialists. One uses software to analyze traffic and pinpoint the day of the week, time, lane and direction a frequent toll violator is likely to pass through. Another specialist spends part of her shift doing the equivalent of fingerprint analysis on the photos to track down car owners who have tried to mask their license plate numbers.

If you even take the tag to a second car, they know if the car's color make and model fails to match. I assume it gets Q/Aed if there is a color fail.

A better scam, if you want to skip the tolls, is to get an out of state dealer plate. Note these are not the temp dealer plates. They run up millions of dollars of unpaid of tolls every year. For reference you can see this mentioned here in 2012

state vehicle inspection, emissions inspection, and toll fees avoidance;
parking ticket fine avoidance (local level);

However, recently (2014) they've been cracking down on out-of-state plates, and I assume dealer plates are soon to follow


Google Chrome "Your connection to website is encrypted with obsolete cryptography"

Your exact case is that RSA is used as the key exchange mechanism. Instead, you should use DHE_RSA or ECDHE_RSA.

To remove the "obsolete cryptography" warning, you'll need to use "modern cryptography" which is defined as:

Protocol: TLS 1.2 or QUIC
Cipher: AES_128_GCM or CHACHA20_POLY1305
Key exchange: DHE_RSA or ECDHE_RSA or ECDHE_ECDSA

Twitter discussion: https://twitter.com/reschly/status/534956038353477632

Commit: https://codereview.chromium.org/703143003

This has nothing to do with a certificate. There is a special "outdated security settings" warning when a certificate uses weak signature algorithm, but this is about authentication, not about encryption. Note that you are still getting a green lock, even in case of obsolete encryption.


nmap localhost UDP scan fails, even though netcat is listening

With netcat:

  In listen mode,  controls the address on which Ncat listens; if
  you omit it, Ncat will bind to all local interfaces (INADDR_ANY). If
  the port number is omitted, Ncat uses its default port 31337.
  Typically only privileged (root) users may bind to a port number lower
  than 1024. A listening TCP server normally accepts only one connection
  and will exit after the client disconnects. Combined with the
  --keep-open option, Ncat accepts multiple concurrent connections up to the connection limit. With --keep-open (or -k for short), the server
  receives everything sent by any of its clients, and anything the
  server sends is sent to all of them. A UDP server will communicate
  with only one client (the first one to send it data), because in UDP
  there is no list of “connected” clients.

So, when nmap will try the connection, nc will exit after the first packet received. But nmap, for testing a port, will send several packets. So the second packet will be lost and nmap will consider the port cloased, and moreover, your OS will send a ICMP port unreachable for the second test.

If you want to test your UDP ports and have a open result in nmap, you must force nmap to do only one connection: nmap -Pn -sU -p 12345 localhost -vvv --max-retries 0


"Shell shock" - exploitable when `system()` syscall or `exec(bash)`, right?

Wrong on both counts.

In order to exploit the "shellshock" vulnerability, an attacker needs to control at least one environment variable (easy to do through CGI, SSH, or DHCP), and bash needs to be invoked at some point with the modified environment: directly as the result of an exec(), indirectly through system() or equivalent, highly indirectly through exec() of a helper app that in turn calls system(), and so on.

bash doesn't need to be invoked by name, either.  On many systems, /bin/sh is a symbolic or hard link to /bin/bash, so running any script that starts with #!/bin/sh will result in bash being run.


You don't want to disable DMA.  At best, it will cause a massive slowdown of your computer, as every memory access must be handled by the CPU; most likely, it will make your computer entirely non-functional.

The best way to prevent DMA attacks is to disable or remove FireWire ports and use a computer case with a chassis intrusion switch to shut the computer off if the case is opened.


Can format string exploit bypass the PaX protection?

Format string vulnerabilities can aid in exploitation of systems protected by ASLR,  but not NX.   The reason why is because some  format string vulnerabilities allow the attacker to read the function's stack frame, that contains the format string vulnerability.  This allows the attacker to figure out the addresses of variables local to that function by reading the stack frame.    ASLR randomizes the memory page's base address at the start of the application.  So on a 32 bit system the address looks like 0xYYYYZZZZ.  In this case the Y's will be randomized,  but the Z's are an offset that is more predictable.  (Ideally) If the attacker can read the randomized base addresses of the same function that he is exploiting with a buffer overflow then the attacker can be 100% confident of the address of where his shell code will be.  If its not in the same function, then attacker is less confident of the address of his shell code,  but it can still aid in exploitation.  After determining the address of where the shellcode will be the next step is to corrupt the stack frame with a buffer overflow and point the EIP at this known memory location.   Which to be honest is really far fetched and not many exploits use this technique.   This technique is covered in great detail in "Exploiting software how to break code"  and in "Hacking: The Art of Exploitation".

There are other ways of reading memory addresses.  In the pwn2own for IE in 2010 a researcher used a heap overflow to overwrite the null terminator and read adjacent memory, he then obtained code execution with a dangling pointer.  Dangling pointer vulnerabilities are really nice for systems protected by ASLR and they are becoming more popular for this reason.

If you look at most of the exploits hitting Metasploit and the exploit forms.  You'll see that Return Oriented Programming(ROP chains) is the weapon of choice for exploiting buffer overflows on modern systems.


Can you tell if your computer was hacked and pictures stolen from 2-6 months ago?

Home computers are hacked all the time. Infected downloads, infected websites, etc can all result in compromises.

You can run tools to see if you might have been compromised, but no way to tell if pictures were removed.


How trustworthy is `sudo apt-get install (package name)` in Ubuntu?

As with many well-designed systems, the package system of Debian has defense in depth: multiple layers, each of which can be verified.

How do we trust the package file is what the system promises? The hash value is computed and compared against the stored value.
How do we trust the hash value isn't accidentally matching some other file? Multiple hash algorithms are used, and only if all those match the stored values do we trust the content actually matches.
How do we trust the stored values are meant for the package file we downloaded? The hash values are downloaded in a separate file (the various Packages.* files) pre-computed automatically by the archive system.
How do we trust the downloaded Packages.* files are what is promised by the system? The hash value for each file is stored in a single Release file for the whole archive.
How do we trust that the Release file is what is promised by the system? The cryptographic signature is computed, and compared against the separately-downloaded pre-computed signature from the archive.
How do we trust the signatures stored in the archive are actually from the archive we expected? It is certified by an archive key which we can fetch independently from a separate URL, and is installed in the initial set-up of the operating system.

And so on. At some point in the chain you have to trust some part of (and party in) the system, on less-than-ideal evidence.

With the above layers, the low-evidence trust window can be kept small and easily-scrutinised. The one-way hashes, and cryptographic signatures, allow us to trust the mathematics to certify what follows in sequence.

The Debian wiki has a good, comprehensive description of how the APT system is secured.

Of course, many other things can go wrong by mistake or malice, and violate our assumptions about what is actually happening. As usual, the only persistent defense against possible attacks is: eternal vigilance.


What are common services that are being misused in UDP amplification DDoS attacks?

The US-CERT lists a few. That list can also be easily found using a web search engine and the keywords in your question:

  DNS
  NTP
  SNMPv2
  NetBIOS
  SSDP
  CharGEN
  QOTD
  BitTorrent
  Kad
  Quake Network Protocol
  Steam Protocol
  RIPv1
  Multicast DNS (mDNS)
  Portmap


Potential consequences of signing software that's not mine

First of all I'd be very careful in declaring all signed software as save since malware with valid signatures already exist and you can expect that the amount of signed malware will increase.

Second, there's a pretty good answer for this question here.

I want to add that a possible solution for your scenario would be creating and installing an own root certificate. This would save you from any trouble if you accidentally sign malware.


How long does 2-factor authentication codes have to be?

This really depends on the site, the level of information being stored, and the TTL (time to live) for the record. Google tends to handle a lot of different accounts for people: gmail, YouTube, blogger, Android accounts, search histories, contacts, calendars, etc; all of the stuff a spearphisher wants. Likewise their app, Google Authenticator, changes keys frequently.

Your tax site is likely going for the illusion of security but they may have a legit reason, if two-factor is compromised, like let's say you're using an app on your phone and your e-mail goes to your phone and your phone is stolen, then it really doesn't matter much how long the passphrases are. However, if the TTL is long, then if the site isn't equipped to block a DDoS mask for someone brute forcing a specific account, then it is a great idea to go with a longer key length. If the credit system is anything like that of the states, then they're trying to protect your identity.

If the TTL is short, then shorter numbers are okay. So if they have 30 seconds to guess a 6-digit code there is less of a chance of an accidental collision. Most web servers don't allow as many connections per second as necessary to brute force a password of a length longer than a few characters unless they're commercial. Commercial servers tend to allow more simultaneous connections to the same database.

Ideally the application framework would notice the multiple attempted intrusions and lock the account immediately though, so again, back to UX not too long, but not too short.


Why do people tell me not to use VLANs for security?

VLAN:s are not inherently insecure. I'm writing this from a service provider perspective, where VLANs are the technology used in 99% (statistics made up on the spot) of cases to segment different customers from each other. Residential customers from each other, residential customers from enterprise leased lines, enterprise VPNs from each other, you name it.

The VLAN hopping attacks that exist all depend on a few factors;

The switch speaks some kind of trunk protocol to you, allowing you to "register" for a different VLAN. This should never, ever occur on a customer port, or someone should get fired.
The port is a tagged port, and the switch isn't protected against double tagged packets. This is only an issue if you have customers on VLAN-tagged ports, which you shouldn't. Even then, it's only an issue if you allow untagged packets on trunk ports between switches which, again, you shouldn't.

The "packets travel on the same wire" reasoning is valid, if the attacker has access to the physical wire in question. If that's the case, you have a lot bigger problems than what VLANs can solve.

So, by all means use VLANs as a security measure, but make sure that you never, ever speak VLAN tags with the entities you want segmented from each other, and do keep track of which switch features are enabled on ports facing such entities.


What are the serious weaknesses in this free password management system?

Compared to a typical password manager, the use of a simple text file has the following disadvantages:

Vulnerable to shoulder surfing. The content of a plain text file will be completely visible to anyone around you. While you scroll the file and copy-paste the relevant information for login, other people around you (either advanced attackers with recording devices or just ordinary nosy colleagues) will be able to see the passwords. Password managers don't display passwords by default, and you can copy-paste them (or use autotype or autocomplete) without ever seeing any sensitive data.
Doesn't have features that could sometimes mitigate some risks or be useful in other ways. Password managers often have auto-complete features that allow you to auto-type passwords only if the URL is as expected, and that can mitigate the risks of phishing (if the form isn't on the right page, you will notice that autocomplete won't work). Password managers also might have generators that help you create new random passwords, or might have ways to manage password expiration, or might have features that allow you to share passwords with other people without sending them (only in online password managers).

You should not be too worried about portability in the long term, as long as you keep backups and migrate or convert data if it is ever needed. You use passwords every day, it's not like something that will be sitting there for several years and might cause unexpected problems when you find out that "oops, this format stopped being supported years ago". If I'm not mistaken, KeePass version 2 does not use the old KDB format used by version 1 anymore, but that format can be imported. So it's not like a popular format will die all of a sudden. If you want to be safer, you will also be usually able to export to formats like XML or CSV that you can keep (encrypted) for backup.


Is $_SERVER[ ] a safe source of data in PHP?

This is taken from one of my questions on Stack Overflow: Which $_SERVER variables are safe?

Server controlled

These variables are set by the server environment and depend entirely on the server configuration.

'GATEWAY_INTERFACE'
'SERVER_ADDR'
'SERVER_SOFTWARE'
'DOCUMENT_ROOT'
'SERVER_ADMIN'
'SERVER_SIGNATURE'

Partly server controlled

These variables depend on the specific request the client sent, but can only take a limited number of valid values, since all invalid values should be rejected by the web server and not cause the invocation of the script to begin with. Hence they can be considered reliable.

'HTTPS'
'REQUEST_TIME'
'REMOTE_ADDR' *
'REMOTE_HOST' *
'REMOTE_PORT' *
'SERVER_PROTOCOL'
'HTTP_HOST' †
'SERVER_NAME' †
'SCRIPT_FILENAME'
'SERVER_PORT'
'SCRIPT_NAME'

* The REMOTE_ values are guaranteed to be the valid address of the client, as verified by a TCP/IP handshake. This is the address where any response will be sent to. REMOTE_HOST relies on reverse DNS lookups though and may hence be spoofed by DNS attacks against your server (in which case you have bigger problems anyway). This value may be a proxy, which is a simple reality of the TCP/IP protocol and nothing you can do anything about.

† If your web server responds to any request regardless of HOST header, this should be considered unsafe as well. See How safe is $_SERVER[“HTTP_HOST”]?.
Also see http://shiflett.org/blog/2006/mar/server-name-versus-http-host.

Entirely arbitrary user controlled values

These values are not checked at all and do not depend on any server configuration, they are entirely arbitrary information sent by the client.

'argv', 'argc' (only applicable to CLI invocation, not usually a concern for web servers)
'REQUEST_METHOD' ‡
'QUERY_STRING'
'HTTP_ACCEPT'
'HTTP_ACCEPT_CHARSET'
'HTTP_ACCEPT_ENCODING'
'HTTP_ACCEPT_LANGUAGE'
'HTTP_CONNECTION'
'HTTP_REFERER'
'HTTP_USER_AGENT'
'AUTH_TYPE' §
'PHP_AUTH_DIGEST' §
'PHP_AUTH_USER' §
'PHP_AUTH_PW' §
'PATH_INFO'
'ORIG_PATH_INFO'
'REQUEST_URI' (may contain tainted data)
'PHP_SELF' (may contain tainted data i.e. /index.php/evilstring)
'PATH_TRANSLATED'
any other 'HTTP_' value

‡ May be considered reliable as long as the web server allows only certain request methods.

§ May be considered reliable if authentication is handled entirely by the web server.

The superglobal $_SERVER also includes several environment variables. Whether these are "safe" or not depend on how (and where) they are defined. They can range from completely server controlled to completely user controlled.


How to check whether the cookie is set securely

Easiest route is to use a traffic interceptor, such as burp proxy, which lets you read cookie parameters. There are various other proxies which will do this as well.

This OWASP page has further information:

https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)


The final SHA in TLS_RSA_WITH_AES_128_CBC_SHA also means (among other things) that every packet has an HMAC-SHA-1 tag, to ensure the data has not been tampered with. This has length 20 bytes, as this is the digest length of SHA-1. So of the 116 bytes, the final 20 are this tag and we are left with 96 = 6 times 16 pure ciphertext (AES-CBC) bytes, the first 16 are the IV needed for the CBC mode, and there is some padding at the end but we have about 4 to 5 blocks of actual application data in here.


Turns out LXD is more secure than LXC by default: https://github.com/lxc/lxd/issues/2771


Why gethosbyname() is as bad as gets() by design?

Deprecated functions are generally tagged by static code analyzers simply because they're deprecated. (That's usually an optional setting.) Many secure coding standards specifically state: "do not use deprecated functions."

Apart from some long-ago-fixed bugs, gethostbyname isn't terrible, but that's no reason to use it in new code when a supported alternative exists.


How to use FDE without needing to share the encryption password

It comes to this: You want to implement a DRM scheme. Many before you have tried, all of them failed. It is not possible to give something (hardware, data) to users and prevent them from using it in an unintended way or copy it. You can make it harder, but you cannot prevent it. Others with more resources than you have tried (e.g. Sony, Microsoft, Nintendo to prevent pirating of console games) and in the end it all was broken.


Part of your answer depends on how your ISP allows you to connect to the Internet.

First consider the security of the device itself.

From the ISP side facing the Internet: If your hotspot is given a public IP address either permanently or temporarily it would be susceptible to attacks from the Internet, and while on-line it would likely get indexed in major vulnerability scanning projects like shodan.io or scans.io at some point (Note: you may be able to find similar devices like yours on sites like shodan.io). Likewise during these times your hotspot was on-line it could potentially be susceptible to attack, especially if no one is regularly going through efforts to secure it.

A quick way to check your security would be to determine your own IP when using the hotspot then perform remote testing against the IP in use and check to see if there are any signs that you can connect to it directly (insert long conversation here). Please note depending on where you live it may not be legal to test this either.

From the wireless side: This will vary a bit more based on the protocols both in use at the time and also the protocol supported by the device over all. You may access it using a more modern cipher in a secure fashion but the device itself may support many weak protocols which may enable an attacker to perform brute force attacks to access it. More importantly a LOT of these devices support web servers on their internal wireless network which could easily be attacked. Finally since the devices TCP/IP kernel is essentially accepting wireless connections from anyone around you it could also be attacked directly (this is far more difficult to do but it is a distinct possibility).

Second, consider how you are using it. What protocols does the device use to connect to the ISP ? are these secure ? does it fall back to insecure protocols when it can't connect to it's primary connection ? Does the device support roaming ? Similarly what protocols do you normally use to connect to it, could your connection be downgraded by an attacker, what's the weakest protocol supported, and do the weaknesses in the worst case scenario allow for an attacker to be able to sniff your traffic ? Do you trust the firmware of the device ? The software ? Where it calls home to ? All the protocols it uses ? Does your ISP track and monitor your connections and things like DNS requests ?

Third, how do you verify you are actually connecting to your device first ? Is it possible that someone nearby with a wi-fi pineapple could be intercepting your traffic then forwarding it on ? Do you verify that you are connecting to the correct device each time ? Do you have any type of certificate authentication in place ?

Basically, the security of these devices are not ideal especially if they don't receive regular security updates from the ISP (rare at best). That said they may not be much worse than any other random wi-fi connection you use anywhere else. If you have serious security concerns you should assume the worst and simply think of it as part of the untrusted Internet and leverage things like VPN's to minimize the risk where possible.

There are many other components about a secure connection that I am not including here (long conversation) but this will help you assess the risk areas and some of the attack surface for such a device.


"Time-Memory Trade-Off" is the generic terminology for an algorithm which improves (shorten) running time by using more space (memory); or, similarly, that improves memory usage (i.e using less RAM or disk, or using it "better", e.g. with sequential access instead of random access) at the expense of more computing time.

In the case of password hashing, the main TMTO algorithm is due to Hellman back in 1980; a number of local improvements were later discovered, resulting in what is colloquially known as rainbow tables. We can get a conceptual view of rainbow tables by considering the two endpoints of the spectrum:

Exhaustive search is about trying all potential passwords, hashing them all and comparing the value with the one that is to be cracked. This has the highest computational cost (average N/2 hashes to compute for N potential passwords with uniform probability) but uses only negligible RAM.
A precomputed table contains the hashes of N potential passwords, and a single lookup needs to be done. We don't count the effort of building the table because it can presumably be reused for multiple attacks, possibly by multiple attackers. The size of the table is proportional to N, but the computational effort is negligible (well, about O(log N), which is small).

Rainbow tables will fit in between. When the table is built, you choose a parameter t called the "average chain length". The table size will be proportional to N/t: it is reduced by a factor of t, compared to the precomputed table. On the other hand, each attack will imply a computational effort proportional to t2 hash computations, and t lookups. Depending on the operational conditions, the lookups or the computations will be the bottleneck (e.g. it depends a lot on whether the table are in RAM, on a SSD, or on a set of mechanical hard disks).

Salts completely thwart precomputed tables, including rainbow tables. Building a precomputed table for N passwords has cost N; building a rainbow table for the same N passwords has even higher cost (about 1.7*N). This is worth the effort only if the table can be used at least twice, to attack two distinct hash values; a one-shot table (rainbow or not) is not competitive with exhaustive search. But the point of salts is that there is not one function; in fact, there is a big family of functions, and the salt value tells you which one is actually used. A table built for a specific salt has absolutely no value in breaking a hash value for any other salt.

Bcrypt uses salts, so no tables, and no TMTO. Attackers are back to exhaustive search. Bcrypt also has weapons against exhaustive searches, namely a configurable slowness, obtained through a huge number of internal iterations: from the user point of view, there is not much a difference between a hash computation which takes 1 microsecond, and one which takes 100 milliseconds; but for the attacker, the latter means 100000 times the effort for his exhaustive search.

See this answer for more on secure password hashing. Short summary: if your password is strong (i.e. has high entropy), then even powerful agencies won't be able to obtain it by breaking the bcrypt hash upfront (they'll get it by breaking your kneecaps, but that's another story).


One computer with multiple OSs in different drives

If a machine is hijack by an hostile entity, then the attacker can gain full access to the hardware -- including every drive which is currently plugged in the machine. If the Linux drives are encrypted with a key that the Windows system never sees (which means that if you want to copy files from the Linux to the Windows, you have to do it from Linux, not from Windows), then such an attacker should not be able to read your Linux files. However, he can still do some considerable disruption.

Moreover, a boot disk is never completely encrypted, since at least the decryption code will be stored "as is". An industrious attacker, who gained control of your Windows machine, may plant some hostile code in the boot sector of the Linux system, so that it grabs a copy of your TrueCrypt passphrase the next time you boot Linux. Of course we are talking about a competent attacker here, but such people exist.

Apart from disks, the BIOS is commonly a re-flashable chip, and thus may serve as vector for hostile code. BIOS virus exist. Other pieces of hardware also have firmware, to be executed by the main CPU or even hardware-specific CPU, and such firmware may also be infected (this has been demonstrated in lab conditions, not sure it was spotted "in the wild"). If a machine is compromised, the compromise can go deep... But then, the attacker is really good, and really hates you, personally.

A "complete" solution would be virtualization -- the VM layer offers only virtual hardware to the potentially infected OS, keeping the rest of the machine clean. However, this is relative to how well the hypervisor can contain hostile code; hypervisor bugs occur (not often, but still...). A bigger problem will be that games will need some rather direct access to your GPU. It may not work at all, or imply heavy overhead; it may also provide an escape route for the attacker. After all, the GPU can run code and has privileged access to the main memory bus.

In practice, isolating the Windows OS in a VM will not provide absolute security, but it ought to block the not-so-good attackers (e.g. mindless malware), and may slow down the best attackers. I am not sure about the compatibility of games with virtualized GPU, though.

A much cheaper alternative, which does nothing about BIOS/firmware hacks but will protect your disks, is to make you Linux disks external. Just unplug them before booting Windows. If they are not in the machine at all, they will remain safe.


Which EAP connection is strong? Certificate based EAP connection or credentials based EAP connection?

Certificates are more secure.
With password submission, an opponent who succeed to impersonate the Radius identity will receive the challenge-response from the clients. He can bruteforce them to retrieve the original password which as possible as the password is strong.
With certificates, the private key can be bruteforced in a similar way. But bruteforcing an asymmetric key is not achievable as it is composed of many many more bits than a regular password.


CSP - Unsafe-inline or unsafe-eval for specific domain is allowed or not

That CSP directive will allows the use of inline resources, such as inline  elements, javascript: URLs, inline event handlers, and inline  elements, plus also allows the use of eval() and similar methods for creating code from strings.

So... don't bother using CSP. You've just allowed all the bad guys in anyway.

If you change that construct to

content-security-policy: script-src https://test1dummy.com/ https://www.google.com/ 'self' https://test2dummy/ https://test3dummy

then you've restricted scripts to run from code files on the site itself, plus any of the whitelisted URLS.

<script type='text/javascript' src='https://test1dummy.com/testscript.js'</script>

is valid, because test1dummy.com is whitelisted.

<script type='text/javascript' src='https://mydomain.com/testscript2.js'</script>

is valid - but only if mydomain.com is the domain that the CSP headers are running on. If not, then that won't be valid.

<script type="text/javascript">document.write("Hello admin");<script>

This would NOT be valid, now that we've removed the inline-unsafe option.

If we have a script which is running on a whitelisted domain, such as

<script type='text/javascript' src='https://test1dummy.com/testscript.js'</script>

and that script itself ends up modifying the DOM and injecting inline script, then that will also be caught by your construct and blocked. And so on, ad-infinitum. Tracking down the script that adds the inline JS is a lot of fun with CSP headers. In the same way, if you leave the 'unsafe-inline' option in place, any of your whitelisted domains can add inline code to your page.


Role Based Access Control is a well defined model, that comes with its own terminology. At minimum, RBAC has the following entities:

A User has one or more Roles.
A Role is a collection of Permissions.

A Permission (or privilege) is the right to perform an Operation (or action) on a Resource (or object).

So, from what you describe in your question, I would say that

your model is not complete yet (operation is missing);
your 'system asset/functionality' is a resource;
"that a user is allowed to access certain asset/functionality" is indeed a Permission


Comprehensive & current book on native application exploit research & development

There are many avenues of exploitation, and as you're noticing, they constantly evolve.  Your best bet is to attend a major conference like Black Hat, take copious notes from the briefings, and learn from the people who are actively exploiting systems today.

The speakers know that by the time they finish writing a book it's likely going to be out of date, and won't sell.  That's probably why there aren't too many books on the topic.  At least they take time to present what they've learned at these conferences, though, so there is information available.

If you have the chance (and the budget) the training sessions held at Black Hat are where you'll pick up the most specific and current knowledge on exploiting software.  For example, the Exploit Laboratory is a two day course, followed by two more days of Exploit Black Belt training.  Taking both would set you back as much as $6,000 (that's in addition to the $2K needed for Black Hat registration), but if you absolutely need these skills, it's an investment in yourself.

If you don't have that kind of money, DEFCON is only $180, a lot more casual, way more fun, and you'll have the chance to meet and hang out with the speakers.  Quite a few of them are the same speakers giving the same presentations they gave at Black Hat; others are a bit more anonymous.


How does an attacker know when he has the password?

Yes, your steps appear to be correct. The attacker hashes lots of words or sequences of characters until she finds one which matches the target hash.

Pseudocode:

hashlist = [ "a235b8320c...", "688b4302c57f3...", ... ]
wordlist = file.readlines("/path/to/wordlist")
for each word in wordlist:
    h = hash(word)
    # is the hash of this word in the list of target hashes?
    if h in hashlist:
        print "Found: " + h + " = " + word

As muchaho requested, here's some pseudocode for how it'd work with unique salts:

hashlist = [ "salt1:a235b8320c...", "salt2:688b4302c57f3...", ... ]
wordlist = file.readlines("/path/to/wordlist")
for each h in hashlist:
    salt = split(h, ':')[0]
    h = split(h, ':')[1]
    for each word in wordlist:
        if hash(salt + word) == h:
            print "Found: " + salt + ":" + hash + " = " + word

Notice that, after adding a unique salt to each hash, we have to try each individual candidate word for each target hash, rather than just hashing all words and waiting for one to match a hash. This increases the bruteforce cost when you've got multiple hashes to crack, but most importantly prevents precomputation attacks such as rainbow tables.


Can I spoof IP addresses when attempting to brute force a login?

When making a connection to a webserver you make use of the TCP protocol. It is a stateful protocol and requires a hand shake to set up.  The handshake is set up in three messages:

a SYN message from the client
a SYN+ACK message from the server
another ACK message from the client

Only after this is done you can transmit data. The problem with IP spoofing is that the SYN+ACK message will never reach you and you will not be able to send the ACK message in reply. This makes the handshake incomplete and you will not be able to send any data. Furthermore when bruteforcing the login screen you need to get a reply from the server that you logged in successfully.

Even if you do not take into account my previous statement  about TCP (for instance technologies which use UDP). If you spoof your IP the server will reply to the random IP and you wouldn't see the data either (unless you are on a hub like device or network and sniff all traffic AND provided the target device is on that same network).


Is request signing (digesting the request body) in a REST API necessary?

From the server, you may want two things:

to make sure that the client sending the request is indeed who they claim;
to be able to prove to third parties that whoever sent a given request is indeed a specific client entity.

Digital signatures are more-or-less needed to achieve the second goal. For the first goal, simple authentication is enough; HTTP "Basic Authentication", played within SSL (HTTPS), is sufficient. Your "type 2" method is a kind of authentication which relies on a client certificate; another equally good method, and simpler to activate, is to use client certificates at the SSL level (the SSL libraries then handle the nonce-timestamp-signature business themselves).

Neither method 1 or 2 yields a proof which could be used during litigation. Authentication convinces the server that the right client is at the other end of the line, but the server gets nothing which could convince a judge. For that, you really need a signature on the request itself, i.e. your "method 3". It is not that method 3 is "more secure"; rather, method 3 provides an additional functionality which may or may not be useful to your specific case.

Also, note that having a signed request does not completely replace authentication, if only because of replay attacks.


We cannot know what Teamviewer does with your data but there are some security risks you should watch out for:

Don't share your private details on a public screen. Some people use Teamviewer to get to screens that are placed far away or high up off the ground (advertising boards and etc) which are available to the public to see. If the Teamviewer details are displayed any user can login to that PC.
After using it renew the private code or uninstall it if not needed anymore so no one can login with the same code again.

If you really do not trust it you can try other programs such as standard RDP.

You can also read a little more about the Teamviewer connection in this question.


Encryption might not be required, but you could make it a bit more useful using public-key crypto.

The receiving machine has the public key, and:
1) Encrypts each file with a unique symmetric key
2) Encrypts the symmetric key with the public key.
3) Stores the two encrypted bits together.

The AWS processing machine has the private key, and can reverse the process.

An attack against the receiving machine can't:
a) Read previously uploaded files
b) Read new files without replacing the code / monitoring the machine in real time.

However an attacker (against the receiving machine), could still: Replace the public key, divert new files into their own store, or whatever they can manage against new files.


How realistic is to be 'hacked' by ONLY clicking a link

Seems like exploits of that magnitude would be rare, and highly valuable.

True, 0-day exploits are expensive, especially for browsers (and mobile devices). It likely doesn't make economic sense for an attacker to buy and burn one on a minor target.
However:

Can you guarantee you're always running the latest update? Even if yes, there may still be a patch gap.
A good example is the recent Chrome security update from just a week ago. It fixes CVE-2020-15999 which had already been actively exploited before the patch.

Project Zero discovered and reported an actively exploited 0day in freetype that was being used to target Chrome. A stable release that fixes this issue (CVE-2020-15999) is available here: https://t.co/ZRQe72Qfkh

(@benhawkes, 9:49 PM · Oct 20, 2020)
Now it's much cheaper (and common practice) to reverse-engineer the security patch and develop an exploit against users who didn't update yet. As ZDNet notes:

The finer details about CVE-2020-15999 active exploitation attempts have not been made public.  [...]
However, since the patch for this zero-day is visible in the source code of FreeType, an open source project, it's expected that threat actors will be able to reverse-engineer the zero-day and come up with their own exploits within days or weeks.

(Source)

They may not target your browser, but a web application or browser extension.
An attacker may have discovered or acquired a vulnerability in a password manager extension, or, possibly, an XSS vulnerability in a web application your company is using. This could be the web interface of your internal email server, a workspace app, an intranet bug tracker, etc. Exploits like these can often be triggered just by following a prepared link, and don't require additional user interaction.


Is the FIPS module of openSSL with fixed base address a security risk?

Having a known address is not a big risk. The only security measure that it defeats is ASLR, and ASLR is merely a technique to make exploits more difficult, it rarely makes them impossible.

The best defense against exploits is not to have a vulnerability in the first place!

This, not the fixed address, is the reason why using a FIPS-certified version of OpenSSL is detrimental to security. As new bugs are inevitably discovered, users must patch them as fast as possible, before exploits come out. As soon as you've patched the bug, you aren't running a certified version any longer. If you needed certification in the first place, you'll need to wait for a certified version with the bug fix, which typically takes months if the vendor even bothers to make one.

Given that the FIPS certification of OpenSSL is not really a security certification (FIPS 140 level 1 is little more than a check that the functions are computed correctly, the security aspects are virtually nil), the only reason to use the FIPS version rather than the latest stable release is if you need to tick the “FIPS validated” checkbox on a procurement form.


Does adding a password to BIOS prevent malware from infecting it?

Absolutely not. The BIOS password is only an authentication mechanism presented when the system boots or when a manual change to the configuration is made during boot. Malware which overwrites the BIOS typically does so by writing over SPI, the interface which the BIOS resides on. If malware gets enough privileges to write to SPI, and your BIOS does not set the proper lock bits that deny access to this interface at runtime, then it is game over. The contents of your BIOS flash chip can be modified completely, including the contents which execute the password authenticating code.

The only two ways to ensure malware cannot overwrite the BIOS is either to:

Have a BIOS which properly sets all the lock bits at boot, and the only way to make sure of that is to use the chipsec framework and understand the results it gives
Use a system which supports BootGuard, an Intel feature in some newer CPUs which causes the chipset to verify the BIOS itself before loading it, ensuring that it can only boot from a BIOS signed with an OEM signing key. This should prevent malicious BIOSes from running (as well as 3rd-party, open-source BIOSes like Coreboot and Libreboot).


How do CAs generate public keys without the private keys?

How do CAs generate public keys without the private key?

CAs do not generate any public keys. They create certificates which contain a requesting party's public key (from the CSR).

The private key is not necessary to extract a public key from the CSR. To do it execute:

openssl req -in your-request.csr -noout -pubkey

On the other hand, the command you included in the question (claiming its purpose is "to extract the public key from the CSR"):

openssl x509 -req -days 365 -in your-request.csr -signkey your-key.key -out your-public-key.crt

creates a self-signed certificate.

CA signs the certificate with their private key, not yours, hence they do not need yours.

The role of the CA is to provide a proof that a public key belongs to the entity claiming it belongs to.

CA might need to verify the domain of the requestor (domain-validated certificates), it might need to verify the documents of the requestor proving its identity

But CA does not need to verify the private key of the requestor because it's mathematically tied with the public key. If someone encrypts the message with their private key, it will be decryptable only by the corresponding public key.


Can CMP (Certificate Management Protocol) be used to issue certificates to mobile devices?

Yes!

Just make sure your device has a toolkit / library for communicating over the CMP protocol, and you should be good to go!

In particular, the 3GPP chose CMP as the main protocol for LTE mobile devices to request certs from a CA, update certs when they expire, and other lifecycle management operations. To facilitate the mobile device use-case, they made some additions to the CMP spec - now CMPv2 - so if your use-case needs some of the mobile-specific CMPv2 message types, then make sure you pick a CA that has CMPv2 support.


I guess I should have researched more rigurously: MAC vs Encryption

The flaw in my thought process was thinking an attacker needs to know the encryption key to attack. However, he/she may simply modify a cipher text without the ability to encrypt plain text.


It depends on which Hash your trying to crack. If its MD4/5 i'd go ighashgpu, for anything else, OCL-hashcat-plus

OCL-HashCat-Plus supports these hashes and ATI/Nvidia cards on linux and Windows and has an excellent reputation, active forums and i've personally used it to great success on both Nvidia and ATI platforms. It's also updated regularly.

I've also used ighashgpu for MD5 cracking. It claims to be the worlds fastest multihash MD5 cracker for MD5. From comparisons i've read, i believe it to be true. The downside is that IghashGPU only supports SHA1, MD5 and MD4 hashes. Additionally, i odn't think its been updated for 2-3 years.

Both are equally reliable as long as your hardware is stable in my experience.

Additionally, since both are command line based (ocl-hashcat plus has an optional GUI), its easy to incorporate them into a script.


Documentation Platforms for Information Security Team

Ticketing platforms are normally used for this kind of thing.

Many products that perform asset management also include a ticking function:

Spiceworks
Footprints
Netclarity

Tracking information is important, but so is tracking everyone's activity, relating incidents, and ensuring that incidents are closed and handled properly. For that level of management, you need a ticketing system.


Risk of man in the middle attack on AWS S3 due to wildcard SSL certs

If somebody has access to the private key of the certificate he can use it for man in the middle attacks. Such attack can be used to redirect the user to another machine if the DNS lookup for the host given in the redirect results in the IP address of the other machine. This can be a different hostname in the same domain as in the original request and thus can be covered by the same wildcard certificate. But it can also be a different domain, for example a domain controlled by the attacker where he also has a certificate to do MITM where he controls the full server (no MITM needed).

Actually, I don't see the problem with a wildcard certificate in this case. It is enough that the attacker has access to any accepted certificate (wildcard or not) and its private key in order to sniff and modify the traffic. The attack is also not limited to redirecting to another system.

  Can attacker redirect to: bad.s3.amazon.com/important.data (but actually corrupted data) with DNS/network rogue trick?

One way is to trick the user into using the wrong URL in the first place (social attacks). Then an attacker  near the user (i.e. local network, ISP,...) might try do DNS spoofing, ARP spoofing or similar to let the user access the intended URL but on the wrong host. Only, in this case the HTTP host header of the request will show the intended domain and the HTTP based routing inside AWS will cause the request to either end up at the good bucket or to get rejected since the good bucket is not accessible using the specific IP address.


Business-to-Business Security Disclosure and Agreement

One very common area where business contract to certain security practices is merchants contracting with credit card companies who require PCI compliance. Where both SOX and PCI compliance differ from your question is that the standard is set by an independent third party and the two contracting parties basically agree to abide by that independent standard.

Since the standard is objective and maintained by a third party, it is possible for someone to audit the firms for compliance, in fact most merchant agreements require PCI compliance testing.

While it may be overkill, you could have a contract requiring that your partner comply with either the NIST standards or Federal Information Processing Standards (FIPS). By writing simple language such as "Firm X warrants that it will comply with X standard" rather than trying to incorporate the provisions of a standard into the contract, resolution would be much simpler and less costly in the event of a breach or dispute because of trying to argue over what the provisions of the contract say, it becomes a simple matter of getting a third party expert familiar with the referenced standard to opine on compliance with that standard.

Finally you need not require compliance with the entire set of FIPS; for example you could reference FIPS 197 for data encryption and FIPS 112 for passwords.


You can have a look at http://www.exploit-db.com and http://www.cvedetails.com/. They don't have any REST service, but they do offer free searching.


Does bcrypt on top of md5 reduce its security?

Absolutely not. In fact, this is almost the standard procedure for migration from a weak hashing scheme to bcrypt in every project I worked with.

What usually happens is that a flag is set for each user indicating that their passwords use the old scheme, and whenever they login the application uses the backward-compatible login logic. Once the user logs in, you have their plaintext password, and now you can simply take the new password and store it using bcrypt only, the unset the flag. All new users use the new bcrypt-only scheme.

Alternatively, you can go by CodesInChaos's suggestion and stick to the new bcrypt(md5()). While he's indeed correct that there's no security gain, I personally like to keep it bcrypt() only.


Are ciphers with a strength of 112 bits considered weak?

I think you are mixing brute-force attacks where bit size is relevant and other attacks. The 112 bit you refer to are probably from 3DES. This algorithm is not considered weak because of only 112 bit strength but because birthday attacks are possible: see the Sweet32 attack.