Gaining sensible information from advertisement displayed in web pages As we all know, JavaScript loaded inside a website A gets restricted to access the domain itself [same origin policy].

Unfortunately, same origin policy does not apply to newly created DOM nodes, that for example link JPEGs of third party domains. Thus, using this media link, a malicious script could pass sensible information to any third party using GET parameters.

Suppose site A loads a JavaScript file from an advertising company to display advertisement. Normally, ads get selected e.g. by user's previous search operations. Since the ad delivery process happens at the advertiser's server, privacy related information wouldn't get exposed to site A (in a direct fashion).

But technically, the JavaScript does some DOM manipulation to make the advertisement visible in pages of A. Therefore A could prepare a JavaScript file, which traces the operations of the script of the advertiser. Specifically, A could trace which exact advertisement gets displayed.

Suppose this arguments are correct, would A be able to regenerate sensible privacy information of users?

Specific example

User U uses Google to search for certain health problems.
Thus, Google analytics targets user U as ill regarding some disease.
A is an insurance company, which sells health insurance plans.

If U surfs on A's site, A could reject health insurance due to the fact, A scans advertisement presented by Google for U.

Does this is pure theory?
Or may this happen?
Does is actually happen?

As a rule, this doesn't happen in real life. Typically third-party content of this variety loads in a separate iframe, the content of which is (ostensibly) not accessible to the DOM of the outer page. There's been some issues with that in the past, but it seems that people have moved on, so presumably the issues are fixed.

More interesting than ads, though, is this same principle applied to thinks like the Facebook social plugins. The plugins will insert text like "Your friend Rory Alsop liked this page" along with pictures of your friends. This means that if the site operator has access to that content, then he can determine who your facebook friends are, and perhaps your own facebook identity.

This is much more significant than guessing your maladies from Google ads.


What is the exact problem if a website has an SHA-1 certificate? There was a recent question about trusting (or not) a website showing an SHA-1 certificate. I would like to know whether I understand the actual issue correctly.

The dangers are (a) that someone manages to redirect me to a different site, produces a fake certificate, and as a result I get a totally secure connection to a website run by evil hackers. And (b) that I connect to the site I want to connect to, but evil hackers decode what I send and receive.

Is it correct that hackers could at a huge but not impossible cost create a fake SHA-1 certificate for some small website, and at the same cost create a fake SHA-1 certificate for www.amazon.com? Since they would redirect me to their site, the security of the actual website would be completely irrelevant. That small website, and amazon's website, could have unbreakable security, which doesn't help since I never actually manage to contact them. In other words, if I see an SHA-1 certificate for Amazon, then it is most likely fake.

On the other hand, if that small website, or www.amazon.com, genuinely used an SHA-1 certificate, would that make it easier to decrypt the messages that I exchange with the site? Could a hacker somehow "break" the certificates and then easily decrypt all messages exchanged with amazon? Or is the communication just as safely encrypted independent of the certificate?

Thanks, Gordon, for answering the question: So using a low quality certificate on your site doesn't make your site any less secure. The problem is indirect: Low quality certificates could be forged, therefore browsers (and users) should reject low quality certificates, but as long as many sites use low quality certificates, browsers can't do that.

The issue is caused by the unavoidable phenomenon of "Hash Collision"

The dangers of trusting certificates that use  SHA1 starts from the technique used by Certificate Authorities (CA) to sign them and how the web browser verifies them.

As you may know the entire certificate is not signed, instead only the hash of the certificate gets signed.

Lets assume a certificate with the following data inside A with value A produces a hash 7d157d7c000ae27db146575c08ce30df893d3a64.

Now if a third party is able to create a certificate X with arbitrary value *************** such that the sha1 hash is 7d157d7c000ae27db146575c08ce30df893d3a64 then it can be used as a replacement and the browser would not be able to tell the difference as the hashes would be same and hence the signatures would match.

The villain in this story is no one else but our trusted Moore's Law

A sha1 hash is a 120 bit (20 bytes) one way hash algorithm. Which means it can produce 2^120 = 1329227995784915872903807060280344576 unique values.

This was more than enough years ago when all this story began but computers have become so fast that the computing power that is needed to produce a collision is dropping every year.

In 2012, Jesse Walker wrote an estimation of cost to produce a collision. Based on the estimates, collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021 ->https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

That means that many companies, organizations and governments today has sufficient computing power to produce a fake certificate that will pass through the test.

You are right, if there is a site using sha1 there is a great chance it can be broken. Not yet by small time hacker but it is better to close the holes before water starts seeping in.


Dual Code Signing: Should SHA-1 signature have a SHA-1 or SHA-2 timestamp? I am signing executables for our software both with a SHA-1 and a SHA-256 signature. In addition I timestamp both of these signatures.

Here I am wondering: I can timestamp the SHA-1 signature with a SHA-256 timestamp, but does that make sense? I would think that I include the SHA-1 signature only for compatibility, so I guess I should use a SHA-1 timestamp for it.

Is this correct, or should I use the SHA2-timestamp for the SHA1 signature?

The current layout looks like this:

What the correct answer is depends on your threat model.
If you consider SHA1 to be secure and are worried about compatibility you should use two SHA1 signatures and two SHA256 signatures.

This will allow a verifier to check your SHA1 signature while your cert is valid and check the SHA1 signature of the CA if it is no longer valid.

However, if you are worried that the SHA1 hash might be forged it might make sense to use SHA1 with SHA256 for the extra signature. This way when your certificate becomes invalid the stronger SHA256 signature will be required.

Note:

I'm not sure what the correct term for this kind of additional CA signature is. "counter signature" seems weird to me.
This scheme means that if you revoke your certificate because you got hacked the extra signature will still attest that at the time of signing your certificate was valid. I'm still not sure how you would revoke the signature in this case.


Any vulnerabilities from shorting browser's XML parser? I have found a way of forcing a site to return content-type XML to the user's browser even though the content is HTML. The browser then interprets this site as XML and throws an error since the HTML contains Javascript that doesn't decode to valid XML. Different levels of information is returned by the main browsers, but FF shows me:

XML Parsing Error: not well-formed Location: http://www.example.com/return_xml

