Is there standard guideline on how the sanitized input should appear in the error message? Let us say your web app is sanitizing bad input and displaying the user what the bad input was. Before XSS measure was put in place web app is spitting out malicious script as is. For example Bad address value : <script>bad script goes here </script>

Now after careful sanitizing output could be something like this. Bad street address  : sanitized input. If the input was let us say not script like !@#$ street then it would output Bad street address : !@#$

Do you think using word sanitized is too obvious for output string that is malicious. I figure regular users wont see this. But bad guys are the only ones will see sanitized.
Or should the app not say anything at all if it sanitizes the input. Or should it replace some of the bad script tags with something other. What is the best known industry best practice here?

Any error message shouldn't provide information to the attacker other than their attempt was unsuccessful. Example: A password/username failure should say the attempt was bad, not whether the username was bad, or the password, or both. If it does, that information might be usable to an attacker in an effort to circumvent your safeguards. Something along the lines of: "Invalid Address" or "Address not Found" in the case of an Address field would be more than sufficient. The same goes for any other field as well.

Now, I am uncertain as to why you would re-display the malicious information to anyone attempting to insert malicious code into your system. It definitely reveals what is happening behind the scenes, instead of hiding the inner-workings of your system from the attacker.

The vaguer the better.


Can someone scan a website from a remote address and steal users login information? Suppose I have a website such as www.myforum.mysite.com, can an attacker sit down and listen to or scan my forum and get everyones username and password when they try to log in to my forum or site?

Is SSL necessary to avoid such a thing or is there no need for this? I was thinking the attacker can't do anything about it since users and hacker are not in the same network (e.g cafe net wireless network) ?
Thanks in advance

They can't snoop your traffic unless they are in a position of adjacency to any system in the routing chain.

When a client first connects to a server, the packet will go from their computer to their router, which then passes it on to the ISP's local routing server, which then passes it down a backbone (via a set of other large routers) and eventually to the server's ISP's local router, through the data center's network infrastructure, and eventually to the actual server. In total there may be as many as 40+ routers involved, if you're routing across the globe. If any single one of these is compromised, an attacker could sniff traffic.

However, your primary risk scenarios are:

User's computer is compromised.
User's network is compromised.
Server's network is compromised.
Server is compromised.

In scenario #1, you can't do anything to prevent the issue. Their system is compromised and their credentials can be stolen. You can help mitigate the issue by asking for 3 characters of a secret word each time they log in, but decent malware would just steal the session ID or something similar.

In scenario #2, an attacker can put their network adapter in promiscuous mode, which allows them to sniff the traffic on the network. If you don't use SSL, this traffic can be read, tampered with, etc. Protecting users from this scenario is the primary reason for using SSL.

In scenario #3, a similar issue occurs, but it's on the server network. The requirements for a successful attack here are largely based on network layout and configuration, since the position of the compromised system on the network is critical in terms of whether the attack will be successful. A switch between their system and yours could prevent promiscuous sniffing. It's pretty hard to know whether or not this kind of attack is happening (it's not your network, it's the hosting company's) so SSL is a good protection here.

In scenario #4, you're screwed again. Your server is compromised and no amount of transport security will save you.

There's a 5th scenario, whereby an ISP or backbone provider (e.g. Level3) are actively logging and sniffing traffic on their network. If you care about this, SSL can help. If you're worried about state actors (e.g. the NSA, with PRISM), then SSL isn't really going to help you, as they can use warrants to get hold of the server's private key and decrypt all of the traffic.


How secret is a dyn dns address? If I register with a dyn DNS service and am allowed to select my own prefix, how secret is the URL?

For example: I register with a dyn DNS service and ask for my prefix to be 204e9800998ecf8427e and the service gives me the URL 204e9800998ecf8427e.some-dyn-dns.org. I configure my home router to tell the service its IP and from then on the URL points to my router.

Given I don't tell anyone about the URL, who will be able to find my router (without using brute force on either an IP or DNS level)? Can the name be looked up in a registry? Can the DNS server of the service be probed to reveal the URL? Does it depend on the service?

It's not designed to be secure. It's designed to be convenient. A well configured DNS server should not reveal all names it controls, but all it takes is a minor misconfiguration somewhere.

Anyway, the entire IPv4 space is scanned regularly by various actors, including shodan.io. Do not assume any privacy for anything that is visible at a public IPv4 address. There's tools that will map out the entire IPv4 space in hours. Some people scan for their own purposes, benign or not - and others like shodan.io put it online in a searchable form for anyone (willing to pay).

In short; if you rely on your host name to be secret, you are doing something wrong. It should not be a concern.


How to securely provide data to a web server using a data warehouse? We have a data warehouse that stores prices for our products. Once every business day, new data points are added representing the day's price for each product.
On the website, a user sees this information on a page load. There are currently 7 products; analytics shows that the amount of page loads is about 100 per day.

The website server is an external server to our data center. The data warehouse server is internal to our data center and has other critical data (in different tables) not related and should not be accessible to the website.

The following approaches have been considered:

The data warehouse could daily push (SFTP) a CSV file containing the daily data to the web server. The web server would have a process running on a crontab every 15 minutes. It would check if the file had changed. If so, it would update its database with the data. Then, on page loads, the web server would query its database to get the data to display on the web page.

Usually, the push would only be once a day, but more than one push could be possible to communicate (infrequent) price corrections. Even in the price correction scenario, all data would be delivered in the file. The polling process would pick up the change and overwrite the data in the database.
The web server could request data from the data warehouse using JDBC or similar SQL connection technology.

However, a security concerns have been voiced. The concern is that by allowing the web server access to our data warehouse, SQL injection attack or some other external attack through the website could compromise the data warehouse. Measures could be put in place to reduce the risk, but the easiest and safest approach has been suggested to simply not allow any public facing system to directly access the data warehouse. In other words, the data warehouse can establish a communication with other servers (say to SFTP the file), but no server can initiate a connection with the data warehouse. Do these concerns seem reasonable and hard to mitigate?
A web service could be built, and the web server could call the web service that is hosted in our internal data center.
A process hosted in our internal data center could call the web server when it knows the data warehouse has data available. If so, how should this be done? HTTPS with some way to prevent other unauthorized clients from making the same call?

Which of the above approaches is best or is there a better approach than listed above? What are the pros and cons to an approach?

Given that your warehouse contains additional data that you don't want to expose a new attack vector to it sounds like your best option is to implement some kind of basic caching layer for this data on the web server that the warehouse can push to.

You'd have some kind of service running in your secure warehouse environment pushing a serialized representation of your needed data to a key-value store or similar (redis, memcached, whatever) running on your web server. This should be more straightforward and potentially more secure than having to deal with a CSV file. It's just a question of the service on the data warehouse's side knowing when and how to bust the cache.

As you mention there's no reason you can't connect to your web server with a secure HTTPS connection to do the push. Alternatively/additionally you could implement some basic encryption to protect the data while in transit, though it sounds like the data your web server needs isn't actually sensitive data so this step may be overkill.

Again, because your data warehouse has sensitive data in it I'd advise against trying to build some kind of API that the web server can query. There's nothing intrinsically wrong with doing so, but it certainly opens up attack vectors and makes the project much more complicated that it seems like it needs to be as it doesn't sound like you need to do different types of querying, you just need one particular chunk of data. Which really makes this a "one way conversation" where the burden is on the warehouse to make sure its "public" data is pushed out.

If in the future there's a need to query, update, or otherwise have a "two way conversation" with the warehouse from the web server it would be wise to silo that data away from the sensitive data before deploying essentially "open" API endpoint(s).

Good luck!


Signing but not encrypting trivial generic e-mails Let's assume my professor sends a signed but unencrypted (S/MIME) e-mail to us students like this:

  Dear students,

  there will be no class tomorrow. I'm sick.

  Regards Professor

Now I could simply replay this mail next month to my fellow students and my professor would be the only one showing up in the class room. All the other students would believe this mail is valid, since it is still signed (by my professor) and sent via a faked sender address.

My idea is, that this e-mail should have been addressed to a specific recipient ( Dear student A.. ). This way each recipient can simply proof via plaintext, if this mail is addressed to him/her.

Is it correct, that sending trivial signed but unencrypted (or encrypted-then-signed) mails like this should be avoided, since it could be turned against you?

If the email was addressed to a specific student, the same replay attack would be possible if you intercepted the email in transit.

The problem with this email is not the vagueness of the recipient, it's the vagueness of the content. It doesn't specify what "tomorrow" is. Would the email read "there will be no class on December 8th 2017", this "replay attack" would be foiled.

