Tag Info

New answers tagged

-5

I have never seen more useless answers to a technical question anywhere. Who the fuck do you people think you are going off on him about what he is doing it for, or why.


2

As always, the choice of the authentication scheme mainly depends on what you need to protect and the kind of public you will receive. As "I forgot my password" link mentioned in the comments is a good example. By the past, for certain non-important websites, I used such links on a systematic basis to open a session: Click on the "I forgot my password" ...


1

You don't know. You technically don't even know whether the password is stored at all, let alone whether it's stored hashed. Them being able to email you the password immediately after you tell it to them says nothing of storage.


2

Create a private key with corresponding verifier for server. Rather than use a hash of a salt and password as in typical SRP, just use a random number (mod N) and not zero for the key value. In SRP implementations, the key is typically called "x", and then the verifier is g^x (mod N). SRP with a key of 0 is simply Diffie-Hellman. Now do an SRP login with ...


1

Snake oil, this is just a glorified Linux live-USB with lots of bold claims to fool naive customers (they advertise it as a silver bullet solution for anonymity and privacy, which is impossible to do by just inserting an USB stick in a machine - does it magically detect hardware keyloggers or compromised firmware?). You can make your own by installing Tails ...


4

One of the reasons that banks often have case insensitivity in their passwords is because of phone banking: banks existed FAR before the internet existed, even before telephones were a thing. So once telephones became widespread, many major banks allowed people to to banking stuff via the telephone. it makes sense: all you need is two account numbers and a ...


8

Typically, it is a choice between usability and security. Users have a surprising amount of trouble with capitals in password so capitalizing password before hashing them makes it easier on the user. Of course, that also decreases the maximum entropy of a password of a given length. To compensate, you should use longer passwords... If you're lot limited to ...


20

The most likely reason is that the backend only supports case-insensitive passwords. To quote OWASP: Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords. The chances of this happening are much higher with stodgy old institutions ...


0

Ok passwords suck. I actually have found more evidence of early password failure than well designed password systems when looking at passwords as an access control method prior to computers. There is unfortunately three methods I have seen to "address" the problem. cost risk analysis: Decide that the risk is small and the cost is large so do nothing ...


1

At first glance, this seems like it might be a good idea. Like many suggestions relating to passwords, in some situations it may even be an OK solution. However, when you consider it in more detail, a number of shortfalls become evident. If I was trying to crack someones password, one of the first things I would do is try to find out as much information ...


1

A couple of sites therefore allow you to log in with e.g. OpenID, Google or Facebook, thereby removing the need for separate credentials. Facebook has also introduced one-time login tokens ("passwords", OTP). Regarding SMS, remember that SMS are clear-text messages that are only protected if the link between your device and the cellular network provider ...


2

Are there any sites which use this approach? This sounds very similar to Yahoo's on-demand passwords. Yahoo announced that in lieu of a standard username-password combination, Yahoo users in the US could log into their accounts with one-time passwords sent to their mobile phones via SMS message. Are there security issues with this approach? ...


3

I think many of your questions (eg SHA-512 vs bcrypt) are answered in the guide linked to by AviD. But it doesn't actually say anything about PHP, so I'll answer that part. Hashing a Password in PHP5 It's good that you want to understand the underlying concepts, but actually securely hashing a password in PHP5 is quite easy: $hashedPassword = ...


0

When selecting the password for the user, you know the entropy, as opposed to placing some restrictions that may prevent them from using a low entropy scheme In order to have the best of both worlds, you could also compute the entropy (or whatever mechanism you deem appropriate) while they type their chosen password. This is the mechanism used on ...


0

Maybe a simple way to proceed with such research would be to use some of the tools normally dedicated to game cheating by analyzing and directly editing the target software memory content. Search for things like "game memory search cheat" on your favorite search engine, and you should find several of them. The programs I'm referring to take a snapshot of ...


7

One respondent touched on the right answer, but didn't expand on it enough, so I will. You are asking the question from a computer- or IT-centric perspective. But why does that IT exist? To serve the customer. Let me repeat this: The customer is not there to serve you, you are there to do what they need you to do. So with that in mind, let's revisit the ...


1

The two main methods that I have considered for this are: 1. User Defined Questions Most of the default questions I see on sites seem to be the same or very similar, easily researchable through social media, etc. I would generally think that allowing users to write their own security questions would be better with some guidance. e.g., "Come up with two ...