Line Number 30, Column 1: var y= (a && a.b ...

The second & symbol breaks the XML parser. What type of attacks could be executed from this (if any)?

My first thought was XXE but I believe browsers disable that by default. Does this sound like a non-vulnerability?

By itself this is not a vulnerability. If rendering XML (valid or not) were somehow dangerous, browsers would not allow it in the first place.

Not being able to make it valid XML rules out XSS, as the content would have to be rendered for it to work. Besides, if there were an XSS vulnerability in the page, it would probably be exploitable even when rendering as HTML.

There is one attack that comes to mind, though: Reflected File Download. If you're able to modify both the end of the URL path and parts of the document content, you may be able to craft a link that causes the page to be downloaded with an "incorrect" file name extension such as .bat or .ps1. Running this file locally would execute a malicious script on the victims machine, e.g. to download malware.

This would not work in all browsers; Safari and IE8 seem to be the only ones that download XML files instead of attempting to render them. And even then the attack relies on the attacker being able to inject enough content to make the document a valid executable script in some language other than HTML or XML.

There's a good white paper on RFD (by Oren Hafif) here, including a bunch of details about different browser behaviours and potential ways of exploitation.


Differences between the OpenVPN SHA1 variations in the digest aglorithms OpenVPN offers the use of various digest algorithms (see list below).
I've read that the the digests, printed with a leading RSA-, DSA- or ecdsa-with- are simply due to a print function in OpenSSL and do not affect the algorithm mentioned afterwards (e.g. RSA-SHA, DSA-SHA and SHA, are all the same and can be equally used).

What I do not understand are the differences between the SHA1 digests SHA, SHA1, DSA-SHA1-old and RSA-SHA1-2. All share the same 160 bit digest size.

Complete list of --show-digests:

MD5 128 bit digest size
RSA-MD5 128 bit digest size
SHA 160 bit digest size
RSA-SHA 160 bit digest size
SHA1 160 bit digest size
RSA-SHA1 160 bit digest size
DSA-SHA 160 bit digest size
DSA-SHA1-old 160 bit digest size
DSA-SHA1 160 bit digest size
RSA-SHA1-2 160 bit digest size
DSA 160 bit digest size
RIPEMD160 160 bit digest size
RSA-RIPEMD160 160 bit digest size
MD4 128 bit digest size
RSA-MD4 128 bit digest size
ecdsa-with-SHA1 160 bit digest size
RSA-SHA256 256 bit digest size
RSA-SHA384 384 bit digest size
RSA-SHA512 512 bit digest size
RSA-SHA224 224 bit digest size
SHA256 256 bit digest size
SHA384 384 bit digest size
SHA512 512 bit digest size
SHA224 224 bit digest size
whirlpool 512 bit digest size

With OpenVPN 2.4.0 and OpenSSL 1.0.2k

Is this again an odd way of OpenSSL printing digests and they all simply represent SHA1?

edit: Interestingly, there's no plain SHA nor a DSA-SHA1-old, when you openssl list -digest-algorithms.

The reason they have the same digest size is because the same message digest algorithm is used.
The difference is what is being 'digested'.

SHA and SHA1 are likely equivalent, and both should provide a 'normal' SHA1 hash (i.e. something you could potentially replicate by running sha1sum INPUT)
DSA-SHA1-old and RSA-SHA1-2 are used for digitally signed digests - the details aren't necessarily relevant here, but basically, this avoids a MITM being able to just replace a payload + digest with something arbitrary (because a key is involved, the MITM would need to know that key to generate a valid signature for a given piece of data).


Secure message transportation It is secure to use the shared secret as the key for a HMAC? is it better to derive one key for all of the messages that are going to be HMACed or a key for each message?
Is it safe to use the shared secret as the key for the symmetric encryption after the shared secret has been exchanged using PKI?

Thanks.

It is secure to use the shared secret as the key for a HMAC? is it
  better to derive one key for all of the messages that are going to be
  HMACed or a key for each message?

As long as you use the key solely for HMAC, you can use single key for multiple messages safely. Many authentication protocols that issue tokens use one key for signing multiple tokens. JWT is one such example. .NET has it's own implementation.

But please note that in case you need to encrypt and then HMAC the message, you need to use two different keys. It is possible to derive these two out of a single, shared master key. See this and this.

There is a better approach though. You can use GCM mode for encryption which will do exactly what you need with a single shared key. Make sure you use it properly, especially concerning the IV. Study it's disadvantages too and see if they concern you.

  Is it safe to use the shared secret as the key for the symmetric
  encryption after the shared secret has been exchanged using PKI?

Yes, this is an approach used in SSL/TLS for example.


What is stored on a banking card and how is it protected? I wonder what is the content of a basic banking card having a chip, the kind you use for payment in any store, with a PIN, possible bank authorization, such as Mastercard or Visa or national banking schemes.

What kind of information is on the card ?
Is it quite similar to corporate smartcard (private key for signing/authentication) ?
Are there crypto primitives in it ?
Is PIN code protected from physical extraction ?

“Chip and PIN” banking cards have a chip, as the name indicates. The chip performs cryptographic operations and stores secret keys. The chip isn't just storage, it's a processor and the storage is not directly accessible from the outside.

The chip is physically protected against duplication — it's embedded in a protective layer and designed to self-destruct if someone tries to peel off the protection. There are software and hardware countermeasures to protect against side channel attacks such as electromagnetic emissions measurements. For more information about protection against physical attacks, see

Smartcard security on Wikipedia
chapter 16 of Ross Anderson's book Security Engineering (a recommended read in any case)
EMV Security? How is it possible that it's secure?
What physical, electronic, and software characteristics are important in a smart card?

The card stores the card number and other identifying information. It stores secret keys that it uses to communicate with the bank. It also stores the card number and a hash of the PIN. It also stores a PIN attempt counter: after three successive incorrect attempts, the card refuses to validate PINs anymore.

Smartcards used in corporate settings use the same basic technology, but banking cards are usually a grade above, incorporating the latest countermeasure technology when corporate smartcards often have previous-generation security (but sometimes higher performance, if they need to do asymmetric cryptography to sign messages). Smartcards used in access control are often several grades lower in terms of security (“cost-conscious”).


Would it better to enforce more complex passwords or passphrases? I have read in different places that passphrases offer better security and are more user friendly however, I have also read contradictory information thats says longer passwords are not really more secure than shorter ones...so enforcing complex passwords (special charcaters, upper/lowercase ect) would be better?

Any clarity on this with a decent reference would be much appreciated.

Length > Complexity in nearly all circumstances. It is easier for us to remember simple sentences, whereas complex passwords are more difficult.

"Abaconsandwich%ismyfavoritebreakfastitem!" is far, far, far FAR more difficult to guess by any method (bruteforce or dictionary) than something like "B@c0ntim3!?" This is because the number of elements is far more varied and long, and simple inclusions like a % sign inside the sentence can make password cracking all but unfeasible.

Good myths:
https://stormpath.com/blog/5-myths-password-security/

Everyone's Favorite:
http://xkcd.com/936/


Securing login form in a desktop app I currently have a desktop application which requires the user to have a username and a password. These credentials are stored on a webserver (myserver.com), so when he types the username and the password and clicks on the Login button, they're sent to the webserver. If the credentials are right, the server will return "ok", some user info, and the main form will be displayed. If not, the server will return "wrong" and an alert will be displayed.
However, this is very insecure, because a user can just edit the hosts file, redirect myserver.com to his localhost, which always returns "ok", and bypass the login screen.
I was told to generate a pair of RSA keys, and then encrypt a "nonce" (a random number) in the desktop app and send it along with the credentials. If the server could return the number decrypted, that would mean that it's actually my server.
I have to say that the webserver is hosted in Heroku so HTTPS is enabled by default, but I don't have any SSL certificates whatsoever.
This seems to be pretty good, but is this prone to a man-in-the-middle attack? An attacker could just redirect myserver.com to his localhost, send the request from localhost, receive the decrypted number, change "wrong" to "ok" (or change some user info) and send it back to the app.

How can I make a more secure login form for a desktop app?

Sprinkling crypto fairy dust will not prevent the attacker who controls the client from making the client do anything s/he wants with it. S/he can still redirect it to localhost, but now needs to replace the public key you embedded with the app with his/her own public key. Or attach a debugger and disable the use of crypto entirely. Or decompile, remove use of crypto and recompile. You can't control this, because it is all running on the client computer over which your attacker has total control and you have no control, and trying to control it is a losing strategy.

What you need to do is keep the assets that the user wants to access on your server, so it doesn't help him/her to change the client's behavior. If the client connects to localhost instead of your server, they can't access the assets since the assets are on your server, not on localhost. If they try to access services for which they have not yet logged in, your server should reject the request - after all, your server should be tracking who has logged in with a standard session management implementation (don't write your own; it's too hard and writing one's own always results in a vulnerable implementation).

Oh, and you do need to use crypto, but only where it actually helps.  Use TLS 1.1 or 1.2, or use SSHv2 to protect the network traffic. Select strong ciphers. Provide your users with your public key digitally signed by a trusted certificate authority. Encrypt the assets when you store them in your database. Use strong crypto like aes128 or 3des. Generate your key securely, reading the complete documentation about your random number generator, only using one that says it's ok for cryptographic purposes, that is standard, and without taking any chances that you might overwrite the seed instead of supplementing it (some documentation is very misleading, like Java's java.security.SecureRandom).

And finally, either hire a security expert or go learn about security yourself on OWASP.org (a great place to start, but be careful, because they often have mistakes, themselves).


Massive operational security hole Everything is based on phones now. If I have someone's phone I can reset their Salesforce password, access any SAS services etc.
Assume this

Hacker finds someone's phone number
Hacker buys (or works at) a T-Mobile franchise
Looks up the IMEI for that phone number at T-Mobile
Finds what services they use (eg Salesforce)
Calls Salesforce from that number on a cloned SIM card, does 2FA, resets the password and gets into the account.

How could this be prevented?

Scenarios like that are possible, but not without consequences. Your list continues like this:

A victim reports this to the police.
The perpetrator loses license to operate as a franchise due to this abuse.
T-Mobile hands over the identity to the police.
Criminal charges are easy to bring as the evidence is overwhelming.

A more typical SIM swap scam is to abuse operator's procedure to get a new SIM card to replace a broken or lost card. As the perpetrator impersonates the victim he leaves much less traces back to himself.
Also, SIM card alone isn't enough to bypass MFA. If that was sufficient, it would have been 1FA. Instead, the perpetrator must also get to victim's password in a 2FA or gain access to all other factors of a wider MFA.
Some services may allow resetting the password having access only to the phone number; now that's really a vulnerability! Also, a fallback to SMS authentication on e.g. Time-based One-time Password (TOTP) failure is not a good idea.