It could also be foiled if S/MIME would include the mail header with the date. There is a standardized way to do that since S/MIME 3.1 (embedding the message in another message as the message/rfc822 media type). The recipient would then see that it is an old email and that it is addressed to someone else (unless it's an email with multiple recipients). But I am not sure how well this is supported by email clients.

By the way, in my opinion it should be common etiquette in email communication to avoid relative dates for a completely different reason: you can't tell when the recipient reads your email. When the recipient reads the mail tomorrow morning and doesn't check when it was sent, then they will believe that "tomorrow" refers to what you would have considered "the day after tomorrow". This problem is amplified if you are in different timezones. Your "tomorrow morning" might be your recipients "this evening".


Do email clients reduce security? I have recently taken a security course, and have learned a lot about, among other things, the way passwords are stored, etc.

Afterwards I was thinking about the way that passwords are stored for email clients. If we provide our email clients with passwords for our accounts, those clients must save those passwords somewhere, and could only save them in plaintext. This would be the same for any client on a computer, smartphone, tablet etc.

I was wondering how much of a risk is this considered?

The user account password is stored somewhere "on the user". The user is theoretically responsible for protecting his own password. Ideally, he keeps it in his head and types it again when needed.

Some (most) users won't like it, and will instead enabled the "remember password" button, which will make the email client remember the password. If the email client is reasonable and runs on a reasonable operating system, this storage can be somewhat protected. For instance, on MacOS X, using Apples "Mail" application, account passwords will be stored in the user's Keychain, which is stored encrypted, the decryption key being the main user password (the one he types to open a session or unlock it). That way, the email account password is never stored as plaintext equivalent; an attacker stealing the complete hard disk of the machine will not immediately find it. (But it won't save the user against an hostile but discreet hijack of the machine, because of, at least, key loggers.)

Some other applications and/or operating systems won't be as reasonable as that.

Among possible mitigations:

Each user shall have his own account and password. This one, you already do. This ensures that a stolen password unlocks the account of only one user, which is better than nothing.
The email account password could be specific to email, and not be used anywhere else, in particular not to open SSH or RDP sessions. Users won't like it (they really prefer remembering one password than two). Also, most "password reset" systems fall back on email, so stealing an email account password can open access to a lot of other systems.
Implement one-time passwords. Hardware tokens such as this one are granted to users. Email applications won't have anything to save poorly.

However, user education is of paramount importance.


Database logs have multiple "Logon Login failed for user" from different IPs Background: I have an SQL Server database running on Amazon RDS

The AWS dashboard has a section for logs and whenever I check the logs I see the following:

2018-04-27 06:10:26.00 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:26.00 Logon Login failed for user 'bwsa'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:28.17 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:28.17 Logon Login failed for user 'ps'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:30.42 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:30.42 Logon Login failed for user 'uep'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:32.73 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:32.73 Logon Login failed for user 'sa'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]

First of all I do not have any of the above users.

Secondly I tried to check where those IPs were located using: https://www.iplocation.net/ , most of them are either from Vietnam or China ,the ones above are from Uruguay. (And yes I am aware that IPs can be spoofed)

Third the database URL was never publicly available.

Question: Is my DB server being attacked by some bot or automated process ? Should I be worried . What action should I take.

Firstly, IPs can be spoofed - but for TCP-based connections that actually log in, they can't. Or they can only with unbelievably high cost.

Secondly, is there a reason your database access is not restricted on a lower level via a packet filter for example? Usually, you would only grant connection capabilities to IP ranges that do have reason to connect to the database in the first place (instances of web applications, for example).

Thirdly, this looks like a scanning tool that tries to maybe tries to fingerprint the database. The huge delta of two seconds between the attempts may be for the dbms to recuperate and have a timing attack revealing version information - or just to not trigger an IDS. Yet, every IDS I know would/should pick up on that anyway.

So all in all: You should restrict access on Layer 3 or 4 and have that potential risk of brute forcing bots trying to login go away.


Linux: is sending prompt notifications on ssh logins a security measure? Scenario

One of my customers has some Debian based boxes directly accessible on the Internet with no firewalling on the ssh port. Those boxes are configured for an "instant" mail notification when a remote ssh user succesfully logs in:

me@server:~$ sudo cat /etc/ssh/sshrc

ip=`echo $SSH_CONNECTION | cut -d " " -f 1`
logger -t ssh-wrapper $USER login from $ip
echo "User $USER just logged in to $(hostname) from $ip" | mail -s "SSH Login" -- security@customer.dom &

I was wondering if this can actually be considered a (good) security notification, as the user who logs in is executing this command, and thus a malicious user might have control over such an event. It obviously happens milliseconds after login, so it should be very hard for an attacker to catch it, but I'm still not sure that a remote user can't circumvent this server side global sshrc.

For instance, I've been working for them for months and didn't even noticed it, but they received such a notification each time I logged in. They pointed my attention on it, because they said they changed something in one of their scripts, that is now generating much more connections than before, and thus they asked me to prevent this user from generating the notification in order to prevent the mailbox to be flooded.

As I'm an instinctive guy, I promptly added an if to match the user that shouldn't generate the notification, and that did the trick, but I think that this makes this measure even weaker than what it already looked like.

I don't know if it's possible, I tried many different searches that didn't returned anything relevant, but if a user on the client side may be able to specify a different path for the sshrc, for instance, this measure would miserably fail. If the MTA has a full queue and the user is able to elevate it might easily dequeue/delay the mail, that's why I'd swap the mail with an SMS service at least.

That's just some of my doubts, and that's why I'm planning to talk to the customer's CIO about this weakness, and would like to have your opinion about that. Of course, he will ask me "what do you think a most secure and still free solution would be?" Cash is always The King.

Honestly I have not yet an answer for such question, but I think that if they want to keep this "logic", at least, root should watch the log and notify when each user logs in. No every minute crontab as they want such notifications to be instant. So I think I might script something with fileschanged and tail, and either use SMS or keep the mail as the customer prefers. That would be executed by root and thus won't be under the user's control.

Questions

-Is it possible for a remote unprivileged user to disable server's sshrc client-side?

-The customer wants to keep this kind of notification, so good or bad, do you consider this way to get it a good way?

-Is there any other free way to be promptly notified on an ssh login, in a non circumventable manner?

-Don't you think it would be more secure switching from email to SMS?

About the insecurity, imho, you're thinking in the wrong direction.
What bad things do you think this system is preventing? Absolutely nothing, and that's why it cant fail to prevent it. On the opposite, it's added security; because if someone gains unauthorized access, there's at least a chance that he didn't know about (or couldn't prevent) the mail.

The only thing to remember the customer is that relying on the mails too much isn't good. As alert, fine, as single source of truth ("we are not hacked because there's no mail"), no. There are too many ways emails can fail, and too many ways to get hacked without proper SSH login.

About the firewall, if someone blocks incomding SSH connections then nobody can login anymore. That's probably not helpful.

About a method that doesn't rely on the user and shell, PAM can do it too. See https://serverfault.com/questions/395393/email-notification-about-each-ssh-connection-to-linux-server
There is even an option to deny login if the command failed, but in this case, that's not really helpful (no login because the mailserver is down or whatever, and successfully sending it to the server doesn't mean that it arrived at the receiver).

About SMS, no, they are not more secure than emails.


Certificate authority structure - best practices I'm working for a company that sells software products to customers some of which do not have the resources and/or know-how to build and maintain their own CA (used for the SSL communication of our software). In these cases we have to provide the certificates for them. The customers are completely independent and should NOT be able to communicate with each other, i.e. there should be no SSL trust between Customer I and Customer II. I have a rather general question about how to best built such a CA structure. These are the two variations that are currently considered.

Company Root CA with SubCA for each customer:

                    Root CA
        /               |              \
       /                |               \
 Customer I     Customer II       Customer III

Independent (Root-)CA for each customer:

 Customer I     Customer II       Customer III

What would be the pros and cons of each variant? Is there an established best practice for such a setup?

When people deploy HTTPS Web sites, they often buy "SSL certificates" from commercial CA. Thus, many sites will use certificates issued by the same root CA, and yet they don't trust each other. Same situation here: using a single root will not induce unwanted cross-customer trust relationships.


Protecting cellphones from USB attacks (a.k.a. Juice Jacking) We have several smartphone with encrypted data on them (BES, iPhone, Android) and want to prevent an unauthorized person from downloading information from the device via USB.

The visual assumption is that the USB file transfer mode is protected by a password; but then again, it is subject to implementation flaws and risks.

Are there any "known bad" or "known safe" smartphones with regard to USB security?
How does a corporation protect from these risks?
Does anyone have easy-to-understand explanations of the risks and what not to do? (e.g. use a public cellphone charging station)

The kind of attack you are talking is popularly coined as "Juice Jacking".

Are there any "known bad" or "known safe" smartphones with regard to USB security?

In my knowledge, NO.

How does a corporation protect from these risks?

By making policies (actually spreading awareness) about the threat
as many people yet aren't aware about it.
And popularizing the practice of Not Using public charging kiosks.
To charge your phones on the go, use a normal power cord as I'm sure non-smartphone mobiles are not that old to get their public charging outlets removed.

Does anyone have easy-to-understand explanations of the risks and what not to do? (e.g. use a public cellphone charging station)

The threat doesn't only get limited to downloading of all your data but also malware could be written to your device, to own victim for longer time.
What to do & Not to do list added in previous part.


Offloading hashing and symmetric encryption to HSM When using a (PKCS#11) based HSM (for S/Mime or PGP) the public key operations for signing or decryption is done by the HSM so that the key has to never leave the protected environment. The bulk part of those operations (for signing this is the digest creation and for encryption this is the symmetric cipher) can be done by the host.

However I noticed that most PKCS#11 implementations (even slow smart cards) do also offer symmetric ciphers and even hashing. I can see reasons for that:

by using the crypto interface and hardware implementation one can claim (hardened) FIPS compliance
by sending all byes instead of an attacker based raw digest to the component it reduces attacks with known ciphertexts (for RSA)
by letting the HSM generate or derive the session key it is never exposed (if this is actually supported?)
taking advantage of hardware random number sources for key generation

However there are a few things to that which do not really make sense, so I wonder what best practice is (mostly to define what configurability I should offer):

I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not exist. Or am I missing something?
I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no way to restrict a signing key to a safe RSA (padding) operation.
while HSMs claim hardware enhanced performance especially for the bulk operations most cannot keep up with modern general purpose CPUs (especially if the data has to be transferred over the network interface with secure messaging to the HSM, only co-processors or PCI solutions can be faster). So there is seldomly a speed advantage.

So I wonder, with HSMs, is it common to allow to specify two providers or make it configurable to fall back to local bulk operations? I checked some tools and most of them allow me to configure the crypto engine for the whole application or operation (like "hash+sign"). I hardly ever have seen a config file where I can say "for RSA use X and for SHA use y". I suspect most will fall back to default (local) hash if a non-hashing mechanism is selected? Are people happy with that?

I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not
  exist. Or am I missing something?

No, there is no such operation in PKCS#11. If you want to do that, you need to construct it from the basic function calls yourself: Generate a symmetric key (on the HSM to use its entropy source), wrap the symetric key with an asymetric key, do the bulk encryption.

  I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no
  way to restrict a signing key to a safe RSA (padding) operation.

PKCS#11 devices support a list of mechanisms which specify how the input data is treated. The most common ones are CKM_RSA_PKCS_PSS and CKM_RSA_PKCS for singing and CKM_RSA_PKCS_OAEP or CKM_RSA_PKCS for encryption (plus CKM_RSA_X_509 for raw RSA).

There is no way to restrict a key to a certain mechanism short of disabling a mechanism completely for the token. If you need that, you will have to do it on a lower level and access the device via PC/SC directly (if possible).

  while HSMs claim hardware enhanced performance especially for the bulk
  operations most cannot keep up with modern general purpose CPUs
  (especially if the data has to be transferred over the network
  interface with secure messaging to the HSM) – so there is no speed
  advantage

There is no real answer for that, the term HSM encompasses a very broad range of devices from two digit to five digit € numbers. Small scale crypto tokens or smartcards will definitely be slower when doing AES than a modern CPU but there are definitely devices out there, which are a lot faster (check the "SSL accelerator" category)


Why do web browsers provide websites with plain text passwords? Suppose I sign up for website.com with username "John" and password "Secret".

Currently the webbrowser supplies website.com with my real plain text password, and we must trust them to salt and hash it properly so that if they are hacked, damage to users is minimized.

Why don't web browsers hash and salt your password for you? What would the downsides be if instead, it communicated:

username: John
password: Sha256("website.com|john|Secret") =>
"655cd29ded358433da16867b682c21621664d26b9ca493ab224488dffce17050"

Maybe it's not the best scheme in the world, but is it worse than nothing at all?

With this scheme websites would have to keep track of which domain you signed up under, and you would probably want to modify the username to be all lowercase in the hash function so that the web browser communicates the same password no matter how you case your username.

The reason I suggest including domain or some other company id in the hash is so that rainbow tables can't be used for more than one site at a time.

--

Update: my question refers to web browser implementation of client side hashing, not one-off implementations in javascript. Relying on a one-off implementation of  client side hashing is similar to relying on server side hashing -- that is -- it is hard to be sure if a given website/company/implementation is not leaking your plain text password. This is about shifting the burden to the major web browser vendors.

What are the downsides? None, really, aside from significantly increased complexity1, which is rarely a good thing, as well as high migration costs for literally every website with a password field, which is also not a good thing.

But let's consider the implications anyway, to see if they outweigh the costs. There are two ways you could handle this hash:

Don't hash it on the server side. Now a database leak immediately gives attackers access to everyone's accounts, because they just pass the hash in like they'd have passed the leaked password in before.
Hash it (again) on the server side. This probably won't hurt security, unless your hash functions happen to interact in extremely weird and unlikely ways. But now everything is basically the same; the only difference is that instead of directly knowing your password, they only know the browser's hash of your password.

In neither case do you gain any advantage. #1 is obviously wrong when you consider malicious clients, and #2 only protects you from attackers who sniff your password and reuse it elsewhere. But that shouldn't even be possible, because you shouldn't be reusing passwords at all. There are so many other attack vectors -- keyloggers, phishing sites, and so on -- that it's a good precaution to take no matter how your password is handled by the websites you're a part of.

1: Some questions any implementation will need to answer include:

Where to store salts (or, if they're not stored -- as seems necessary -- how to generate them in a way that can't be trivially parallelized to defeat the entire purpose of salts)
What hash algorithm (and parameters) to use
How to handle it when hash algorithms weaken over time and need to be replaced
Where to actually implement the in-browser hashing step, which seems simple until you actually sit down and think about it
How to securely handle this cross-platform, so that the same user entering the same password sends the same hash to the website
How to provide password fields without hashing, since that's often useful for entering sensitive data like SSNs or credit cards, and needs to be known in plaintext by the webpage, in a way that bad websites won't abuse to keep their original bad code

It's incredibly complicated, and all that complication adds plenty of room for bugs. In security code, that's especially dangerous.


How can I duplicate an EVP_PKEY struct without knowing the underlying algorithm? I'm working on a TLS implementation (using OpenSSL 1.0.1s) that currently employs 1024-bit RSA keys for both encryption and authentication.
I want to upgrade to EC for performance reasons, but I need to remain backward compatible.

So I decided to use OpenSSL's EVP API to have as much common code as possible.
But, I've run into a problem when I want to read certificates from my RAM (stored in ASN.1 DER format), I can't find a way to completely copy an EVP_PKEY struct (no PKEY_dup or PKEY_copy or anything of the sort).

I want to avoid switch-casing the EVP_PKEY.type so the next upgrade will be smoother, any suggestions?

I managed to duplicate by converting to DER and back. the general i2d/d2i functions call the specific ones.

Code:

error_code_ENUM read_evp_pkey_from_ram (int       index,
                                        int       DB_ID,
                                        EVP_PKEY  **pkey_ptr_PTR){
  EVP_PKEY           *pkey;
  unsigned char      *p;
  unsigned char      *DER_PTR;
  int                DER_size;
  int                pub_len, priv_len, type;

  *pkey_ptr_PTR = NULL;

   if ((pkey = sensitive_EVP_PKEY_data[DB_ID][index]) == NULL)
     return error_code_no_key;

   type = pkey->type;
   /*passing NULL to char *out returns the length only*/
   pub_len = i2d_PUBKEY(pkey, NULL);
   priv_len = i2d_PrivateKey(pkey, NULL);
   if (pub_len <= 0 || priv_len <= 0 )
       return error_code_general_error;

   DER_size = pub_len + priv_len + 2 * sizeof(UINT_16);
   if ((DER_PTR = OPENSSL_malloc(DER_size)) == NULL)
       return error_code_no_memory;

   /*
    * store the key in buffer as:
    * |public key length | public key | private key length | private key|
    */
   p = DER_PTR;
   *(UINT_16*)p = pub_len;
   p += 2;
   pub_len = i2d_PUBKEY(pkey,&p);/*p is incremented here by the key size*/
   *(UINT_16*)p = priv_len;
   p += 2;
   priv_len = i2d_PrivateKey(pkey,&p);

   p = DER_PTR + 2;
   /*pass NULL to EVP_PKEY *key causes a fresh EVP_PKEY struct to be allocated and a pointer to it returned*/
   pkey = d2i_PUBKEY(NULL, (const unsigned char **)&p, pub_len);
   if (pkey == NULL){
      OPENSSL_free(DER_PTR);
      return error_code_general_error;
   }

   priv_len = *(UINT_16 *)p;
   if (priv_len == 0){
       EVP_PKEY_free(pkey);
       OPENSSL_free(DER_PTR);
       return error_code_general_error;
   }

   p += 2;
   /*now pass &pkey*/
   if (d2i_PrivateKey(type, &pkey, (const unsigned char **)&p, priv_len) == NULL){
          OPENSSL_free(DER_PTR);
           return error_code_general_error;
        }

   OPENSSL_free(DER_PTR);

   *pkey_ptr_PTR = pkey;

   return error_code_no_error;

note that i2d/d2i functions increment the pointers they are given


Apache, DocumentRoot and path traversal - /manual/ query A PCI scanner of a client is current showing a potential path traversal exploit. The document root is set to /home/somefolder/somewebfoldername/

YET, visiting ourwebsite.com/manual shows the Apache manual. The same goes for ourwebsite.com:8443/manual

The exploit highlighted is: ourwebsite.com/manual/howto/ssi.html?..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F/etc/passwd%00

I don't see exactly how this would display the contents of passwd, but my actual questions are two fold:

1) Would deleting the contents of the manual folder solve this?
and 2) Is this just masking a larger problem? I thought that apache could never reach outside of the DocumentRoot?

TIA

Apache itself should not serve files outside of its DocumentRoot.
However, in your example, the directory traversal is done as a GET parameter to the ssi.html file. A script have access to the filesystem with the same permissions as the user running the web server (nobody or www-data is common).

I find it strange that the manual for for SSI should contain a vulnearbility. I cannot find any details about this file being vulnerable pr default for any versions of apache.

It is possible that someone has planted a backdoor (knowingly or not) in this file. Does your url actually respond with the passwd file, and have you inspected this file to see if there have been any modifications to it?

1) Deleting (or removing the configuration for) this should remove the associated vulnerability.