3

I don't pick my own passwords. I use a password manager that generates random passwords for me. However, most web sites are based on the idea that users will memorise their passwords. It's much easier for a user to memorize a password they picked themselves, rather than one assigned to them. In practice as well, users typically use the same password on ...


-1

I want to produce a signal such that when a cell phone enters that area, I must get all the specifications of that device. That's not how cell phone signals work. Can I do it? Nope. Which signal is good? I don't think this question has a correct answer.


14

Organisations want users to be responsible. If the user chose the password, they can be blamed for choosing a bad one. Unfortunately, in the real world, organisations may have to be more concerned about seeming to take some of the responsibility for intrusions than about insuring they can't happen. Users want to choose something they can remember Many ...


2

In many situations, the user is expected to be their own security watchdog because the user of the system is not the threat to the system. The threats to the system are administrators and employee-grade operators that by virtue of position have elevated exposure and permissions/rights within the system. Without a seriously flawed system already, James ...


1

Other people have mentioned it before- but I feel that a user is expected to have control over the security of their account. That being said, I do agree that many passwords aren't very strong and should certainly should be checked by a client-side (so we're not sending raw passwords through the network) checker for complexity, and if the password doesn't ...


5

Think about it this way, if you choose the user's password for them, they will forget it, and have to use password reset systems. The 'forgot my password' is usually less secure than the password, so making the password more secure, but causing more password resets makes the entire system less secure as it would be harder to detect fraudulent 'forgot my ...


56

Why, indeed? Allow me to ignore that question for a moment, and answer your implied question: Should we? That is, should we continue to have users create their own password, which is often weak, instead of just having the system generate a strong password for them? Well, I am of the controversial opinion that there is a pretty strong trade-off here - ...


27

