Tag Info

Hot answers tagged

17

It is a bit of a fetish. As far as we currently know, there is no reason to believe that using the first four bytes of the HMAC output would not be equally secure. However, lack of reason to believe does not imply that nobody believes. Some people "feel" that systematic truncation may help the attacker in some completely unspecified way. With a lot of ...


12

Looks like the certificate is only valid for opensource.apple.com, not www.opensource.apple.com: www.opensource.apple.com uses an invalid security certificate. The certificate is only valid for opensource.apple.com (Error code: ssl_error_bad_cert_domain) You can simply use the former.


7

It's a rather short list: ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ Now that's the fixed and static list. But: contact info from WHOIS is also legal. From the CAB-Forums' Baseline requirements, page 17: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL ...


6

There are a few benefits that persist in 2FA: A keylogger can't make use of my 2FA passwords for later. I can't share my 2FA with somebody on an ongoing basis. I'm more likely to know my 2FA credentials are compromised (e.g., because my token is missing) than somebody simply copying my sticky note hidden in my wallet. Somebody who phishes you will be have ...


6

There are several differences. First, by setting up your API server to accept username/password (as opposed to only allowing access via keys, which is increasingly a best practice to do) you potentially decrease its security in general, as, now, users with weak passwords on the system (or, worse, services that you install which may have hardcoded default ...


5

"Back in the day" we didn't really have any standards prior to oauth, everything was hand rolled and custom. (so for example the photobucket API provided its own direct authentication mechanism. ) Usually token based authentication with a API key (or even plain credentials. ) Back then the majority of online services were 'islands' of their own and didnt ...


5

There are several techniques that are still being used beside OAuth. API keys/Service keys Whitelisting IP's User/Password Login Token Login (non OAuth)... eg. custom implementation. none, just a 'secret' web-endpoint. and often a combination of them. What you saw often was a combination of whitelisting and one of the other techniques. OAuth was ...


3

This way, if one of your applications gets hacked, you theoretically don't lose any login credentials. But is that all there is to it? No, an additional benefit (or possibly the main benefit) is that a resource owner can give temporary access to a subset of their resources to a client without giving away their credentials. From the document you ...


3

Computing entropy for a randomly chosen password can be broken down to a simple rule that can be used in virtually all cases, with some caveats. It's the log2() of the password character set space raised to the power of the password length. So, with a completely random password where all characters are independent, this is an easy calculation. E.G., For a ...


3

Edit: I realise that this may not be clear from the answer below... but from the point of view of your application, it doesn't really make any difference whether you run the PKI/CA yourself or whether you use one or more third-party CAs. Even if you choose to run your own PKI, you really don't want to code it yourself - so you'd use one of the existing ones, ...


3

A JWT token consists of a base64 encoded string containing header, claims and signature. The claims section contains a JSON encoded expiration field, exp: Expiration time. It contains the UTC Unix time after which you should no longer accept this token. It should be after the issued-at time. The username can also be stored in the claims object. ...


2

Encrypting the very first message sent from the client with the secret key would present significant issues for the Authentication Server. If this initial request were encrypted, the Authentication Server would not be able to determine which user made the request and therefore which secret key is needed to decrypt the same request. This cleartext ...


2

The registrar verifies the identity of the user (in a comment you said that the user is not anonymous towards the registrar). Identification means that each user has some kind of unique identifier. That could be their social security number, their real name + birthday + birthplace or something like that. The registrar uses a cryptographically secure hash ...


2

No, this does not put all your eggs in the same basket, it takes some of the eggs out of the security basket and puts them in your resource basket. Using more common security terminology, you are "reducing your attack surface". The idea is that every bit of code you are running has potential vulnerabilities in it. (Obviously, we'd all like to deploy only ...


2

There is no right or wrong answer. If you implement a more aggressive lockout policy then you will be more secure and you will degrade your user experience. You have to assess where the right balance is for yourself, based on your application's requirements, your knowledge of your user base, the value of the assets you are protecting, your threat model, ...


2

Yes its neccessary. A token can still be requested by a bruteforcer. Yes, it would cost the bruteforcer one request extra per try, but a captcha still blocks attempts completely instead. If you dont want to bother your users with a captcha, you could set so when a incorrect password is used, the account in question will require a captcha. This both thwarth ...


2

Assuming AES is being used in any mode other than ECB, the IV is used in the AES encryption (the actual encryption is E_{Ks,IV}(F), not just E_{Ks}(F)). Every mode of operation for AES that I'm aware of except for ECB mode requires an initialization vector, that is used for different things depending on the mode (in CTR it's used to produce the keystream; in ...


2

The credentials may be shared for the whole network (eg. LDAP credentials), allowing access to the local computer, mail, remote access… Also note that Phishing OS credentials is very different than phishing a website. You don't go back to a computer and fill an Email prompt without even logging in (actually, I don't think many company users enter their ...


2

The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the ...


2

I work for a penetration testing company that requires a client certificate to log into any of our testing hosts. The certificates do require you enter a pass phrase when authenticating. This is done as an added layer of security, not to replace the need for passwords. If the certificate does not require a pass phrase, then yes - letting someone get a ...


2

Password reset mechanisms typically work like this: The server generates a secret random string (e. g. 16 bytes read from /dev/urandom). Then the server sends this string to the user, often embedded within a link to a password reset page. A hash of the string is stored in the database for later validation. Usually, the string is only valid within a certain ...


2

Well in answer to your question as to whether there's a better way to do this, I'm wondering if a slightly simpler solution which I've used previously might be up to the task. Rather than generating a pre-defined list of challenges and transmitting them, have the client and server each add a predictable incremental value to the hash you pass in the header. ...


2

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password (passwd -de). That way users get prompted on their first login and can choose their own passwords. I ...


2

The difference between the two keys is that the Master key (PMK) is supposed to be valid for at least as long as the client is connected. In the case of WPA-PSK, the PMK is the same from the moment the AP is configured until either the passphrase or the SSID changes. Therefore, if the PMK is compromised in any way, the attacker gains "permanent" access to ...


2

A few items to consider: Cookies can be stored on disk or in memory. How they are stored is dependent on browser settings (.e.g Private Browsing mode in Firefox) and server settings (see PHP docs on session handling). HTTP connections can be cached using the Keep-Alive header. It looks like you are set up to store session ids on the server in a file, but ...


1

Generally, the very nature of PKI (and some good system maintenance) should prevent this from being a security risk. But personally, I'm not sure I'd really want just any website to be able to enumerate my Trusted Root CA list. This sounds like a good way to phish out systems vulnerable to attacks using stuff like DigiNotar certs or certificates from other ...


1

No, the web server cannot check to see all the CA's the client has installed. If you have access to the client machine, you can check by viewing the Trusted Root Certification Authorities store.


1

Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop. Yes, true, if someone gains full access to your machine, you are in trouble either way. Am I missing something here? Yes. ...


1

Well, if you drop the idea for username/password (that is not secure at all for this use) you could implement a chrooted environment for the ssh-client to connect into. using ECDSA or RSA Public key encryption, (you ship the private key with the app, and store the authorized keys outside of the chroot). Especially if you make a "dropbox" for the clients to ...


1

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings. In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started. You have to assume your clients are stupid, ...



Only top voted, non community-wiki answers of a minimum length are eligible