2) This should not create a major problem. There are other ways to harden an apache server. In this context, running it in a chroot jail would make sense.


OpenID Connect access token to access protected API In our setup we need both reliable user authentication and scope-based authorization.

Consider the following scenario: a user logs in into our client (portal) using OpenID Connect, and our client wants to access a resource ("read") on a resource server (exposed by a backend service API) on a different server that is protected via OAuth 2.0.

Would it be a legitimate approach to add a custom "read" scope to OpenID Connect and use the received access(!) token to access a protected API requiring the "read" scope?

To answer my own question. Yes, it is legitimate to do that. We use OIDC for authentication and the access_token to protect the APIs.


How common is it for CAs to issue end entity certificates with Extended Key Usage marked as critical? Does anyone know whether it is common for CAs to issue end entity certificates, which can be used as client certs (possibly among other purposes), with the Extended Key Usage (EKU) extension marked as critical?
I think that most CAs do not mark EKU as critical in the certs that they issue, but I would like to have my assumption confirmed.

While absence of evidence isn't evidence of absence, the general answer is "no, TLS certificates do not get their EKU marked as critical".

RFC 5280 says "This extension MAY, at the option of the certificate issuer, be either critical or non-critical."
CA/Browser Forum's Baseline Requirements v1.6.3 has opinions regarding root EKU (don't have them) and intermediate EKU (if needed, SHOULD be non-critical); but on end-entity (or "subscriber" in their terminology) EKU it has no opinion regarding criticality.
For timestamp authorities RFC 3161 says "This extension MUST be critical."