Does the ECDSA signature value (of an OCSP response) need to be DER encoded In OCSP responses by a certain eIDAS PKI I every once in a while get signature values which, when unpacked from their BIT STRING, contain an ECDSA signature whose INTEGER constituents have an unnecessary leading 00 byte and, therefore, are not DER encoded, e.g.

 376   10: . . . . . SEQUENCE {
 378    8: . . . . . . OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
         : . . . . . . . (ANSI X9.62 ECDSA algorithm with SHA256)
         : . . . . . . }
 388   71: . . . . . BIT STRING, encapsulates {
 391   68: . . . . . . SEQUENCE {
 393   32: . . . . . . . INTEGER
         : . . . . . . . . 6D 7F 95 D5 8E 9B E1 18    m.......
         : . . . . . . . . 60 DC A6 D6 91 37 0D B4    `....7..
         : . . . . . . . . AF D5 C9 A0 E8 21 40 4A    .....!@J
         : . . . . . . . . 94 8B 9F AA 6C DC F2 8C
 427   32: . . . . . . . INTEGER
         : . . . . . . . . 00 1B FD 92 CB 1E E2 A8    ........
         : . . . . . . . . 2B 18 FC 37 ED 42 D0 66    +..7.B.f
         : . . . . . . . . E6 52 63 88 47 88 EE 00    .Rc.G...
         : . . . . . . . . FF 37 CF 20 8F F8 3C C1
         : . . . . . . . . Error: Integer has non-DER encoding.
         : . . . . . . . }
         : . . . . . . }

Here already the ASN.1 dump utility claims that this non-DER encoding is an error, and so does the current BouncyCastle version (a check for DER encoding has been introduced in a October 2016 commit, unfortunately without any issue or norm reference in the comment).

I would like to know whether BouncyCastle is too strict or the OCSP responder indeed creates invalid responses. Unfortunately I have not yet found any norm (relevant for eIDAS PKIs) which clearly indicates which encoding may be used there.

RFC 6960 on OCSP says

  The value for response SHALL be the DER encoding of
  BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

but this only requires the BIT STRING signature to be DER encoded, not any data encapsulated in it.

TR-03111 (Technical Guideline on Elliptic Curve Cryptography by the German Federal Office for Information Security) says

  In X9.62 format the ECDSA-signature (r; s) is encoded as ASN.1 structure with the following
  syntax:

ECDSA-Sig-Value ::= SEQUENCE {
  r INTEGER,
  s INTEGER
}

  To embed the signature in a BIT STRING the DER encoded ECDSA-Sig-Value SHALL be the
  value of the bit string (including tag and length eld).

but a requirement by the German Federal Office for Information Security hardly is normative for eIDAS PKIs in general.

In X9.62 I only find

  While it is likely that these
  ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also
  be used.

According to ISO/IEC 8825-1:2003 BER/DER encoded Integers should be:

  8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the
  second octet: a) shall not all be ones; and b) shall not all be zero.
  NOTE – These rules ensure that an integer value is always encoded in
  the smallest possible number of octets.

apparently dumpasn1 does check exactly this:

    if( i == 0 )
        {
        if( ( value == 0x00 ) && ( ( ch & 0x80 ) == 0x00 ) )
            warnNonDER = TRUE;
        if( ( value == 0xFF ) && ( ( ch & 0x80 ) == 0x80 ) )
            warnNonDER = TRUE;
        if( warnNonDER )
            {
            intBuffer[ 0 ] = ( int ) value;
            intBuffer[ 1 ] = ch;
            }
        }

See: https://github.com/clibs/dumpasn1/blob/master/dumpasn1.c#L1398

So since the encoding says it is BER/DER encoded INTEGER, it should be.


When using public/private keys to secure app licensing info, couldn't someone simply replace your public key to defeat it? We have a simple C#9/WPF app that we're releasing on .NET 5 Core on which we need to introduce licensing.
From what I'm reading, one of the most common patterns to do so is asymmetric encryption, aka public/private key encryption.
From what I understand, you as the developer encrypt the customer's licensing info using a private key which only you know, save the results to a file or send it in an email to the customer. Then upon app launch, you use the public key--which you ship along with your application--to verify that no one has tampered with the license file.  Makes sense.
They also always say you don't need to worry about protecting your public key because it can only be used to decrypt data generated from your private key, which you have safe and protected.
My question is... what's to stop someone from just replacing the public key stored within the app with their own?
In other words, couldn't a user use your public key to decrypt the license file, make any changes they want, then using their own public/private key set, re-encrypt it, then simply replace your public key with theirs using nothing more than a simple resource editor or binary/hex editor?
My thinking is you would also somehow have to hash your public key to ensure it hasn't been tampered with either because if you can't validate the app is using the expected public key, then that defeats the entire system.

Yes, what you describe is a possible vector to crack your software.
The question is how likely it is that someone really goes that route. After all the public key needs to be stored somewhere where it is accessible to the program. And if that program runs on the computers of your customers, they can potentially can access that area too and change it.
But Ask yourself:

What's the audience of your program? Could they really do such things on their own? Hiring some developers to do the job might be more expense than just paying the license. And they'd need to redo that for every update.

How "honest" is the audience? Most people are.

Do you offer support and is it likely users, at least occasionally, need it? Usually support is bound to a license. And if someone phones for support and you look them up and discover you haven't issued them a valid license... Call the lawyers.

Or is the software popular enough that crackers could make money out of it on their own?

I mean if someone's eager enough, they can also just patch any license check away... But is it likely?


6 digit code to access the account? All my security senses are tiggling when I wrote the title, but here's the scenario:
When a user wants to connect to their account, but can't remember their password, they can use the "Lost password" form, which will send an email that contains a 6 digit code that expires in 15 minutes.
The interface, when the user hit "submit" from the "Lost Password" page, will be presented with a "Enter your code" form, that expects the 6-digits number received by email.
Now, that number is not tied with anything else, so anyone entering the right code will be able to access the app. This is the point that bothers me. To mitigate this, I was planning on restricting the number of submissions for this form to 3 per minute.
So to recap:
In order for an attacker to successfully access the account, (s)he must be able to successfully guess a code that will expire in less than 15 minutes, while being throttled at 3 requests per minutes, giving them the possibility to test up to ... 45 codes (quick maf).
Can this be considered non-secure?

The potential problems with the "lost password" form are several. Some of those I'm aware of:
It can be used to test / enumerate the accounts
So my form says: "Enter the username or email for your account" and then "Thank you. If this data is in the database, an email will be sent. If you do not receive the email in a few minutes, it is possible you entered the wrong username or email". Whether the user exists, or not. The page takes the start time for the submission and answers only after a set time has passed, a random number of milliseconds between 4900 and 5100.
It can be used to mount a denial of service attack
The page closes all resources and frees all memory before entering the final wait state and outputting the result, which is always '{ "status": "OK" }'. Also, there is a concurrent connection limit and a per-IP limit.
It can be used to harass someone (if the mail is right)
There is a limit of emails sent per day. And you cannot ask a new email if at least one minute hasn't passed (there is a Javascript timer to tell you this). Trying to circumvent the intentionally weak security will notify the sysadmin and lock you out for a longer time.
Also, when you request the "lost password", the account may enter a "password recovery" mode whereby the PIN and its expiry timestamp is recorded in the account aside with the intact password hash (the account has now two passwords, one of which will expire in 15 minutes). Any attempt to log in will afterward clear the PIN. This means that after every attempt to guess a PIN, the attacker has to repeat the whole "I lost my password" rigmarole, otherwise the PIN will simply be rejected.
If there is an open session for that account, and the session shows any activity during the recovery phase, the session is left undisturbed and the IP requesting the reset is blacklisted (which means that any PIN attempts from that IP will always fail). Before doing that, and only if the PIN is correct, the open session is shown a "Someone is trying to log in with your email. Is that you?" (failure to answer within a set time means that the session will be disconnected. The user having performed the successful PIN login is shown a countdown explaining that there is an outstanding session that has to be closed first
The above takes care of the "password brute force" possibility. It also tries to minimize discomfort for the legitimate users.
I sometimes use other checks on IP, browser etc., that allow putting an account into suspicious status. Users in this status may be restricted in some operations until they have performed some task that clears them, or the admin does so (e.g. if you just recovered the password and try changing some key parameters, you're told that the change was approved and pending -- but what really happens is that the admin calls you on the phone).


What is the rationale of binding SSL certificates to a domain name? As I understand them, SSL certificates contain a domain name, a public key and the giving CA.
Why is it important to include a domain name?
Why isn't it enough that the CA considers the public key as trusted and that the said server indeed has the private key associated with it?

Because, when using the PKI, you do want the CA to confirm for you that the holder of the key is indeed the legitimate owner of the domain.

If if worked as you suggested, I could get a certificate and MITM your server, posing as your server on your domain and present a valid certificate (as the domain I'm presenting it for is not restricted).

The CA does not confirm that the holder of a key is trustworthy but does confirm that the holder of the key is also the legitimate holder of the domain.


Is access token confidentiality also ensured in the Authorization Code grant type in Oauth2.0 One of the really nice articles I came across while trying to understand the various grant types in Oauth2.0 was this. The author really has done a good job at explaining quite clearly what various grant types in an Oauth2.0 flow look like. I also followed a few more articles like this and this. Each one of them explaining well about the flows involved in the different grant types.
However, there is one thing that I am getting confused with & hence this post. Would love to understand what am I missing here.
In the Authorization Code Grant flow, after the Authorization Code is shared with the client (a web app page that the end user is accessing in their browser or a mobile app that the end user is accessing), the front end web page of this web application sends the Authorization Code to it's backend. The web app's backend (server side code) then exchanges this information (along with other info, like the client secret etc.) with the authorization server for an access token. Till here things are clear. (or please correct me if my understanding is not correct here).
Now the confusion is:
Does the web app's backend server send this access token back to it's front end & then the front end makes all subsequent calls, with this access token, to access the resources?
OR
Is it that the access token is never really sent to the web app's front end & instead the front end code simply sends all resource access requests to it's backend which then fetches the resources, using the access token from the backend, & forwards it to the front end?

This is not something that OAuth specifies. OAuth specifies how you obtain a token and a little bit, how they are used.
Both patterns you describe can be seen in the wild. The first is called the "backend for frontend" pattern. This is generally a good idea, because a user then cannot directly access the ressources, as the access token is never presented to the user.
The second one is mostly seen in Single Page Applications and should be used, when there is no backend present that can handle the tokens for you. You need to make sure that it is not a problem, that a user has access to the access token. (For example by accessing protected resources that only a backend server should access)


What security exposure (if any) can result from lots of apparently odd referrers in server log I see relatively many referrers such as the following (as reported by Webalizer) in a web server log. The server is located outside Russia and it's a small one.

  8     3  http://tiandeural.ru/
 19     3  http://timetorest.biz/
 20     3  http://vigrx-original.ru/
 21     3  http://www.rukinolenta.ru/
 22     2  http://www.arenda.triumf-realty.ru/

What is going on here? Why are all these entities (or single entity) taking the trouble of referring (perhaps even linking) to the site? Is this some attempt to increase page ranks or an attempt to draw naive admins to (perhaps) phishing sites? In any case, the pattern looks suspicious and I am wondering if there is any better reaction than just ignoring such blocks of apparently odd refer(r)ers.

There is a thing called Referer spam, of which your case may be an instance.

Alternatively, the requests may be part of some sort of automated crawling and testing for possible vulnerabilities, and the attacker includes random HTTP referer header values as a way to make the requests look more "genuine" and thus bypass some basic intrusion detection systems. When you have a server online, you soon get lots of very stupid requests from mindless botnets which look for new hosts to infect, and can afford to try random IP addresses blindly with attack attempts which work on only one in a million machines (botnets are patient).

Best thing to do is to ignore them. The real problem with such requests is that they reduce the usefulness of logs, and may make you miss some important clues about more targeted and dangerous attacks.


Should Failed Login Attempts Be Logged Should failed login attempts be logged? My doubt is that if there is a distributed brute force attack, it might exhaust the available disk space of the database. What is the best practice for this?

I'm protecting a public-facing web server with sensitive data.

Based on the answers so far, one other question that occurred to me is whether web server logs would be enough for logging such attempts. Would it be redundant to log them in the database?

Yes, failed login attempts should be logged:

You want to know when people are trying to get in
You want to understand why your accounts are getting locked out

It's also very important - older Windows logging process never emphasized this enough - to log successful login attempts as well.  Because if you have a string of failed login attempts, you really really really should know if the last one was followed by a successful login.

Logs are relatively small.  If there was enough login attempts that logging would cause a problem, then "not knowing about the attempts" is probably a worse-case problem than "found out about them when we ran out of disk."

A quick caveat - as @Polynomial points out, the password should not be logged (I seem to recall that 25 years ago some systems still did that).  However, you also need to be aware that some legitimate login attempts will fail when people enter their password into the username field, so passwords do get logged.  Doubt me?  Trawl your logs for Windows Event ID 4768:

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

Correspondingly, you should limit access to these logs to the necessary people - don't just dump them into a SIEM that the whole company has read access to.

Update to address question edit:

  Based on the answers so far, one other question that occurred to me is
  whether web server logs would be enough for logging such attempts.
  Would it be redundant to log them in the database?

Best practices are that logs should be forwarded to a separate log aggregator in any case - for example, consider PCI DSS 10.5.4.  In practice, such an aggregator is usually a SIEM, and functions like a database rather than flat log files.

So, yes, it's "redundant" by definition, but it's the kind of redundancy that's a security feature, not an architectural mistake.

The advantages of logging them into a database include searching, correlation, and summation.   For example, the following Splunk search:

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,host

Will allow us to roll up authentication failures by user and host:

Note that the ability to query discrete fields like 'user' and 'host' is dependent upon the SIEM picking logs apart and understanding what means what.  The accessibility of those fields here is a side effect of Splunk automagically parsing the logs for me.

Given that your original question dealt with space constraints, it should be pointed out that any database or SIEM solution is going to take more disk space than flat text file logs.  However, if you use such a solution, you'll almost always put it on a separate server for security and space management reasons.  (There are even SIEM-in-the-cloud solutions now to make life easier for you!)


How to prevent bypass of user agreement window I have a file on my website which users can download. After clicking the download button, then I show a div with user agreements and two buttons, "accept user agreement" and "decline user agreement".

If the user presses "accept user agreement" then I append the GET Parameter &useragreement=1 to the download URL, otherwise &useragreement=0.

Then on the server side i check if useragreement == 1 and if true, initiate the download, otherwise initiate a page reload.

However, a user could just manipulate the url and add &useragreement=1 to download a file without even reading the user agreements.

Questions

A: Is it considered as cyber crime (hacking) to bypass the user agreement window like this?

B: How can I improve it?

Whether or not this is a cyber crime depends on the jurisdiction you and them are in, and even then it is a topic for law stackexchange. So I am not going to talk about that.

If you want to make sure that only users which at least saw the user agreement can download a file, you need to give them (or rather their web browser) a secret together with the license agreement.

Don't have the user agreement page set a simple 0/1 token.

When you generate the user agreement page on the server, randomly generate an unique token for each page impression. Put that token both into a hidden input field on the agreement-page and store it in your database.
Have the submit-button below the agreement also submit that token
Have the download-page check if that token is in the database. If it is, allow the download and delete the token from the database so it can not be used again.
(optional) regularly purge tokens from your database which weren't used within X hours to prevent your database form getting too large and slow due to unused tokens accumulating in it.

By the way, this is also a good precaution against bandwidth stealing, because deep-links directly on your downloads won't work. Anyone linking to files on your website will have to link at least to the agreement page.


Active Directory Server and Mimikatz Is it possible to use mimikatz to dump plaintext passwords of users in network by injecting mimilsa into lsass in Active Directory server? Basically other than dumping SAM which contains all hashes of everyone in the AD domain, can you do anything else with mimikatz?

Are you targeting to dump all the plaintext password of all users in AD?

As far as I know, you can use mimikatz sekurlsa module in dumping  passwords, keys, pin codes, tickets from the memory of lsass in selected workstations, not in lsass of AD Server.

Refer to this https://github.com/gentilkiwi/mimikatz/wiki/module-~-sekurlsa#logonpasswords

If you want to dump all the user password hash in Domain, another thing you can do in mimikatz is DCsync which you can pull the password hash, as well as previous password hashes, it retrieves the password hashes from the NTDS.DIT. DSsync requires a privileged account with domain replication rights.

Refer to this link: https://adsecurity.org/?p=1729


Are inactive vulnerable Wordpress plugins still unsafe? When you install a plugin in WordPress you can choose to activate or deactivate it.

Let's say you have a plugin of which the latest version is vulnerable to XSS for example and you're waiting for a security fix to be released. Should I disable or uninstall the plugin? What is recommended?

A plugin is just a bunch of PHP (and other) files and when it's installed, it's in a directory on the web server so if a function is called from the outside by an attacker, it will get executed no matter if the plugin is "active" or not. A mitigation from a WAF or some htaccess rules to deny access might be used to block access to the vulnerable files until they are updated to the new (safe) version.

It is better to uninstall the plugin and delete all the files, unless it's not possible to do so because it would alter the website too much and you don't want to give up to some functions.

Depends on the plugin, they can be if there is say a PHP script that can be called directly (doesn't depend on wordpress code or includes the right statements to load the wordpress libraries it needs).

You can effectively attempt to block direct access to the files via htaccess/server configuration but there are ways around that. Removing it entirely is better in general after all you can't run a file that doesn't exist.

Ultimately it depends on the vulnerability and the script it's in.


Tethered connection appears to be intercepted whilst at work Hi I have an iphone which I tether my laptop to via a personal hotspot.

This all works fine anywhere but at the office.  IN all other places I do not need to re-enter the hotspot password and the network is automatically joined when selected.

However, when operating at work I find that I am consistently being asked for the Wifi password during the same hotpost tethering process.

Can somebody explain how this could be happening, and what I can do to get around it?

Specific reasons for "why" this could be happening are numerous. Do you work in a tightly regulated facility? Could your employer have something to interfere with radio frequency emissions in the vicinity (intentional interference or not)?

The first thing to try is changing the wifi channel your hotspot uses, if the iPhone allows this.

Top things I would guess as the cause:

Your hotspot configuration overlaps or conflicts with another radio signal in the area.
An active countermeasure system is in place, overtly trying to disrupt the wireless signals it detects between your phone and laptop (not unheard of, but not very common in my humble experience).
A malicious actor is trying to man-in-the-middle (aka Evil Twin) attack your connection (more common, but not exactly something you encounter every day).


Person tried to login in my website with non-existent username, but not a VPN nor Tor I am managing a WordPress website.
I have installed the plugin "Limit Login Attempts Reloaded".
This plugin sent me an email saying that A.B.C.D has tried to login with the non-existent username "admin" 9 times and has been blocked.
Googling the IP address, it has been reported as being abusive (it tried to login to other WP websites before).
But I went to https://www.ipqualityscore.com/ and this website doesn't report the IP as a VPN exit node nor a Tor exit node (although classifying it as abusive with 89% probability).
How is it possible?
Is that the real IP address of the person that tried to login?

Not all sources of spam are proxies, VPNs, or Tor. Many are either hacked computers, or servers on networks that really don't care about abuse complaints. It's unlikely to be their personal home IP though, if that's what you mean, in the same way that a web server's IP is unlikely to be the home IP of the person who owns the website.


What is the difference between authenticity and non-repudiation? I'm new to infosec and doing some reading. Not surprisingly one starting point was wikipedia. In this article, authenticity and non-repudiation are listed as 2 separate 'Basic concepts'. My understanding is that you cannot achieve non-repudiation by not knowing which parties are involved, which requires authenticity to be in place. In that sense, I see authenticity as a sub component of non-repudiation.

Have you got examples backing up the approach that these 2 concepts are fundamentally separate?

Authenticity is about one party (say, Alice) interacting with another (Bob) to convince Bob that some data really comes from Alice.

Non-repudiation is about Alice showing to Bob a proof that some data really comes from Alice, such that not only Bob is convinced, but Bob also gets the assurance that he could show the same proof to Charlie, and Charlie would be convinced, too, even if Charlie does not trust Bob.

Therefore, a protocol which provides non-repudiation necessarily provides authenticity as a byproduct; in a way, authenticity is a sub-concept of non-repudiation. However, there are ways to provide authenticity (only) which are vastly more efficient than known methods to achieve signatures (authenticity can be obtained with a Message Authentication Code whereas non-repudiation requires a Digital Signature with much more involved mathematics). For this reason, it makes sense to use "authenticity" as a separate concept.

SSL/TLS is a tunneling protocol which provides authenticity (the client is sure to talk to the intended server) but not non-repudiation (the client cannot record the session and show it as proof, in case of a legal dispute with the server, because it would be easy to build a totally fake session record).


Are there any dangers in sharing ifconfig information publicly? If I were to share my ifconfig information from Linux publicly, is there any possible danger associated with this action?

There are at least 3 dangers:

Sharing your public IP addresses - it will surely result in several kinds of unauthorized security scanning (this applies, if your servers have public IP addresses).
Sharing your public IP addresses combined with possible OS version (ifconfig results on different OS-es look differently, you can compare ifconfig from modern Linux with ifconfig from BSD, or with typical Linux from eg. 2004). This is dangerous, if you are forced to use old software for some reason.
Sharing valid MAC addresses - a few years ago I read an investigation report about some fraud, which - apart of the most important facts - used changed MAC addresses on computers, where these MACs were changed to imitate valid MAC addresses gathered from competitive company's computers, just to mislead the investigation. I have completely no idea, how popular might be this kind of misleading activity, but I wouldn't publish my MAC addresses, just for sure.


Impersonating in a (W)LAN (Wasn't sure but this question might be better in Network Engineering)

Say I'm at a wireless access point that is password protected and I don't know the password. I do know that the people around me are connected to that access point. How does a router know what devices are and are not connected to the network? What stops me from impersonating one of the devices that is connected to the network and thus use the network access of the access point? Is this solely based on the MAC address of a device? If so, can't this be spoofed with ease?

You're limited by the fact that data is encrypted.
Nowadays the most used encryption algorithm is wpa2/wpa psk that has not critical flaws like the old wpa.


Mixing green (EV) ssl certificate with non EV certificate We have a green (EV) SSL certificate for our site and images are fetched from the same domain (https). Currently we are planning to change the images domain (for performance issues) and put them in a different domain with a different ssl certificate. In order to reduce costs we are thinking if acquiring a standard certificate (not EV) for this CDN content (for the images). In that case our page will have an EV certificate but images would be fetched from a non EV certificate.

Will this -mixing of EV and non EV certificates- remove our green status from the browser (like fetching content from http connection inside an https page)?

This should not affect the EV status displayed in the browser's address bar.  The EV status is based only on the certificate presented for the page itself.  (You will, of course, not have EV displayed if you have mixed content or invalid certificates presented, but using a cheaper cert on images.yourdomain.tld should not be a problem.)


How does a HTTP client authenticate itself with a HTTP server? Is it correct that there are various ways that a HTTP client can authenticate itself with a HTTP server?

Are the following such ways?

authorization header: for various authorization protocols (e.g. basic, digest, ...)
digital certificates: as used in HTTPS.
specify user name and passwords in HTTP request's message body, by applying HTTP POST method on form data

Are they used individually or together? Are they used for the same or different purposes? When is each way used?

In the second way, is digital certificates specified in some HTTP request header(s)? (In curl, it is specified via --cerf)

In the third way, when specify user name and passwords in HTTP request's message body, are they encrypted? Does the server know how to decrypt them?

Is it correct that there are various ways that a HTTP client can authenticate itself with a HTTP server?

Yes. There are many, many ways. Custom authentications schemes are common.

  Are the following such ways?

  authorization header: for various authorization protocols (e.g. basic, digest, ...)
  digital certificates: as used in HTTPS.
  specify user name and passwords in HTTP request's message body, by applying HTTP POST method on form data

Yes. Those are all ways authentication can happen. Although, nota bene, client certificate authentication usually involves the Authorization header with protocol = digest. Also sending username and password in a POST body is sloppy unless you're creating an account. It works, but it's sloppy. unusual unless the request is coming from an actual HTML form.

  Are they used individually or together? Are they used for the same or different purposes? When is each way used?

Only one authentication scheme is used at a time. Digest authentication is used when replay attacks are a real threat. Digest authentication involves a nonce such that the same MAC will not work twice. Basic authentication is more vulnerable to replay attacks but TLS encryption would need to be broken (or absent) to make this possible.

Client certificates are used when the server wants to check the veracity of the client's claimed identity using a trusted third party.

  In the second way, is digital certificates specified in some HTTP request header(s)? (In curl, it is specified via --cerf)

The client certificate itself would be specified in the body of an HTTP request. Client certificate authentication requires multiple requests and responses passed statefully.

  In the third way, when specify user name and passwords in HTTP request's message body, are they encrypted? Does the server know how to decrypt them?

They are encrypted if the request body itself is encrypted. This is the case in any https request. If you want details of the encryption and decryption system, read about TLS/SSL.


Would it be possible to create a zero knowledge social network? I understand the concept behind a zero knowledge web application where only the user has access to their data. What about a social network where some circles of user have access to that data?

Is it possible to have multiple public keys decrypt a "friends" information?

Whilst multiple public keys for a single private key is possible, it is not recommended.

In practice this sort of problem is solved by abstracting the private key exponent into a single symmetrical session key encrypted by as many multiple asymmetric key pairs as needed.

For instance, for a secure social network, each post you publish to the cloud is encrypted by a symmetrical session key which in turn is encrypted with public keys of everyone currently belonging to the social circle that you have posted the message to.

Revocation of friends from a circle is trivial, in that you don't encrypt the next session key with that person's public key.

Revocation of access to data that they have already seen is not trivial as data propagates freely across the internet once any authorised party has decrypted and disseminated it. Basic social networking common sense applies in this scenario.

We currently rely on a Netscape PKI design kludge from the early 90s for the world's internet security. So I wouldn't worry about whether key distribution uses classic PKI. For a client-server secure social network, the server could act as an OAuth/OpenID server with a public key cache.


Malicious RCE functions in CGI and Java I know there are some  functions in CGI and Java that can be abused to  perform remote code execution attack.

For example we can see abuse of "eval" function in Movable Type CMS:

sub core_drop_meta_for_table {my $self = shift;
  my (%param) = @_;
  my $class = $param{class};
  my $sql = $param{sql};eval "require $class;";            <-----------------------------
  my $driver = $class->dbi_driver;
  my $dbh = $driver->rw_handle;
  my $err;
  eval {
    $dbh->do($sql) or $err = $dbh->errstr;
  };
  # ignore drop errors; the column has probably been
  # removed already
  #if ($err) {
  #    print STDERR "$err: $sql\n";
  #}return 0;
}

I want to know if there are other functions that allow the attacker to execute arbitrary command in CGI and Java?

The direct equivalent in Java would been using class loaders or implementing an interpreter particularly if it allows arbitrary method calls through reflection. An IDE or other code viewer that allows tracing back method calls will show you APIs that indirectly use this (or use grep).

Oracle's Secure Coding Guidelines for Java SE has a list of examples in Guideline 3-8 / INJECT-8: Take care interpreting untrusted code.


"openssl crl" verify gives "Error getting CRL issuer certificate" File A - This is my CRL File - http://pastebin.com/yvstfPTD

File B - It's signed by this cert - http://pastebin.com/T1pXZSat

File C - The CRL signing cert has been issued by this CA http://pastebin.com/Q82PZCh1

File B & C are in directory dir1

When I issue command

openssl crl -in A -CApath dir1

I get the error

Error getting CRL issuer certificate

This is a vague error message.

How do I figure our what's the problem here?

All files are in PEM format

TLDR: IT'S THE WRONG CERT

The issuer name in that CRL is

$ openssl crl -in file0 -noout -issuer
issuer=/C=IN/O=Gujarat Narmada Valley Fertilizers Company Ltd./OU=Certifying Authority/postalCode=380054/ST=Gujarat/street=Bodakdev, S G Road, Ahmedabad/houseIdentifier=301, GNFC Infotower/CN=(n)Code Solutions CA 2011-1

The subject name in your purported signing cert is

$ openssl x509 -in file1 -noout -subject
subject= /C=IN/O=Gujarat Narmada Valley Fertilizers and Chemicals Limited/OU=Certifying Authority/postalCode=380054/ST=Gujarat/street=Bodakdev, S G Road, Ahmedabad/houseIdentifier=301, GNFC Infotower/CN=(n)Code Solutions CA 2014

These are not the same. The first one is 'Fertilizers Company Ltd.' while the second one is 'Fertilizers and Chemicals Limited' and the year (or year-like number) in CN is different.

In addition, if I ignore this mismatch and check manually, the RSA signature in the CRL does not 'decrypt' (more accurately, recover) to valid PKCS1-v1_5 padding using the key in the purported signing certificate. This means it was signed with a different keypair, which must have a different cert.


Sanitizing JavaScript to prevent XSS I'm going through a vulnerability remediation exercise for a client and am trying to figure out how to best mitigate this particular hole. There's a script on our site that calls up content into a new window using <%= %>. Essentially this takes a hard-coded link in an include file looking something like

link

and displays it on the resulting page within html using a script looking something like:

<img src="<% =request.querystring("x") %>">

This script is in hundreds of includes, so I'm trying to figure out the most efficient way of mitigating it. Should I use a find and replace to remove the script from the include files or is there a way to sanitize the actual script using something other than <%= %>?

The whole thing is legacy, super clunky and needs to be replaced anyway, but like I said, we're talking about hundreds of files here, and not all follow the same syntax so I can't run a batch find and replace for all of them. It'll have to be in small batches and I'll still have to go into each one to check if something broke. Kill me now.

I'm a designer/front-end dev, not a security expert (and not a JavaScript whiz either), so any help here would be much appreciated.

A simple way would be to create a white-list of characters, such as alphanumerical and forward slashes - and making sure the file exist on your local filesystem.  You want to avoid having:  and such.

For this, I'd recommend making a function say sanitize() which filters out unwanted characters, and wrap each of these with it

<img src="<% =sanitize(request.querystring("x")) >">

Depending on your framework being used (ASP, Ruby, ...) maybe you could monkey patch the code, so that request.querystring() always returns a sanitized version.


How to stop a request for an external image from exposing my IP to the server hosting the image? Suppose I have a server A, and that there is a website W hosted on A. The HTML of W contains:

<img src=https://www.domainD.com/testT.jpg>

Then I have a computer C, that accesses W.

Will computer C directly ask domainD for testT.jpg?
Or will it ask A for testT.jpg, and then A asks domainD for testT.jpg and send the data back to C?

From the test result, it's the former case.

If C directly asks for testT.jpg from the server, the server will easily know the IP of C. How can I prevent that?

HTTP is Hyper Text Transfer Protocol. Hyper text stands for the ability to aggregate informations from different sources. If you advertise an URL in a web page, the browser will use that URL to fetch the information piece. This is inherent to the protocol. Full stop here.

But, you can advertive a local URL for a distant resource. That is called reverse proxying. Any good http server should have options for that. In Apache, mod_proxy contains all you could need with the ProxyPass directive:

You can then use:

<img src=/domainD/testT.jpg>

and in Apache config:

<Location "/domainD/">
    ProxyPass "https://www.domainD.com/"
</Location>

Here, the browser will send the request to your own server, because it only sees your local URL, and that server will send a request for the actual resource and send it back to the client browser, hiding the original client IP.


Are ciphers with a strength of 112 bits considered weak? SSL/TLS Ciphers of strength 128 bit is considered strong while ciphers of strength 112 bits is considered weak.

Ciphers of 56 bit is understandably weak as they can be easily brute-forced.

If it is weak, on what grounds is it considered weak and the reasonable time to brute-force it.

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


How to exploit system call when the full path of binary is given inside the call? I was working on a challenge where I have to exploit a C program to gain elevated privileges in a linux system. To complete it I have to call a program /bin/test while the vulnerable program is running with elevated privilege level. The relevant code snippet is given below.

I was able to exploit another program which used system("cat <some file>") without a problem. In that case I created a C program with which executed /bin/test , named it cat and kept it in a directory which I later added to the $PATH variable.

However in this case I am unable to follow the above approach for two different reasons.

I am unable to locate the binary for export command.
I am unable to create a $PATH variable which will call my custom file command as the full path is being called in the system() of the program to be exploited.
Also note that the program sanitizes semicolon and a couple of special characters which makes it difficult to append multiple commands in the system call.

I have compiled the program and I can execute the "id" command by providing

`id`

as arg on stdin. Looks like they missed the backtick as forbidden character. Maybe you can create a sh script that creates a root user...


Average user reaction to SSL certificate error pages With the attack on Twitter's whois information today, I got into a bit of an argument about whether or not the SSL certificate error messages that web browsers have will actually do any good to prevent an attack, assuming that the attackers can't manage to get a valid certificate somehow.

The average error page or error message says something along the lines of "There's a problem with this site's security certificate, and this may mean an attempt to intercept the data you're sending to the server." Admittedly, this is a bit wordy, but I believe it's short enough to keep a user's attention and has enough detail (without going into too much detail) to let the user know that it's not just a "You win a free car and $1,000,000!!!!" sort of thing. There's also that typically the error pages are intrusive and minimally flashy, which I believe will catch the user's attention but not divert it away.

Since this is a fairly subjective question, I'm going to make it as objective as possible: In your experience, what is the average user's reaction to warning pages like this?

I would add this as a comment if I had the rep but the typical user reaction would be to click through. Your average user has no clue about SSL. As a side note, at my place of employment, our ERP throws an error message due to an unverfiable certificate. The solution to this problem (according to the help desk) is to click through it.  I assume most users would take the same course of action on their home computer.


HTTPS support for LAN based hub device I'm working on a product that would connect to a LAN and provide a web server for user/application control, think something like a Hue or Sonos hub.  I would like for the web server to be HTTPS only, but that doesn't seem totally feasible as the device won't have a "hostname" and will just that can be validated in the HTTPS requests, it will just obtain an IP address via DHCP.

Is there anyway to create a valid TLS connection or will I always have to disable verification to make a connection?

** Edit**

I have tried using a self-signed certificate on the hub, but requests still fail with

http --verify ./testca.crt https://localhost:1338
http: error: SSLError: hostname '192.168.1.100' doesn't match u'Test-Hub'

Generate a self signed certificate and install it on all devices you want using this service.

If you disable verification then there is no reason to have it be over HTTPS in the first place.


Why don't banks get hacked? From reading a lot of info on this website I came to the conclusion that if someone with enough skill really badly wants to gain access somewhere, then there is absolutely nothing stopping them from doing so. Additionally I learned that getting access to a company computer is much easier than a singular computer at home.

However I am completely confused. What exactly prevents someone from for example, stalking one(or more) of the bank employees, getting information on them and then gaining access into their system? As far as I have seen financial fields have one of the most soul sucking programming tasks which usually end up in small amount of security holes. So what would prevent someone from waltzing into the bank's system, causing gigantic chaos (not for sake of stealing money, but for sake of screwing them up), and then walk out.

For example I know from internal sources that this has one of the worst security methods implemented. This makes me assume that this is not the first software that a bank would release that would allow data to be stolen and/or modified.

Does this actually happen but the banks do not care because they suffer very small damages? Or is a bank completely impossible to get into and destroy data?

I think it's fair to say that the idea that any large organisation is entirely impervious to attack has been proven false over the last five years or so.  Everyone from nation states through large corporations, security consultancies and other security minded companies have had breaches.

One reason that a bank hasn't been thrown into "complete chaos" as you put it is likely down to a combination of the security measures they have in place to react to attacks, the size and complexity of their systems and the motivations of people who have the resources to effectively attack them.

If you think about people who are most motivated to attack banking systems, it's criminals who want to steal money from them.  From their perspective there's no reason to cause chaos, they want to get in, steal things and get away without being noticed, if possible.


Does `ssh-keyscan` verify the legitimacy of the host(s) it scans? There are tutorials on the web, such as this one: https://blog.oddbit.com/post/2019-02-24-docker-build-learns-about-secr/

They show you sample code to run ssh-keyscan in an automated manner so that subsequent automation steps that depend on SSH can complete successfully. E.g. excerpt from that tutorial:

# syntax=docker/dockerfile:1.0.0-experimental

FROM alpine
RUN apk add --update git openssh

# This is necessary to prevent the "git clone" operation from failing
# with an "unknown host key" error.
RUN mkdir -m 700 /root/.ssh; \
  touch -m 600 /root/.ssh/known_hosts; \
  ssh-keyscan github.com > /root/.ssh/known_hosts

# This command will have access to the forwarded agent (if one is
# available)
RUN --mount=type=ssh git clone git@github.com:moby/buildkit

Is that a good idea? Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans? If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification?

Is there any way for ssh-keyscan to automatically verify the legitimacy of the host it scans?

No. How could it? You are using it to build the known_hosts file that would be used for verification.

  If not, doesn't it become security theatre and defeats the point of SSH's known_hosts verification?

In the example you've shown, it indeed does.

Although the problem isn't that ssh-keyscan is being used, but rather when and how it is used. Overall, it isn't any different from getting the regular "Verify unknown host" SSH prompt and blindly typing yes without looking at the fingerprint.

If you do it once and keep the resulting known_hosts file around, then you still get the same Trust-on-first-use behavior that we all expect from SSH. But if you throw away and regenerate known_hosts every time, with no verification against previous runs, then it's going to be a problem whether you use ssh-keyscan or not.

In short, deploying a static known_hosts file would be much more secure – GitHub's SSH hostkeys certainly don't change often, so there is really no need to re-keyscan them every time.


How to encrypt a >1MB file with RSA? I am new to cryptography, so please excuse any "obvious" beginner mistakes.

I need to send a file larger than one MB to Bob, but my RSA keys are only 1024 bit large. I believe this means I can't use it to encrypt the data.

I know the public key of Bob. Can I create a certificate with his public key, so that Bob can then decrypt the data using his private key?

Or am I on the completely wrong track?

In theory, this can be done with an additional layer of encryption:

Generate a key of appropriate length
Encrypt the message (file) with a symmetric-key algorithm using this key
Encrypt this key with an asymmetric-key encryption using Bob's public key

If you then send the encrypted file and encrypted key to Bob, he will be able to decrypt the key and then the file using this key.

This approach is implemented in most cryptography software. From the user's point of view, you choose the file and the key of the recipient, and get the encrypted file which usually contains metadata (e.g. public key hash), so the recipient (or any other  person) may check whether he has the correct private key without actually decrypting the data.

This scheme combines the obvious benefits of public-key cryptography with the speed of symmetric-key encryption (asymmetric encryption is considerably slower).

As A. Hersean pointed out, you should not implement this scheme from scratch (unless this is your homework assignment, or you are just curious), but rely on widely-used packages like GnuPG. This software often includes GUI, so it can be used by a beginner.


Automated tools to manage or monitor authorized_keys? In short

Are there any tools that can be used to work with authorized_keys to scan the keys and maintain a database of which servers have which keys?

More context

I'm a big fan of public key authentication for ssh, but one aspect that worries me a bit is disabling keys that are compromised. I've been putting my laptop public key on all the servers I interact with. I've been doing this for years. I've long since lost track of all the servers I've put the key on.

In the event that my laptop is stolen, proper procedure would be to remove that public key from everywhere I've added it. But, like I said, I can't remember where that is.

I'm wondering if there are any automated tools that help with this, like something that maintains a database of where your key is, and helps you to remove it in the case where a key is lost.

Pie-in-the-sky would be a daemon that runs on each server and periodically checks with a remote database. If it finds any keys have been flagged, it immediately removes them from all authorized_keys files that it monitors. However, with a daemon editing authorized_keys, I'm sure there are all kinds of ways that could be exploited, so even a step down where it just somehow notifies you, saying "Hey, I've got a compromised key here..." would be better.

While I do not want to promote commercial software, I know ssh.com is selling a software called "Universal SSH Key manager" that can discover, monitor, remidiate and manage SSH keys throughout an enterprise.

They describe their product with the following quote:

  Your enterprise may have more Secure Shell identities than employees.
  A lot more. Gain visibility and control over who has access to what
  and when, with the only comprehensive identity and access management
  solution for Secure Shell.

I have not tried their software, and are not affiliated with them.
It would be interesting to see if anyone can recommend open tools that do more or less the same task.


What are the security concerns when connecting to a WiFi network? I connected my phone to a protected Wifi network that is not my own. Can anyone accessing the same network be considered a threat on my mobile device? Is it easier for hackers connected to the same Wifi network to access my mobile data?  If so, how can I protect my device?

Unlike other questions I have read on this website, the network is secured but more than one person have access to it and i'm not only concerned about emails but all data found on my device in general

People on the same network can read your unencrypted web traffic. They probably won't be able to access your phone data unless you have apps that open up your phone to that (FTP/SSH apps, for example)

If you want to protect the data you send over the web, only use visit SSL (HTTPS) pages while on this network.


How secure is the windows Cipher command? So in windows CMD, there is the Cipher.exe Command Line tool. Supposedly it will allow you to fully overwrite empty disk space with 0x00 and 0xFF. (with the /w parameter)

There is some further information here which I could find about the usage of the command.

From my understanding this should mean that any data deleted should be unrecoverable.

I could not find too much information on to what extent is this true and can it be relied on to securely delete data permanently?

Securely deleting data, otherwise known as “wiping” can be surprisingly difficult.
Overwriting data even once with “cipher.exe”, or any other tool, makes the data effectively gone. The old bugaboos about multiple pass wipes being necessary to thwart magnetic force microscope recovery of partial track wipes is urban legend. It was theoretically possible back in the days (20 years ago) preceding IDE disk drives with storage capacities measured in MEGAbytes. Even then it was a laboratory curiosity never successfully demonstrated at scales beyond a few bytes. A one pass write of anything; zeroes, random, pattern,  whatever, securely wipes the data. Yes, “cipher.exe” and others offer multiple pass wiping, but this is a marketing holdover because so many people still believe it’s necessary. It’s not and it’s a waste of time, but feel free to multipass if you like.
But I said it can be difficult, then described something simple?
The hard part is actually overwriting the data, because the data is often not as static as it seems.
Tools like “cipher.exe” overwrite unallocated disk space, commonly referred to as deleted. For the most part, this works as you would think.
So where does this fail?
Slack Space (smallish risk)
File storage is allocated in blocks. Any file that does not use an exact multiple of blocks will have filler making up the difference. Typically this is fragments of whatever file last used this disk block. Realistically, this is a relatively low risk of useful content. On solid state drives with properly functioning TRIM, slack space should be empty.
Bad Tracks/Sectors (small risk)
Tracks that have been remapped due to failures may contain chunks of data that will not be touched by overwrite attempts. Generally these are genuinely bad and data is not retrievable, or even if retrieved contains system fragments not associated with anything important. Yes bad tracks can be artificially created, but if you did that you’d know you did it, it’s not accidental.
Wear Leveling (insignificant risk)
Solid state drives attempt to reduce wear by switching out memory chunks internally. When this happens, old data cannot be reached to overwrite it. Again, these are tiny chunks and accessing the chunks requires “Chip-Off”, removing the memory chips and controllers in order to bypass the wear leveling control. Even if this is done, good luck getting anything useful from it.
Databases and MFT (significant risk)
Databases delete entries by marking the space as available to be reused, however this is not unallocated to the system because it’s still part of the allocated database file. It will not be overwritten by “cipher.exe”. The Windows Master File Table works in an analogous manner. It’s main function is to hold file attributes and point to the disk location(s) actually containing the file data. However if a file is small enough (approaching up to 981 bytes), the actual file data may be stored directly in the MFT. Deleting this file marks the entry as available to the MFT, but the MFT as a whole is still allocated so will not be touched by “cipher.exe”.
Shadow Volumes (big risk)
Microsoft supports the ability to perform recovery “rollbacks”. It accomplishes this feat of magic with the Volume Shadow Service (VSS). In essence, Windows maintains prior version copies of files that have changed. Not just a single previous version, but potentially many previous versions. These previous version files are easily recoverable even if the current version has been successfully wiped. “cipher.exe” will not touch shadow volumes.


Odd Proxy setting in Microsoft Edge Today I encountered odd proxy settings on a user's Windows 10 installation.

Microsoft Edge had the proxy set to:

  use proxyserver

The address field was set to:

  ...os=127.0.0.1:51144

The "port" field was empty.

The "no proxy for" field was set to:

  <-loopback>

I was not able to change the proxy settings.

Is this a trojan of some kind?

Click on the start icon.
Click settings.
Select Network & Internet.
Select Ethernet on the left panel, and click Internet options.
When the Internet Properties window opens, click the Connections
tab.
At the bottom of this window, click LAN settings.
In the Local Area Network (LAN) Settings window, make sure the Use
automatic configuration script and Use a proxy server for your LAN
boxes are not checked, and then click OK.
If any settings were changed, click Apply and then OK.
Confirm the connection by testing two separate web pages.


How does a trojan like Trojan:JS/BlacoleRef.BV infect a website? Today I find out my website is infected with Trojan:JS/BlacoleRef.BV. The server is a shared server from a hosting company.

How does a trojan like this get on the webserver?

In your case it is likely the recent Plesk credentials leakage vulnerability, which has been mass-exploited to install Blackhole.

Plesk is always the first of the unwanted packages I uninstall on a new server. Trust my administration to a sack of random PHP? Don't think so...


Purpose of using API Key in addition to password It was suggested to my coworker and me to password protect our API in addition to requiring an API key. This doesn't seem like it's making anything safer since if the threat gained access to our API key, presumably they also gained access to the password.

Is this standard practice to secure with both an API key and password? I've searched around but haven't seen anything suggesting to do so.

The point of an API key is to authenticate (or at least identify) the application, and not the user. Something called an “API key” does not normally determine what data a request is allowed to access, but how many requests can be made in a certain time interval through a given user account. It's a way to impose access quotas, to avoid denial of service, without completely blocking a user just because they've used a buggy app or have used it a little more than you'd like.

If your API serves public data then there's no reason to have a password in addition to the API key. The API key is the password, in this case.


OpenVPN configuration and ISP's DNS I have configured OpenVPN server for using Clouflare DNS - 1.1.1.1. I use OpenVPN connection in the next way: sudo openvpn --config Config.ovpn on my local machine in WiFi network.

My ISP provider blocks some sites, for instance mail.ru with default these configuration configuration I'm not able to establish connection to the blocked site, while my IP address corresponds to the address of OpenVPN server. I found out that I have the next DNS configuration:

nmcli device show wlo1  | grep IP4.DNS:

IP4.DNS[1]:                             192.168.0.1
IP4.DNS[2]:                             1.1.1.1

After I got rid of the first record I was able to establish connection to the blocked site.

I suggest that 192.168.0.1 was DNS of my ISP and accordingly it was blocked and removing of it solved the issue.

I have two questions:

Does this situation correspond to case of using OpenVPN with kind of poisoned DNS?
Even if I used OpenVPN connection but with DNS of my ISP, could ISP track my network traffic?

This doesn't have anything to do with DNS poisoning, it's most likely just an error in the configuration of your embedded device (presumably an Internet-facing router).

However, it might just behave like DNS poisoning, heavily impacting the privacy of your activity on the Internet.

As a matter of fact, if you're using whatever VPN connection you may set up but with your stub resolver going into your provider's network (which you'll always still have there on your network interface), the provider would be able to record all your DNS requests at will and stream them to any third party they would like to.

Moreover, your provider would be able to provide you with false DNS responses. For HTTPS requests, that's usually not a real issue if you're aware of basic TLS/PKIX concepts (like, not blindly accepting self-signed certificates or certificates with issues), but it might be a problem for the rest of your actions, e.g. HTTP, e-mail, applications not following best practices, etc.

Actually, modern browsers have started to implement DoH which never leaks your in-browser DNS queries to whatever is configured as a recursive resolver on your network, and if you care about your privacy, you may want to choose one of those. But the rest of applications are still exposed to the risk outlined above.


Selling used ram [DDr3 SODIMM]. Need to erase? Does DDr3 SODIMM memory hold information after being removed?  I would like to sell the memory I just removed from my computer, however I wasn't sure if I had to wipe/erase it first some how.  Please advise.  Thank you.

Most people will tell you that the RAM is erased as soon as you remove it from you pc. That is not a 100% true. The data fades away bit by bit in around a minute. The exact time depends on the ram module. To answer your question directly: You can just sell it without any worries.

Just a sidenote: The time the RAM needs to be flushed can be enhenced by cooling the RAM down rapidly using ice spray for example. This is done to extract encryption keys from the RAM for example. Its caled a cold boot attack.


Is there any advantage on using OTR in a messaging app if the messages are first sent to a REST API server over HTTPS? I don't have any kind of experience in security, but just on API and app development, and I'm developing an application for doctors and patients which has an added private messaging feature between doctor:patient.

I also should be able to retrieve messages exchanged in case of legal issues between doctor:patient, basically a man-in-the-middle.

I invested the day studying XMPP, OTR, etc and I decided I'll use a simple POST REST endpoint to post messages, using sockets, instead of XMPP, et. all.

I read that even consumer chatting apps use OTR for end-to-end encryption, but isn't HTTPS enough? I understand the concept of end-to-end encryption, but both doctor and patient will be connected via HTTPS to the server, isn't that enough? Isn't that already a kind of end-to-end encryption?

So is there any benefit on using HTTPS AND OTR?

Is there another secure but easier to implement option and/or technique other than OTR? (compatible with iOS, Android, Windows Phone, Web).

EDIT: OTR has "Deniability: After the chat session is finished, messages cannot be identified as originating from either your correspondent or you." - but in this case the messages have to be identified, specially for liability issues on face of the doctor decisions/instructions/etc.

OTR messages are encrypted end-to-end. This means that the clear-text of OTR messages cannot be accessed by an intermediary such as a server. This is useful to prevent messaging companies, governments, and any other MiTM from snooping on your conversation.

If you are looking to implement your own messaging system using a REST API that records the data that is being messaged, OTR is not what you want as the server will not be able to access the clear-text of the messages for logging. HTTPS will provide you with sufficient on-the-wire security.


Device authentication, common method What are some standard device authentication methods, in a scenario when:

The desktop computer is being authenticated on web service
I provide the .exe on the desktop
I control the web service
The desktop has a TPM chip installed

Should I get the device ID from the desktop, then somehow sign it with TPM and send it to web service? What is the standard method?

Trying to answer my question, reviews are welcome.

On https connection :

Alice requests random number from Bob in publicly accessible web service
Alice signs random number with her private key within TPM 2.0
Alice sends signed random number to Bob
Bob verifies that Alice signed random number


Security of Chrome's Printing Output On Linux systems the printing functionality of Chrome (printing of websites or PDF documents) generates PDF documents which are sent to the print server (e.g., CUPS). Are there any security mechanisms built into Chrome which ensure that these PDF files do not contain any potentially harmful content like JavaScript?

As I'm aware Google Chrome just provides "security" when you download a file.

So answering your question, unless you actually download the file I don't think that Google will check for virus in that specific file.

But Google does offer security in a way that prevents scripts that can send information to the server, so it may just do that.


Verify CDN javascript's integrity CDNs speed up the loading of websites by allowing caching for frequently used javascript libraries like jquery. How do we know if they have modified the javascript before serving it to my clients?

E.g. I have compared the hash of jquery.js and verified that it matches the hash on the official website. I then insert the link on my webpage. 2 week later, the CDN replaces it with a malicious copy with a keylogger embedded. When a client visits my webpage, the malicious script is downloaded and logs all input and posts it to their server.

Can I use a library like Crypto.JS to verify the md5 checksum of a script before executing it? This has to be done in javascript since the exploit works on the client side.

This is what you are looking for - Subresource Integrity:

http://w3c.github.io/webappsec/specs/subresourceintegrity/

Summary: http://qnimate.com/how-to-make-browsers-verify-fetched-resources-content/

Subresource integrity is only supported by the latest browsers.


How to detect "forged" SSL certificates from the webserver end The company I work for sometimes intercepts employees ssl connections to https websites by making the ssl connection on their behalf from a proxy, and then using the own generated certificate to send the page to the user. Obviously this only works because they installed their own root certificate on the employees PCs but you can tell when you go to a https website and look at the certificate and find that it's signed by [company] and not by one of the usual CAs/

Now I don't intend to get into the morality or legality of this practice here even though I have opinions on it :P

My question is, is there any way to detect that this is happening from the webserver and refuse to deliver the page if it's being intercepted like this?

I was thinking that maybe some javscript on the webpage could find out which certificate the page was signed with and issue a warning if it was wrong - but there doesn't seem to be any way I can find to check the certificate from javascript. (I realise that if the company could modify the certificate they could modify the javascript too, but I'm assuming they wouldn't write custom code for each website)...

Is there any other trick I can use to do this?

The only way I can see is to open a XMLHTTPRequest over SSL and pull the certificate out of that connection:

MDN: How to check the security state of an XMLHTTPRequest over SSL
(archive)

This doesn't work from a web-page, but is required to be run from an extension.

As already pointed out the proxy can easily change the javascript to kill this.


How dangerous is it to allow local connections to remote selenium servers? There are services like BrowserStack or Sauce Labs that help with testing and test automation on different browsers and devices.

But, in order to solve the problem of an application under test being behind the VPN or firewall, they implement and offer this idea of "local testing":

  Local Testing establishes a secure connection between your machine and BrowserStack servers. Once you set up Local Testing, all URLs work out of the box, including those with HTTPS, multiple domains, as well as those behind a proxy or firewall, and much more.

What risks are we taking allowing the remote selenium server on BrowserStack access to the internal resources? How secure is this setup and is there anything we can do to improve security?

You are essentially allowing an external third party to access any resource reachable via HTTP from your computer. This includes resources on your local machine and inside your local network. The dangers of this should be obvious: if any sensitive information can be reached via HTTP(S) from your system it could be stolen by this third party.

And note that even data which are not accessible by HTTP might get stolen: if you don't use the Chrome extension but the provided binary you are executing third party code on your system with the same permissions as yourself. This code has thus access also to local files, mounted network volumes etc.

In other words: if you don't fully trust this service don't use it. Alternatively use it only within an environment which contains no data worth stealing and where no such data are reachable from inside the environment.


Is it safe/wise to store a salt in the same field as the hashed password? In using Argon2 for hashing passwords in my application, I've noticed it generates a string like this (e.g. for password "rabbit"):

$argon2i$v=19$m=65536,t=3,p=1$YOtX2//7NoD/owm8RZ8llw==$fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

My understanding is that everything prior to p= are parameters, the body of the p= is the salt, and the last part is the hashed password.

Is it acceptable to store this in one field in a SQL database (varchar(99) in this case), or should the string be separated into its constituent parts? Should I store the salt separately from the hashed password and keep the parameters in code?

You should store it in a single field. Do not try to divide it into parts.

I know this might seem a bit unintuitive for people coming from a database background, where the modus operandi is to normalize data and using serialized strings is considered an ugly hack. But from a security practice, this makes perfect sense.

Why? Because the smallest unit the individual developer needs to operate on is that full string. That is what the app needs to pass to the hash library to check if a provided password is correct or not. From the developers perspective, the hash library can be a black box, and she need not concern herself with what those pesky parts actually mean.

This is a good thing, because most developers are imperfect humans (I know, because I am one myself). If you let them pick that string apart and then try to fit it all together again they will probably mess things up, like give all users the same salt or no salt at all.

Only storing the parameters in the code is also a bad idea. As processors gets faster, you may want to increase the cost factor in the future. During the migration phase, different passwords will have different cost factors. So you will need information on the password level about what cost factor was used to hash it.


Forcing new password with zero-knowledge proof authentications Let's say a ZKP (e.g. SRP6a) is used, for password verification.

Let's say I need to force a user to change their password (so I have the salt and the verifier for the current password). For this, the client will need to send me the new salt and verifier values. But I can't check if the password used was the same if the salt is random.

The reason I bother is because an initial password may be delivered over a less secure way, and I don't want that password to linger.

The only way to ensure the passwords to be different that I found is to require the new salt to be the same as old.

The mechanism to change the password is exposed as an API to the client, and I can't necessarily trust the client to do that verification.

The questions are:

Is there a better way?
If no, then is there any downside to requiring the same salt, i.e. am I compromising anything?

First of all, note that if the server generated the first insecure password, than it is easy for him to check whether the client switched password or not. Because the only secret value in this scheme is the password itself. Hence the server can try to generate the v variable and simply check if they are identical. So your original problem is solved that way.

As far as I understand, the idea behind the salt in this scheme is exactly to prevent from an adversary to figure out when the same password is used.
It seems to me (haven't checked it through, but with a quick glance) that the scheme will be secure enough if you will fix a random salt for each client. It seems that the only advantage in this case is that the server can detect password reuses.


I want to have the security of my crypto code checked, how should I go about doing so? Specifically part of my system stores encrypted information in a database. I wrote the code that actually does the encrypting/decrypting using an existing cipher.

How should I go about making sure that the system I designed is secure?

The only option I know of is hiring a security consultant or company to audit my security protocol. Any information concerning this option is appreciated, as well as other options.

You can

have your code audited
have your design audited
perform blackbox checks against your web service

see: http://en.wikipedia.org/wiki/Security_testing

An audit should be performed by a person that was not involved in the creation of your service and infrastructure. That may be another team or department of your company – or some external consultancy.

And: use tested techniques & components in your design, which means: do not re-invent the wheel (c.f. http://en.wikipedia.org/wiki/Not_invented_here)