Getting the password to the user The only times I have seen systems that set the password for the user, it is send to the user via email (obviously in plaintext), which is obviously a bad idea[*] (and SMS, Mail, etc are not that much better). So that would leave displaying the password when creating the account (which might also be a bad idea because of ...


2

Well Dmitry is right when he says 72 characters is good. If the characters are random enough. (1.78 bits per character). You can use the approach described (security warning that password is "too long"). Or simply limit password length (with security warning). If you expect your users to enter more than 72 characters, you could as well use SHA-512 to ...


0

I wouldn't worry about it. 72 characters is a quite decent password length, and password truncation is a common practice. Your users will trust you with many security options (like hash algorithm and the number of iterations) which affect security much more than password length. Implementing a warning wouldn't hurt though, that is, if you have nothing else ...


1

In modern versions of windows and most *nix distributions you typically run with lower level privileges and then elevate your privileges ("run as" / UAC / sudo / etc.) to do more risky tasks. In some cases there is just a prompt, but a more secure configuration would require the password each time you elevate. If a malicious script or malware runs and want ...


1

The answer to your question depends on the threats you're fighting against. If you're only concern is other people stealing your system, your're fine by using FDE as this prevents them from even getting to the point where they could attack the password. This assumes that your boot-password is strong and you power your machine down often. However, if you ...


1

It's best to use a method that would stay secure even if everyone used it. You'll have less to worry about and it lets you collaborate with others in tweaking the method to be the most secure, because you don't have to keep your methods secret. This "the enemy knows the system" approach is a huge motor for innovation and advancement in information ...


-1

Use Malbolge. After all that's essentially random, right? (=<`#9]~6ZY32Vx/4Rs+0No-&Jk)"Fh}|Bcy?`=*z]Kw%oG4UUS0/@-ejc(:'8dc That's the hello world program.


2

Many email clients protect the password in similar ways to a password manager (and some do not). No flaw in your logic, although once you get malware designed to steal password manager passwords, all bets are off anyway. That's once reason why 2FA is so important. By setting up 2FA, even if malware gets your email password, they cannot use it apart from ...


1

Say you use Diceware you can generate a memorable, secure passphrase. For the technically inclined, each word in your Diceware passphrase yields 12.9 bits of entropy, the way passphrase security is measured. If you want a passphrase to be uncrackable, ever, using today's technology (and the technology of the foreseeable future), you need 128 bits of ...


0

Facing the same issue I ultimately decided to provide the crypto keys via an API, when an application asks for it. This has several advantages and drawbacks: you rely on some kind of containment / limitation. In my case it was IP filetring which was optimal for the architecture we were in. there is the the risk of IP spoofing which needs to be weighted ...


2

To answer your two specific examples: Most Western computer systems don't have fonts with complete coverage of CJK characters, and when they do, the appearance isn't always correct. Having a password displayed to you as a series of boxes isn't particularly useful, and worse, some programs will replace those un-displayable characters with substitutes, ...


0

I gave this answer to another question, but I think it addresses your question as well (in a roundabout way). What is "password strength"? In most people's minds, it's the difficulty factor malicious actors would have when they are trying to guess your password. Password strength meters generally answer a slightly different question: how many iterations ...


1

I realise this is an old thread, but still... This raises the following questions: How is the SRK derived from the password? How is the SRK stored? If the SRK is somehow compromised, how easily can the password be derived from the SRK? It isn't. The SRK is generated by the TPM using an onboard random number generator. The password is ...


18

Like most password generation algorithms, this one relies on security through obscurity. As long as nobody suspects that you use this method, nobody will use a cracking tool which tries random valid source code snippets and the rule of strength = possible_characters ^ number_of_characters will stay valid. But as soon as someone suspects that you might be ...


-2

This is actually a very good idea. You won't find this kind of passwords easely in rainbowtables, and most bruteforce attacks don't include characters like this or search for such long passwords. Its only weakness is the fact that it is a short code (not a short password), if someone knows you have a script as password it could be easy for them to guess. ...


25

You can use source code as password. However I'd strongly recommend against using source code as a passphrase. The reason for this is entropy. Passwords / passwphrases need to provide lots of entropy (100 bits+) and programming languages usually pose severe constraints on the formulation of instruction thus resulting in less entropy per character than even ...


0

Yes, you can encrypt data without a password but I'd strongly recommend against it. You can use OS specific systems like the metioned Keyring or you can use Windows-user-account credentials to derive a key. I'm not sure about this, but this would probably give any other app potential access to your encrypted data. You could also use keyfiles, which are a ...


0

Probably not - you would find many compatibility problems depending on the supported character sets of devices that you may need to enter your password from. There are two ways of making sure you have a strong password: Use a source on entropy that the attacker isn't aware of. Use enough entropy so that brute force is infeasible. The approach your ...


0

Yes, it would be a great idea to use those characters. passw密码rd would probably not be the best example as it is simply two characters away from password, but it would certainly be more secure than password11, p4ssw0rd, or similar permutations. Since these letters are not as convenient on average keyboards, most users will probably not use these characters ...


0

Generally, yes. Some systems may not support or allow non-latin characters. In the backend, the database and other systems need to be setup properly to handle non-latin characters or unexpected things may happen. For example, one multi-bye unicode character may be interpreted as multiple single byte characters (or whatever the expected size is in the ...


0

No. In order to store passwords in an encrypted manner, you need an encryption key. If you don't derive that key from a master password, it means you're storing the key somewhere, and an attacker can retrieve it from that "somewhere". Now, you could store that key (or the passwords themselves) in a platform-specific secure store (such as MacOSX's ...


-2

SHA256 and MD5 are message digest algorithm. You can only encrypt your data using this algorithms. If you want to validate this data then you need to encrypt that data and compare it to validate it. And as you told brute-force is the only way to get that data back and it's too difficult to decode it. If you realy want tha data back then go for AES/DES ...


4

SHA256 and MD5 are hashing algorithms, or "one-way encryption" if you will. A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size (Wikipedia (Hash function)) So to get the (probable*) plaintext that was hashed, brute-force is the only way. There are rainbow tables as well as you mentioned ...


0

I didn't implement such a system. But I can still answer your questions (I hope). A different password for each application is a nice feature to enhance security, so that a broken password won't immediatly give you access to all apps. The problem with logging in with a different password for each application is the amount of passwords. Google has like 10 ...


1

Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X? Yes. The traditional keylogger is a hardware device that intercepts data between the the keyboard and the intake of character data at the Keyboard Controller (mostly USB Device, HID Keyboard). The physical components are few and various tamper evident ...


1

You are saying that the private key cannot be decrypted server-side for authentication (because then the server would need the password), and it also cannot be sent to anybody requesting it, and then decrypted client-side (because then the private key would be vulnerable to an offline brute force attack). Basically, what's left is to design a completely ...



Top 50 recent answers are included