So, critical EKUs exist, but it's not common to have critical EKU for a TLS Server or TLS Client certificate.


Safe User Login Questions I need help determining how safe the login is. First of all, I have been reading this:

The Definitive Guide To Forms based Website Authentication

It's really well written, great information most of which was either entirely new information or more detailed than I previously knew. However in my situation, I can't decide if it's helpful or not.

The problem is:

I have a login that will be used by 1 - 3 people max, with their passwords distributed in advance. The login itself will be online, but will function more like a closed network login, not being available to the global public visiting the website with clickable links to it -> (but with modifying the address bar to add /admin so that admins can access it.
With that being done, the user experience for even a handful of people is necessary. I want to put a dreadful "Remember Me" so that while only they will use the login to access the admin page, they don't have to login everytime.
The problem arises when a real situation today is to someone accidentally charge to the login or admin page. Either way since he/she isn't logged in, the page will forward him/her to the login page. For the global population that really went there accidentally, I will put a "Return to Home" link, but the concern is if that person tries to brutal attack the way in, or worse.
I thought about IP FILTERS but don't know how good that will be, today it's absolutely no effort to change an IP ADDRESS. I thought about Session lock with DB values on login, but that would lock the entire login for X amount of time (and if the brute force continues, the admins will never be able to login, because the lock will re-activate after the X time with the brutal attacks). I thought about captcha, but wouldn't that counter the remember me?
I don't like to false hope that nobody will even try to hack an innocent website, or spam the hell out of it. That is reality today. I just want to hear if you have a better way than what I think. If so please, tell.

Security by obscurity is bad. While developing it act as if the login form was displayed to every user of your website.
Remember to create the "Remember me" function in a way that does not store e.g. the password in a cookie. One choice would be having a random and unique login hash stored for the user. You then save the user id and this hash in a cookie. This prevents the password from being saved in a cookie and you can provide a "log out everywhere"-style button that simply changes the hash in the database and thus invalidates all "remember me" cookies.
While also somewhat of security-by-obscurity you could simply return a 404 error in this case. No need for people to know that something exists even though they do not have access to it.
Brute force attacks might be carried out by botnets so an IP filter alone is indeed not much help. So restricting the number of login attempts by account is the only valid choice. However, you can do this in a very user-friendly way by allowing 1-3 attempts without any captcha etc. and then require a captcha on every additional attempt. Of course locking the whole account for some time would be even better but then people could DoS your legit users.
That captcha will not interfer with "remember me" - the restrictions would only apply to the Username+Password login but not to the cookie login. That's not an issue since you can simply use 40+ character hashes for this purpose and you can safely assume that those won't be cracked using brute-force.

Since you just have a few users you might want to consider using SSL client certificates for authentication in case those users are not likely to login from random machines. They'd install the client certificate/key in their browser and then simply select it when logging in - no need for a username/password anymore. And SSL is secure enough so you don't have to worry about brute-force attacks for now. However if your users are stupid enough they might export the key without encryption and store that unencrypted file on their PC. But then again, this kind of user would also have a passwords.txt file on their desktop...


On a Linux server, is it safe to store a script containing DBI credentials in the cgi-bin of the DocumentRoot? I understand that (at least on Linux servers) the custom is to create a ScriptAlias from a cgi-bin directory located inside the DocumentRoot (i.e. /var/www/html/cgi-bin/) to a cgi-bin directory located outside of the DocumentRoot (i.e. /usr/lib/cgi-bin/ etc.)

Is this required for security reasons, or is it safe to simply store and run a script (for example, a Perl script containing DBI credentials) in the original cgi-bin of the DocumentRoot? What would be required for this option to be just as secure?

Those credentials have to be placed somewhere.  If you decide to place them at a place like /usr/lib/cgi-bin, you'd have to grant your web user access to that directory structure which would in turn make your system more vulnerable.

It is more common to place them one level above the web root as a compromise between the two.  This way you don't open much of your machine to a potential intruder while making it less apparent.  Do note that less apparent is relative to the intruder as many would figure it's part of an include right away.


What damage could be done if a malicious certificate had an identical "Subject Key Identifier"? I'm looking at the the Subject Key Identifier attribute of a CA certificate and am trying to understand the role it plays in validation and infer how validating client software could get it wrong.

What is the role of the Subject Key Identifier in validating a CA or End certificate?
Any knowledge of how it's implemented popular software packages would be helpful
What is the worst that an attacker could do if they could generate a public key that also contained the same hash?

As I read RFC3280 I see that the Subject Key Identifier (SKI) is like the glue that is used to build and verify the PKI chain.  The SKI also appears to be a more secure version than the certificate serial number and name that was also used to bind two certs together.

With regard to client validation of the certificate hash, do clients simply do a "pattern match" of the SKI, or is the chain SKI actually computed as described below:

  For CA certificates, subject key identifiers SHOULD be derived from
  the public key or a method that generates unique values.  Two common
  methods for generating key identifiers from the public key are:

  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
  value of the BIT STRING subjectPublicKey (excluding the tag,
  length, and number of unused bits).

  (2) The keyIdentifier is composed of a four bit type field with
  the value 0100 followed by the least significant 60 bits of the
  SHA-1 hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bit string bits).

