Duly noted. I was thinking something along the lines of a non-connected workstation with some sort of software or script that prompts the user to input their password (obviously not echoed to the console), hashes it with the common hashes, then tries to break it based on common attack methods and tosses the hash once it's finished. Obviously it would have to be tested to ensure it was tossing the hashes and that it could crack standard passwords relatively quickly (no one is going to stand there for 5 minutes while it cracks their password). Probably not the most practical demonstration considering that last point.
Along these same lines, perhaps a presentation on internet safety would be useful- Danger of common passwords/reusing passwords, trends in password hacking, two-factor authentication, a clear understanding of just who can see your cloud-based data, etc. On Mon, Feb 11, 2013 at 4:55 PM, Lloyd Brown <lloyd_br...@byu.edu> wrote: > As interesting and useful as that sounds, you will want to be very, very > careful with something like this. > > Time for a war story. > > Several years ago, when I was an undergrad, I took a the IT program's > Security class. At the direction of the professor, the TA set up an > access point and faked "BYU Wireless Login" page (this was before we > could whitelist device MACs with OIT). He ran this for a few minutes in > the security lab, during our lab time, which was right before class. > The teacher was out of town, so the TA was running things in class, and > he started asking people in the class if their password was a certain > number of characters long, and started with this letter, ended with that > letter, etc. > > Since we had several full-time employees from OIT, and from other > computer support organizations across campus, this made a number of > people upset. > > In the end, it all worked out. The TA could demonstrate that he'd ONLY > stored the first and last characters, and the total length of the > passwords. The members of the class started being really careful about > checking for the SSL certificate (which the TA didn't spoof). All in > all, it was good lesson learned for everyone, but it made a good number > of them freak out. And when people in a position to make policy > decisions get upset like that, they're prone to overreaction. > > > I'm not saying that it's a bad idea to do something like you're > proposing. I think you could probably design the demonstration to avoid > a lot of these problems, etc. Just be careful, make sure you document > everything, get appropriate approvals, etc. > > > > > > Lloyd Brown > Systems Administrator > Fulton Supercomputing Lab > Brigham Young University > http://marylou.byu.edu > > On 02/11/2013 04:38 PM, Jacob Adams wrote: >> Maybe someone could set up a password cracker in the Wilk and invite >> people to come see how (in)secure their passwords are :) > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