One example risk I'm trying to mitigate is a malformed CA certificate with a public key that doesn't hash to a correct SKI (done by manual ASN.1 editing and resigning the cert from the attacker's root)

The Subject Key Identifier does not play a role in validation, at least not in the algorithm which makes up section 6 of RFC 5280. It is meant to be an help for path building, the activity which takes place before validation: this is when the entity who wants to validate a certificate assembles potential certificate chains that will then be processed through the section 6 algorithm. Section 4.2.1.2 describes this extension, and includes this text:

  To facilitate certification path construction, this extension MUST
     appear in all conforming CA certificates, that is, all certificates
     including the basic constraints extension (Section 4.2.1.9) where the
     value of cA is TRUE.  In conforming CA certificates, the value of the
     subject key identifier MUST be the value placed in the key identifier
     field of the authority key identifier extension (Section 4.2.1.1) of
     certificates issued by the subject of this certificate.  Applications
     are not required to verify that key identifiers match when performing
     certification path validation.

These "MUST" are obligations on the CA: to conform to the profile which RFC 5280 describes, CA must take care to match the Authority Key Identifier of the certificates it issues to its own Subject Key Identifier. Take note of the last sentence: this match is not part of what validation must verify.

It is recommended by the RFC to compute the key identifier through hashing, because it will minimize collisions, thus guarantee maximum efficiency of this extension for path building. However, hashing is not mandatory. CA can choose the identifier in any way as they see fit; and verifiers certainly do not recompute identifiers. This is pure byte-to-byte equality test. Also, I know as a fact that Microsoft's implementation of path validation is ready to build and try to validate paths where key identifiers do not match.

The worst that a rogue CA could do by reusing key identifiers is to make path building more difficult; this might trigger a kind of denial of service for verifiers who do path building through key identifiers and are too lazy to try otherwise. In practice, verifiers tend to build paths by matching the subject and issuer DN, not the key identifiers, so the practical impact should be close to nil.


If I'm PCI-DSS compliant, do I need to worry about GDPR? Next month, the EU's General Data Protection Regulation (GDPR) takes effect.

Our organization is already PCI-DSS compliant.

Do we need to do anything additional to make sure we are consistent with GDPR standards? Or are all the requirements of GDPR included within the PCI-DSS requirements?

Assuming GDPR apply to your organization, yes you should worry about GDPR.

PCI-DSS compliance doesn't imply GDPR compliance.

There are many concept present in GDPR and not in PCI-DSS or not with the same scope/expectations. For me you will have to take a close look of some principle of the GDPR like :

Admissibility of the user for the processing of his personal data
Necessity of the data processing
Transparency to the data subject
Limitation of use to specific purpose
Principle of data reduction (collecting as little personal data as possible)
Data deletion
Data controller and subcontractor

The two regulations have different scopes.

The GDPR scope is much more wider than PCI-DSS which is focusing on the handling and protection of card holder data. GDPR scope include all the personal data your organization is potentially handling. So it will affect many different department of you organization and not only the part which is manipulating card holder data. For example your HR department will be in scope of GDPR for sure as they are collecting & storing personal data of the company employees.


How bad is it to *not* reboot a server after kernel updates? I’m administrating a few Debian Linux server, and install package updates when apticron notifies me of them. Occasionally I see updates to linux-image-[something] packages, but don’t bother to reboot the server. How bad is this in terms of vulnerability?

You aren't running the new kernel until your reboot, so in terms of security the vulnerability you'd patch by updating the kernel isn't patched until you reboot.

Linux 4.0 has support for no-reboot patching. It's still in very early stages and the userspace tools (systemd, etc) don't yet support it but the code is there and hopefully it'll become widely supported soon.

Another solution would be to use something like Uptrack that can update some parts of the kernel without rebooting, but that requires a subscription and is only available for some distrubutions.


Which is better for server-to-server-communication: IPSec or TLS? Maybe you could help me with a small problem.

Would you recommend IPSec or TLS for a Server-to-Server-Connection? I need two or three arguments for reasoning a decision within my final paper, but sadly didn't find a criterion for an exclusion. The reflection of IPSec and TLS within my thesis is only a minor aspect, therefore, one or two main reasons for selecting TLS or IPSec would be enough. Do you think the possible compression within IPSec could be one of these main reasons?

More complete explanation of the scenario:

A user wants to login on a portal to make use of a service. The portal backend consists of the portal itself, a registration authority, user management, access control authority etc. Should I choose TLS or IPSec to secure those Backend connections? The delivered service does not have to be positionated within the backend, but it is reliable and is only connected with the portal. Here's a list with the connections I want to secure:

service (may be an external one) ---- portal

registration authority ---- user management

portal ---- user management

for a user-server-connection I've already made my decision, but the reasons I've used for this decision, doesn't work for a server-to-server-connection.

Thanks a lot in advance!

A picture of the scenario:

(red = problematic connection)

(in fact the model is by far larger, since I treat also other mechanisms like authentication, storage-mechanisms, storage access, access control, software-architecture, including possible technologies and so on. Therefore, securing the connections is only a partial aspect)

There are two main usage modes for IPsec: AH and ESP. AH is only for authentication, so I suppose that you are talking about an ESP tunnel between the two servers. All IP packets get encrypted and authenticated, including some header details such as the source and target ports. There are several encryption and MAC algorithms which can be used with IPsec; AES (CBC mode, 128-bit key) and HMAC/SHA-1 (truncated to 96 bits) are fine, and are MUST-implement, so any conforming IPsec implementation should support them.

For this "tunnelling" part, IPsec does things correctly, and so does TLS (assuming TLS 1.1 or 1.2, for IV selection with block ciphers in CBC mode). In fact IPsec can be deemed to be "more correct" than TLS because it uses encrypt-then-MAC instead of MAC-then-encrypt (see this); however, properly implemented TLS 1.1 or 1.2 will be fine too. Practical differences will occur at other levels:

To encrypt and decrypt data, your two servers must first agree on a shared secret. This is what the handshake in TLS is about; the equivalent in IPsec would be IKE. You might want to rely on X.509 certificates; or maybe on a "shared key" manually configured in both servers. Both TLS and IPsec support both, but any specific implementation of either may make one option easier or more complex than the other.
IPsec acts at the OS level; application software needs not be aware of the presence of IPsec. This is great in some cases, not so great in others. On the one hand, it allows some legacy applications to be "secured" with IPsec even if this was not envisioned during application development; and the security management can be done without being constrained by what the application developers thought of (for instance, if using X.509 certificates, you can enforce revocation checks, whereas a TLS-powered application might use a library which does not support CRL). On the other hand, with IPsec, applications cannot do anything application-specific with security: a server may not, for instance, vary its security management depending on which other server is talking to it.
Though TLS is normally used applicatively, it is also possible to use it as building block for an OS-level VPN between the two servers. This basically means using TLS as if it was IPsec.
IPsec being OS-level, its operation implies fiddling with OS-level network configuration, whereas TLS can usually be kept at application level. In big organizations, Network people and application people tend to live in separate worlds (and, sadly, are often at war with each other). Keeping everything at the application layer may make the deployment and management easier, for organizational reasons.

Summary: it depends. Use IPsec if you want to apply it on uncooperative applications (e.g. an application which does not natively support any kind of protection for its connections to other servers). Use TLS if you want to abstract away OS-level configuration. If you still want to use TLS and yet do so at OS level, then use a TLS-powered VPN.


Tracing the location of a mobile IP from an email I'm a TV scriptwriter - and not hugely tech-savvy, so please bear with me...

If the police have an email, sent by a suspect over a 3G or 4G network, could they use the IP address (since they know when it was sent) to find out - from the service provider - the precise location the email was sent from?

The problem with this scenario is that emails are typically not sent from the device itself, but from a central service.

In order to do what you want, the investigators would have to make a few hops:

to the email service (gets the user account details, including the IP the user used to connect with)
to the ISP the device used at the time of sending (gets the general location of the connecting IP, or if lucky, the known IP of the user's home)

At best, using 3G/4G, investigators might get the cluster of towers the user was in the middle of. No exact location.

BUT, with all that info, it might be possible for investigators to breach the phone's data or the user's other accounts and determine the location of the device using the multitude of location services modern devices have (Find My Phone, Facebook, Instagram, etc.) (Insert a whole host of legal issues currently in the news, like Stingray).

Edit:

You don't specify the country (or reality) you are dealing with. There are some countries that have set up massive detection nets so that every mobile device is physically tracked no matter where it goes. That way, investigators can have a real-time, accurate map of a particular device at any time.


AES CBC padding when the message length is a multiple of the block size Assuming that a 32-byte plaintext is encrypted by AES 128 CBC - is it mandatory to add 16-byte padding, according to the different padding schemes?

Padding is a way to encrypt messages of a size that the block cipher would not be able to decrypt otherwise; it is a convention between whoever encrypts and whoever decrypts. If your input messages always have a length which can be processed with your encryption mode (e.g. your messages always have a length multiple of 16) then you do not have to add padding -- as long as during decryption, you do not try to look for a padding when there is none. If some of your messages require padding, then you will have to add some sort of padding systematically, otherwise decryption will be ambiguous.

Padding does not add security. Badly implemented padding management can leak information (padding oracles) so you have to be careful with your implementation -- preferably by not doing it yourself.

(Of course, you would be better served with an encryption mode which does not need any padding and includes the much needed but much overlooked integrity check; that would mean GCM or EAX, not CBC.)


(How) Can outsiders discover the pages that are being hosted on my server? I have a web site hosted from my server.  Sometimes, I upload database manipulation scripts to a folder which is three levels deep in the website and run them using my web browser.  These scripts should not be accessed by outside users and I remove them within hours of uploading them.  Is there a risk that these scripts will be found or crawled if no other page links to them?  If so, then how can they be discovered?

I also have a test sub-domain located at user.mysite.com.   Is it possible for outsiders that do not know the sub domain to discover the existence of the sub domain?

Your "secret files" remain secret exactly as long as their names (with full path) remain secret. You may consider the path as a kind of password. Note that the paths will leak to various places (proxy, Web server logs, history of your browser...). If the files are important and sensitive, you should just do things properly:

Use SSL for upload and access to these files.
Setup an access password for the directory where the files are.

That way, you are back to known waters: you have a (part of) Web site with sensitive data and protected by a password. Make it strong, and you are all set.

In the case of the sub-domain: that "sub-domain" is advertised to the World at large through the DNS. It is possible to configure DNS servers so that outsiders cannot easily enumerate all sub-domains of a domain, but this takes some care. Moreover, whenever you access that sub-domain, your machine will use DNS queries (for the corresponding IP address); these queries travel without any particular protection, and contain the sub-domain name. Thus, this is an easy prey to passive eavesdropper (i.e. "people connected to the same WiFi access point as you"). It would be overly optimistic to believe in the secrecy of a sub-domain.


What attacks does Content Security Policy base-uri protect against? I have read up on base-uri and the HTML base tag, but what exactly is the base-uri CSP is meant to protect against?

I wasn't able to find any official reason. But generally, injection of a base tag can be used in HTML injections.

For example, consider that an attacker can only post very limited HTML (but can use base). Depending on the point of injection, they could now hijack existing forms to send the information (eg CSRF tokens, passwords, etc) to their server.

Of course, in this case setting form-action would be better than setting base-uri, but might not be practical (eg because legitimate users need to create arbitrary forms).

Another example would be a case where developers can't or don't want to restrict where scripts are loaded from. They have an XSS filter in place which prevents script injection, but they forgot to filter base. An attacker could now perform XSS via base HTML injection. Setting a base-uri would prevent this.

The examples might seem a bit far-fetched. But I would assume that it is these sorts of corner cases that the directives are meant to protect. The base tag has little practical use (at least in production), so why not provide the option to limit it?


Is disabling IPv6 an effective workaround for "Bad Neighbor" Vulnerability (CVE-2020-16898)? CVE-2020-16898 is a remote code execution vulnerability caused by the improper handling of ICMPv6 Router Advertisement packets by Windows TCP/IP stack. Microsoft's recommended workaround is to disable ICMPv6 RDNSS component.
My question is: In my system, I already had TCP/IPv6 unchecked in my network adaptor options, is this an effective mitigation?
Remark 1: Common sense tells me that by disabling IPv6 in the adaptor, the upper layer problematic ICMPv6 RDNSS should not be able to receive maliciously crafted packets. But I cannot be sure, especially with all the fancy functions offered by IPv6, such as Teredo/4in6/ other tunneling methods. If there is any material indicating that this is indeed/not the case, please do share.
Remark 2: I have tested the PoC for causing BSoD (https://github.com/0xeb-bp/cve-2020-16898). The PoC does not work when IPv6 is disabled in adaptor settings. But no tunneling has be configured in my tests.
Remark 3: I know that IPv6 is an essential component for Windows, disabling it could cause components to stop working. But it had been disabled for a long time and I would like to keep it disabled.

Probably disabling all the IPv6 stack is not a good idea, specially if you have applications that use IPv6. On the other hand, you have the source code of a tool that can generate the issue, so my recommendation is to block that traffic on the host firewall if possible, other option will be disable RA packets, but that depends on your operating system.
If you can not block the traffic probably the only option that you have is to disable the IPv6 stack.


Is it possible to protect my Windows XP users now that Microsoft is no longer releasing security updates? My office has about 20 PCs running Windows XP.  I got a message saying that Microsoft is no longer releasing any security patches for Windows XP.  However, we find that XP is very convenient for our work.  Please suggest some possible ways to keep Using Windows XP for my PCs without any risk.

Disconnect from the Internet, don't allow any external devices to be connected to your network and physically guard your computers to make sure that nobody violates the no external devices rule, and you'd be fine.

Otherwise the only option is to upgrade.  Since security updates are no longer provided, any newly discovered vulnerabilities would remain unpatched and an attacker (either external or internal) would have an easy time of using one of those unpatched vulnerabilities to access your systems if they can connect to them in any way.  Keep in mind that a large portion of attacks originate from disgruntled internal workers and unpatched vulnerabilities will mean that tools will become easily available to let even a relatively unskilled user make use of complex vulnerabilities.

There is no way to secure against this cost effectively other than to upgrade to an OS that still receives patch support to counter security flaws as they are discovered.  Honestly, if you are concerned about properly securing your business, it was past time to upgrade from XP even prior to the end of life.  There are numerous performance and security enhancements in Windows 7 that rendered XP obsolete from a security perspective years before end of life was reached.


Difference between SELF XSS and REFLECTED XSS I am confused about the difference regarding these two. If possible please use examples and payloads to explain the difference.

The self xss is basically social engineering where attacker convinces user to paste code into browser and execute it.
example:-I may ask you to paste a malicious JavaScript code into your browser URL bar which will give you logs about surfing data and look for such random tit-bits from which you will understand the difference between self xss and reflected xss with those logs.you may complain after trying that no results are found,but too late to complain.what I'm actually doing is, hacking your machine,masquerading the procedure to look like your help.

while reflected xss is browser executable within single HTTP response onto victims browser.
They are activated through clicking a malicious link.
Refer details,simple diagrams and example from this nice article(I haven't read it entirely but looks good enough to satisfy the thirst for information):-
https://www.incapsula.com/web-application-security/reflected-xss-attacks.html


Is it possible to browse HSTS sites over SOCKS5 proxy? I am unable to browse HSTS websites using SOCKS5 proxy in chrome browser...getting this error...

  This site can’t be reached The web page at
   https://www.instagram.com/accounts/login/?hl=en might be temporarily down or
  it may have moved permanently to a new web address.
  ERR_SOCKS_CONNECTION_FAILED

SOCKS5 by itself just make sure that the necessary TCP connectivity to the target is created and that all data are forwarded between client and server. It also might do a DNS lookup to resolve the hostname. A plain SOCKS5 proxy does not change anything with the payloads or changes the requested target server which means that HSTS will continue to work the same as without proxy.

But what you see here as error has nothing to do with HSTS at all.  ERR_SOCKS_CONNECTION_FAILED means that the SOCKS5 server was unable to create a connection to the requested target. This is a problem creating the TCP  connection already and has nothing to do with HTTPS and thus also not with HSTS.


Is MD5 ok to use if salted? This post:
http://www.gaiaonline.com/journal/?mode=view&post_id=19734573&u=8357925

Said that salted MD5 is ok but regular MD5 would not be ok.
I am a bit confused about this and would apprecaite a response.

The solution is garbage because they store unsalted MD5 hashes of passwords in the database. That is the weakest link in the solution. Nothing else matters.


SSH says Authentication tried for XX with correct key but not from a permitted host I am using and authorized_hosts file to authorise certain keys. One of those is restricted with the prefix from="1.2.3.4", the others are valid from anywhere.

When accessing from a machine that has an SSH key, but whose key is not in authorized_keys at all, and therefore logging on with a password, this message is generated in syslog.

What is disconcerting is that it says "with correct key". How is it a correct key if the key is not in authorized_keys?

Does it just mean "host offered an SSH key but I didn't recognise it and asked them to sign in with password"?

(I'm using ssh on Debian squeeze)

Some more details would be great to go along with this question...

But in the meantime are you aware of the ability to turn off password authentication in ssh?  If you want to make sure the only access to your machine comes from a proper and mutually agreed on ssh key configuration just set the following flags in your sshd_config

 ChallengeResponseAuthentication no
 PasswordAuthentication no
 UserPAM no
 PubkeyAuthentication yes

Then restart the ssh service.

As for the message in the log... have you seen this?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607602

Granted it's not exactly the same as you've described as you note the key isn't in authorized keys at all.  Though might be safe to assume the error message is just poorly worded or is being applied too broadly.

Good luck!


Trust store management best practice A typical scenario: a big company with lots of servers in all shapes and colors (on-premise, private and public cloud)
Each server (or rather each service) needs to maintain a trust store (a file in Java, or a file folder in Node.JS) that contains certificates required to establish SSL/TLS connections to other (mostly internal) services
Certificates change, get recalled, expire, - all that introduces service maintenance overhead
I'm looking for a software or an approach that would shift certificate maintenance from the service teams to the more appropriate group (e.g. information security)

Typically, one maintains a (mostly offline) root CA and then signs a certain number of intermediates to actually issue end-entity certificates.  With this approach, you ship the root CA in the certificate package for your system using a configuration management approach (e.g., on Debian, a custom ca-certificates package distributed via Puppet).
As for the end-entity keys and certificates, usually these can be distributed via something like Vault.  Vault, in fact, has support for running your own PKI.  It can also be used to ship globally trusted certs to systems.  You can automatically deploy systems every N days to rotate keys (or otherwise guarantee frequent deployments or certificate reloads); that can easily be handled by service teams as a requirement for deployment.  The certificate management can be done with Vault or other secret-handling tooling by the security team.


CSR from IIS 8 and Keeping my Private Key a Secret I've been trying to understand something. When you generate a CSR from IIS, how is the private key kept as a secret, or is it? Do CA's email you a certificate that includes your private key? Because nothing seems to tell me otherwise, and nobody should know your private key but you. Instructions to generate a CSR from IIS typically go like this: http://www.digicert.com/csr-creation-microsoft-iis-8.htm

A certificate, properly named, does not include a private key. A certificate contains a public key, and an identity, and is signed by a Certification Authority. Unfortunately, a number of widespread documentations use the term "certificate" to designate the combination of a certificate and the corresponding private key; this spreads confusion.

A certificate request (so-called "CSR") contains only the public key, not the private key. When IIS generates a CSR, it actually generates a new key pair (public and private key), then wraps the public key into the certificate request and signs it using the private key. The private key does not go anywhere; the CA never sees it. When the CA receives the CSR, it takes the public key from it, puts it into a certificate that it signs, and sends back. At no point does the private key leaves your machine, and that is how things should be done.

Now some CA insist on generating the private/public key pair themselves, and sending both the private key and the certificate to you. This makes things technically simpler for the CA, but entails potential security issues, because then the CA also has a copy of the private key, and the private key has somehow to travel back to you. Usually, a PKCS#12 archive (aka "PFX file") is used, because that format includes password-based protection.

CA-side private key generation can be a good idea when the private key is used for encrypting data permanently (e.g. a private key for encrypted emails), because loss of that key implies loss of data. Thus, that kind of private key should be backed up, and the CA is a nice central place for such backups. However, this does not apply to SSL, where the private key is used only transiently for connection establishment. Therefore, when the certificate is for IIS, then server-side private key generation should be used, and that's what IIS does.


Is it possible to hack a device via the USB port on an airplane? Nearly every airplane these days has 5V USB power port at every seat. Some of these appear to be configured for power only, while others appear to be configured for both power and data transfer, since I will sometimes get a prompt on my iPhone: "Allow this device to access photos and videos?"

I think on some planes it might be possible to play media from your device on the seatback screen, but I'm not sure since I've never done it.

Is there any risk to using these USB ports if a malicious person is connected to another port on the plane? And is the risk any different if you allow/disallow media access?

please add appropriate tags, unsure which ones to use

Yes. This could be dangerous. I'll try to explain a scenario where this may harm your phone:

Since you are using an iPhone and Apple's software is kept closed-source, we cannot know for sure whether it matters if you allow/disallow media access. I think it makes an attack somewhat more difficult, but not impossible. I will base my answer on Android phones, so that you can get a feel for the risk involved. iPhones can be as easily exploited but lets consider the following scenario:

An attacker plugs in a Rubber Ducky or a Teensy to the airplane's entertainment system. This allows him/her to perform an HID attack, compromising the machine that handles the entertainment system. The attacker is then able to run any process on the entertainment system.
Now you plug in your device. Assuming the same machine manages both yours and the attacker's USB ports, the process he/she is running can now infect your phone. The possibilities for an attacker are endless, and this scenario even helps him/her to employ some social engineering tactics (pretending to be the entertainment system to gain your trust, etc.).

A way of thwarting the threat is to use power only cables that you can make or buy for this use case.


Why re-verify with CAPTCHA on failed form entry? Is there a reason for sites to ask for another CAPTCHA verification when some other part of the registration form, e.g. the username, was invalid?

If the site has a means of knowing it's the same user in the same session, then no. So for example given a cookie or an ssl session then it seems OK to assume it's still a human user (within the limits of captcha).

If it's just a cookie that establishes the session (i.e. this is over http without SSL) then make sure to time it out tho. And you should be using SSL anyhow :-)


How to send SQL or HTML data over HTTP without triggering WAF rules? I'm working on securing an application that receives SQL and HTML-like information that is actually proprietry formulas in some cases, and parts of XML documents in other cases.
So the WAF thinks some HTTP requests are SQL or HTML injection attacks while they actually aren't.
So how can I send these formulas and XML informaiton without triggering those WAF rules? I tried encoding the data but that didn't work.

So how can I send these formulas and XML informaiton without triggering those WAF rules? I tried encoding the data but that didn't work.

A WAF is there to protect an application. The application should not need to work around the WAF but the WAF should be tuned to match the expected behavior of the application. This is no different from other firewalls or IDS, which need to be tuned to the expected traffic.
Of course, the application has to make sure that these requests are really innocent even if they might look like SQL or HTML injection to some (dumb?) WAF rule.


OSSEC - firewall-drop not working for rule 5701 I am setting up a OSSEC in local mode (on CentOS 7) to act as an IPS for a specific behavior. I am trying to use firewall-drop but it is not working (I noticed that the script can't see srcip). let me show you some outputs:

command:

<command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
  </command>

active-response:

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5701</rules_id>
    <timeout>86400</timeout>
  </active-response>

ossec-logtest output:

**Phase 1: Completed pre-decoding.
       full event: 'Jul 11 16:15:50 cloud sshd[31119]: Bad protocol version identification 'POST http://muabannha.org/ HTTP/1.1' from 45.32.161.230 port 53595'
       hostname: 'cloud'
       program_name: 'sshd'
       log: 'Bad protocol version identification 'POST http://muabannha.org/ HTTP/1.1' from 45.32.161.230 port 53595'

**Phase 2: Completed decoding.
       decoder: 'sshd'

**Phase 3: Completed filtering (rules).
       Rule id: '5701'
       Level: '8'
       Description: 'Possible attack on the ssh server (or version gathering).'
**Alert to be generated.

any clue?

Thanks in advance,
:wq!

It was a bug,

I found and fixed it then sent a pull request to OSSEC team: https://github.com/ossec/ossec-hids/pull/1194

I had to change the ssh-scan decoder. In fact it was needed to split ssh-scan2 into two different regex. The change can be found here.

Thanks,


How do I use DuckDuckGo securely? The Privacy Policy of DuckDuckGo.com mentions using HTTPs and POSTs affects the privacy of the search requests.

Since HTTPS is disabled by default, and POSTs is enabled by default, how does this affect my default search security?

Should the defaults be changed?

What browser are you using?
For example if you use firefox and set up DuckDuckGo as your main search engine it will use HTTPS by default.  Firefox DuckDuckGo Plugin
This are the instructions for firefox, chrome, opera & safari .

The great thing about DuckDuckGo, is that you customize it to your need (settings).  You can specify there under Privacy Settings to use HTTPS by default. At the end it tells you how to keep the changes (Load/Reset Settings).

You could follow the same instructions on this answer and would increase DuckDuckGo security, but IMO it would be a bit overparanoid.

Post is generally faster, and since DuckDuckGo isn't as popular as Google they want to leave a good first impresion (assumption), thus fast and effecient results is the priority. User can add HTTPS later on as their default search option.

Edit
HTTPS needs a initial handshake which can take some time, if most of the data is sent through the initial request, performance will not be that significant.

SSL may decrease performance, in a way; Search results can be large spaning pages (take in account duckduckgo provides scrolling rather than clicking on next page) this might burden the system to encrypt all of this.

Also take in account, not everyone need HTTPS, even though it is recommended to use HTTPS.


Secure Software Development I'm researching models on building security into the SDLC and so far have come across:

BSIMM
Microsoft SDL
Open SAMM

Are there any other documents and resources to look into? Specific tools that incorporate the principals of these models to help dev teams build secure software?

Also any resources that might be specifically targeted to Smartphone App Development would be great.

Microsoft SDL v5 is pretty decent and you have to full paper explaining the whole process that can be downloaded from MSKB: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=12285
If you need to get just a general grasp of the process, you can read a short and solid intro @ TechSurface: http://techsurface.com/2010/01/microsoft-security-development-lifecycle-sdl.html
There are several more esoteric ones, if you are interested:

Maturity Framework for Assuring Resiliency Under Stress
Correctness by Construction

For Android secured development, try those:

https://isecpartners.com/files/iSEC_Securing_Android_Apps.pdf - development focused.
http://developer.android.com/guide/topics/security/security.html - for system security considerations.


Signing Double Submit Cookies, where the value is a pseudo random string and a signature of it. Is this more secure? I'm not sure if I am describing something that has already been proposed. If not, I would like to coin this "Signed Double Submit Cookies" as a method to improve the Double Submit Cookies technique that attempts to prevent CSRF attacks.

Here is the concept:

Before outputting a web page, the server sets a cookie in the header where the value includes two values:

token value generated from a strong random number, and
signature value which is the signature of the token (or maybe simply a hash of it that has been salted).

When the client makes subsequent requests, it reads the cookie and includes the token+signature in the POST or GET requests (along with the cookie being automatically in the request headers).
When the server receives the request, it authenticates by:

checking if the token+signature included in the POST or GET requests matches the cookie value in the request header, and
taking the (cookie/query string) token value and signs it again and compares if the resulting signature matches the (cookie/query string) signature value. If matches, it proves that the cookie has not been blindly written by a subdomain or something else.

For the sake of argument, let's assume that XSS attack preventions have been properly implemented and SSL only is true.

Has this method been used before? Does it properly prevent the attack where a subdomain writes cookies to the parent domain?

[EDIT: Originally I had the token and signature in two separate cookies, but to simplify as suggested by @SteffenUllrich, I have edited the question to reflect both the token and signature in one cookie.]

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match.

This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be achieved by having some server side secret which is used in creating the verification cookie from the CSRF token, i.e. some signature using a server side private key, a hash of secret+token or similar.  In this case it does not matter if the signature is a separate cookie, is included in the verification cookie or if you only use the signature as the verification cookie.

Thus in this case I think your solution might help against the problems with native double submit but is unnecessary complex: you don't need two cookies but you could simply use the signature as the verification cookie. For verification just try to sign the CSRF token and if it matches the signature everything is fine. And the attacker is not able to create a token and a matching signature because he does not know the server side secret needed for the signature.

EDIT: Note that the signature should also include information regarding the current user, e.g. the session id. Otherwise it would be possible for some other user to obtain a valid token+signature pair and reuse it.

Note that none of this helps if the attacker gets access to both the CSRF token and the verification cookie because in this case this could be used for reusing this pair. But this is not the attack scenario double submit cares about, i.e. it assumes that reading the cookie is protected by using httpOnly cookies and a protected connection (https) and no way for XSS either.


Are there any HTTP servers that can detect two cookies with the same name, but issued from different subdomains? As a follow up to the Related Domain Cookie Attack question, I'd like to see if there are any servers that are able to detect instances where multiple cookies are sent from multiple domains.

In other words, what combinations of client software and server software can detect when multiple cookies have been issued for multiple domains?

It is impossible for the server to determine where a cookie originated from,  and if an application is designed properly the origin of a cookie should not be a concern.  Based on the Same Origin Policy for cookies:

  www.foo.bar.example.com may set a cookie to be sent to
  *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Using this simple rule the problem of an attacker setting cookie on a related domain can be avoided entirely.


Does the use of pepper for passwords violate Kerckhoffs's principle?  Kerckhoffs's second principle:

  "It should not require secrecy, and it should not be a problem if it falls into enemy hands."

Does the use of a pepper for passwords violate this principle, since the pepper is considered to be stored somewhere (code / server) in secrecy?

No. The principle means "The security of a cipher must not depend on the secrecy of the algorithm". Inputs are allowed to be secret. That includes keys, plaintext, and passwords.

Different people use the name "pepper" to refer to different things. I know of at least three. None violate that principle. The first two don't harm security.

The key used to encrypt password hashes and salts.
A second salt that is stored outside the password database.
A second salt that is randomly generated and not stored anywhere. The server and password crackers are supposed to brute force it as part of its password stretching procedure.

Definition one doesn't hurt security. A benefit to this is that it prevents offline cracking if the key can be kept secret.

The key might reside on a HSM, which would mean an extra layer of defense resistant to a lot of attacks.

At worst using encryption like this is equivalent to storing hashes unencrypted. It doesn't reduce security. (Just like using full disk encryption doesn't reduce secrecy.)

Two is no more insecure than normal salted password hashing. If this pepper is unpredictable (remains secret and can't be brute forced) then it prevents offline cracking. It is better than using one salt in certain contexts where hackers gain read only access to only some of your data.

The old justification for this method was that it would provide an extra layer of defense if the only type of access a hacker has is a database dump or SQL injection. Outside of that context it's pointless, but it never hurts security.

Three doesn't violate the principle, but it's inferior to just allowing the original password stretching algorithm more time to run. (Instead of forcing the server to run it more than one time.)

It's less secure if scrypt is used, for example.


If I want to protect a string from modification, is it enough to salt and hash it? There is a particular string (URL) that I need to send from my webserver to the browser. The browser will need to inspect the string and later send it back unmodified (aka request the resource that the URL is pointing to). If the browser could modify the string, it would be a security risk. So I need to make sure that the string has not been tampered with.

To do that I need to provide some kind of checksum in the URL which the server can validate, but which the client cannot generate. Two approaches come to mind:

Append some secret string (aka "salt", preferably pretty lengthy and random) to the URL and hash it with SHA1. Since the client doesn't know the secret string, he shouldn't be able to generate the hash for a different URL. My worry: Since he can gather several of these server-side generated URLs (on the order of a few dozen), maybe he can reverse-engineer the salt?
The same as before, but also encrypt it with AES. This is slower, but there's actual cryptography involved. My worry: SHA1 generates 160 bits, while AES works with 128-bit blocks. So the hash will need to be padded, probably with zeroes. Also, there are just 2 blocks. Will that not allow the attacker to discover the key easily?

Is any of these approaches really secure? Or should I try to do something else entirely?

This technique can be implemented reasonably securely. I would view this as an advanced technique for high performance: something you should only do if you're sure you know what you're doing. If you don't need high performance, it's simpler to have the server validate the user is authorised for each request. Having said that, this pattern is actually quite widely used, especially when a dynamic website hands off to a content delivery network.

You should use HMAC to generate your hash. You can use HMAC with any hash; for this purpose SHA-1 is quite adequate. Among other things, this protects you from Length Extension Attacks.

The simplest arrangement is that the hash contains a fixed server secret and the URL. The problem with this is that once a user has a URL with the hash, this is valid forever. You can't revoke a user's access to a particular resource.

We can partially fix this by including a timestamp in the URL. When you generate the hash, use the current timestamp. When you verify a hash, also verify that the timestamp is within a period you consider acceptable (perhaps 24 hours). There are other approaches to fixing this, such as including the user's session ID in the URL, although this would require a database lookup to verify the hash.


Data wiping. SSD VS eMMC how are they the same and how are they different? looking into how to properly erasing data from solid state devices is quite the topic with a different answer from just about every webpage I read. I understand there are issues with wiping data from SSDs due to the efforts of wear leveling, but now I read that eMMC supports TRIM, does that mean that eMMC storage will be just as complicated to data wipe as SSDs are?

I don't believe TRIM has a major effect on memory clearing; it's wear-leveling that's the main issue, as it means the OS could 'overwrite' data while it still exists on the physical media. TRIM is just telling the drive that a certain area isn't needed, and the drive can do what it likes with it.

SATA drives (including SSDs) have the ATA-SE commands, which allow you to tell the drive to delete everything on it, including any 'reserve' areas. Whether this is implemented correctly is another question, though. I don't think eMMC drives have this.

As eMMC drives are generally a single package, it's harder to remove the flash chips (or solder onto the pads directly) and read the flash without going through the controller - this could make it slightly more difficult. It's probable that eMMC controllers have debug modes that allow read-out of the flash, though.

I'd have to agree with childofsoong that you can't be certain that it's all gone without complete destruction.


Protecting vs Defending a system What is the difference between saying defending a system from attacks or protecting a system from attacks?

This question might be trivial to most of you but I really don't see the fine line here. In fact, I don't see a difference (maybe because English is my second language) but I was told that there is a difference!

In the context of a computer system being attacked, both Protecting and Defending are considered the same.

If this were a physical attack, then there would be a difference, but in IT Security both Protection and Defense are the same.

There is a term called Protected Storage, but this is not the same context

Defense could mean retaliation, where Protection would not. However, retaliation is not a desirable solution in IT Security, and is not directly effective.

In my opinion, Defense is a less desirable term, because computer systems deal in absolutes; Protected could seem more absolute, where Defended implies a finite amount of resources.

Personally, I would not use either term. Instead I would say 'Securing a system' from attacks. This is because success or failure when attacking a vulnerability is an absolute. This is quite different from physical attacks in which relate to 'strength' on both sides. DoS is an exception to this distinction.


Could've previous owner installed tracking software on my phone, even if I changed the SIM card? I recently bought a used mobile Android phone. Is there any way to install malware, tracking software etc. that is not on the SIM card, but on some other kind of memory disc?

I recently bought a used mobile Android phone. Is there any way to install malware, tracking software etc. that is not on the SIM card, but on some other kind of memory disc?

Yes.  When you buy a phone, you're trusting that the phone doesn't have malicious software installed on it.  Even the factory reset could potentially be compromised if the phone itself has been rooted and the OS replaced with a malicious version that doesn't perform a full reset.
In practice, it's unlikely that a phone you buy used has a malicious OS installed, so a factory reset is (likely) going to be sufficient to clear out any tracking software installed by a previous owner.
Of course, your paranoia may vary :).


If Cloudbleed affected a site that uses Facebook login, do I need to reset my Facebook password? I got an email from at least one site saying they use Cloudflare and due to the recently discovered leak they're recommending I change my password on their site.

But I don't have a password on their site, I use the "Log in with Facebook" option.

Do I need to reset my Facebook password, or take any other action on Facebook to ensure that leaked data cannot be used to access any of my accounts?  If I need to take some other action, what is it and how do I do it?

When logging in with Facebook your password is only sent to Facebook and not to the web site where you log in. The site where you want to log in asks Facebook who you are, and Facebook provides the site with some information and a secret token. Anyone who has this token can impersonate you on the site.

So your Facebook password has not been leaked, but your token may have been. To revoke the token, you can revoke the access the application has from within Facebook.


Signing webhooks: symmetric vs asymmetric I want to sign webhooks so that client services can verify that a request came from my service.

Looking around, it seems that most SaaS use symmetric keys shared by the client and the SaaS. Obviously, there's an overhead of generating and storing a unique secret for each client here.

It seems to me like asymmetric crypto is an easier solution here: sign the payload with a private key, publish the public key on your website, and you avoid the overhead of maintaining shared secrets for each client.

Given the above, is there a good reason many reputable SaaS (GitHub, Stripe, Slack etc.) opt for using shared secrets for signing webhooks? What are the tradeoffs of the approaches?

I suspect there's 2 reasons for this, preventing replay attacks, and key rotation.

With Github for example, it signs the message payload using HMAC-SHA256, and then places the signature on a header value, which can be verified by the hook endpoint.

A replay attack is simple enough, I generate a few webhook calls to my API, and since they're all signed by the same key, I can take those same payloads and use them to call your webhook, and it will at least pass the first authentication step.

You could check certain fields in the payload (e.g. the repositories full name) to ensure these are really 'your' webhook calls, but message types can be different depending on the event -- it's much easier to authenticate the message by checking one signature that's always found in a known HTTP-header, then it is to parse different message formats trying to extract these fields. More importantly, it's always a good idea to authenticate first and then process the message, authentication of a message based on a public key isn't really 'authentication' in this case, as I could easily impersonate it.

The second reason is key rotation, having just one key for ALL Github webhooks is a phenomenally bad idea! Should that key get compromised, an attacker could impersonate GitHub on any Webhook.

Worse yet, imagine if 5 years from now, GitHub wants to swap the public key -- now every GitHub webhook needs to change in a co-ordinated fashion, not easy when you have millions of webhooks. By having user-defined keys, Github has pushed the key rotation maintenance onto the users (as they should), and let the user define their own key rotation policy (which could be never!).


Is salted MD5 or salted SHA considered secure? Is using something like bcrypt or scrypt necessary? The hashes are so much longer to store in a database. Can one get away with using salted MD5 or SHA and still be secure?

MD5 and SHA-1 are emphatically poor choices for storing passwords. The problem is not their collision-resistance; it's that they're designed to be extremely fast. A modern GPU can attempt upwards of billions of passwords per second when brute-forcing through a list of hashes. This can shred through every possible eight-character alphanumeric password in at most a few days; that's with just one GPU.

The advantage of bcrypt and scrypt is that they can consume arbitrarily many resources; bcrypt has configurable CPU requirements, scrypt has configurable CPU and memory requirements. By increasing these work factors, you can dramatically increase the amount of effort it takes an attacker to attempt even a single password in your database.

As to the length: it's 2014. Storage is essentially infinitely cheap. Saving 40 bytes per record is simply not an acceptable excuse for selecting known-poor password hashing algorithms. In whatever project you're working on, surely there are more worthwhile tasks to spend your limited development resources on than this.


Made my password a few characters over the 64 character count and can't mount I can't enter my full password here (the screenshot) since veracrypt limits character count to 64 and my pass is 66. Is the data on the drive recoverable?

In general, when you make a password that's "too long" for a system, what actually happens is that it gets truncated to the system's max length, then hashed, and the result of the hashing function(s) is used for authentication purposes.

Therefore, the general approach to getting access when you created a password that's too long is to truncate the password yourself.  In this case, your password is likely to be the first 64 characters of what you chose as your password, based on veracrypt's max password length.