Bitcoin Forum
June 28, 2024, 10:23:07 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: mcx passwords  (Read 4291 times)
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 18, 2013, 05:17:50 PM
 #41

Actually CIYAM Open is a 100% C++ platform (and I would be interested to perhaps compare notes then).

I only store hashed passwords in the DB and don't really understand why you are not doing the same - the *reset* issue is really not the same thing as you can always send a new password (or a unique link for the email recipient) to accomplish this.

Why exactly do you think you should be able to decrypt your user's passwords?


I don't believe in email password resets. I stated this. So unless you have another work-around to resolve people who forget passwords (outside of having them store other data about themselves in recoverable form) then it's pretty easy to understand my position.

https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 18, 2013, 05:20:48 PM
 #42

Unfortunately when a layman such as usahero encounters manual password reset and verification he gets upset that his "used at every site" password is visible to someone like myself. However exchanges which have reset by email (which usahero wanted and thinks is secure) are actually quite insecure.


I know email recovery system has its weaknesses, so this is just another of many of your strawmen arguments. Lets rather focus on the recoverable passwords and the fact you can spy on our passwords?


Yes I can spy on your passwords. If I moved to another piece of information for a user to store instead of passwords I'd be able to spy on that too, or your funds, etc. I'm the admin. Basically if you don't trust an admin to keep your password (or password hash) and other important data to themselves you shouldn't be using that site in my opinion. So what is your point, that an admin has access to data other people don't?

Alternatively you can do what every security expert does, use a unique password at every site so it's irrelevant. Simple isn't it?

https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
August 18, 2013, 05:22:54 PM
 #43

I don't believe in email password resets. I stated this. So unless you have another work-around to resolve people who forget passwords (outside of having them store other data about themselves in recoverable form) then it's pretty easy to understand my position.

I also think that email password resets are a problem (although not so much if you use a GPG sign-up which CIYAM Open offers).

Asking someone to disclose even part of their password insecurely (i.e. via plain email or IM) is of no extra benefit and in fact is just even less secure than asking them to disclose something you sent in an initial email.

Why not also offer 2FA via Google Authenticator (I can give you the necessary code in C++ if you like as CIYAM Open offers this)?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
usahero (OP)
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
August 18, 2013, 05:23:40 PM
 #44

On decent sites, admin would have to use password cracker to see hashed passwords. On your site, you just click the button (or whatever implementation you are using).

So this is my concern, and it doesn't matter if I use the site or I don't use the site. And I can have opinion of the site whether I use it or not.

CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
August 18, 2013, 05:26:13 PM
 #45

On decent sites, admin would have to use password cracker to see hashed passwords.

Actually on CIYAM Open I wouldn't even try to crack your password (as I wouldn't have enough computing power to do so unless you used a very poor password - all I could do is change your password).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
MCXnever
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 18, 2013, 05:29:45 PM
 #46

Unfortunately when a layman such as usahero encounters manual password reset and verification he gets upset that his "used at every site" password is visible to someone like myself. However exchanges which have reset by email (which usahero wanted and thinks is secure) are actually quite insecure.


I know email recovery system has its weaknesses, so this is just another of many of your strawmen arguments. Lets rather focus on the recoverable passwords and the fact you can spy on our passwords?


Yes I can spy on your passwords. If I moved to another piece of information for a user to store instead of passwords I'd be able to spy on that too, or your funds, etc. I'm the admin. Basically if you don't trust an admin to keep your password (or password hash) and other important data to themselves you shouldn't be using that site in my opinion. So what is your point, that an admin has access to data other people don't?

Alternatively you can do what every security expert does, use a unique password at every site so it's irrelevant. Simple isn't it?

Does anyone really trust you? Seriously basic password shit name a major company that uses the RS method to password recovery. Perhaps Google's straw team of support crew can just give it to me. Does it mean I get my password as fast as we get fee shares or the site upgrade on the 10th? Does C++ enable us to trust you more? You sir are a nut job and no WE DONT TRUST YOU.
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 18, 2013, 05:32:44 PM
 #47

I don't believe in email password resets. I stated this. So unless you have another work-around to resolve people who forget passwords (outside of having them store other data about themselves in recoverable form) then it's pretty easy to understand my position.

I also think that email password resets are a problem (although not so much if you use a GPG sign-up which CIYAM Open offers).

Asking someone to disclose even part of their password insecurely (i.e. via plain email or IM) is of no extra benefit and in fact is just even less secure than asking them to disclose something you sent in an initial email.

Why not also offer 2FA via Google Authenticator (I can give you the necessary code in C++ if you like as CIYAM Open offers this)?


Google auth is in the next update already, but thanks for the offer. It's quite easy to implement in c++ which is why I like it.

This isn't about ways to make users more protected from themselves, it's a discussion about how mcxNOW stores some data and the ignorance on why it's irrelevant. People are coming at it like it's a SQL/PHP site when it's completely different and been coded in a way for utmost security.

I don't do email resets at all because even people who don't lose their passwords can be attacked in this way. The few people who do forget their passwords and email me are of course opening themselves up to potential abuse, but they will likely be in the "Loop" quicker than any attacker reading their email and can therefore change it before it's able to be abused. I tell people in my response emails this if usahero wants to share it with the world.

https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
usahero (OP)
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
August 18, 2013, 05:47:36 PM
 #48

You could easily implement algorithm that would disallow you to see plain-texted passwords. You could easily create email recovery system, which you would have to authorize first te be used. So people that didn't lose password could not be attacked via email recovery method, while protecting privacy of people who did lose the password, but with this system they would have to share password details with you.

Its not as much a security concern (if you want to steal from us, you will steal from us anyway), as it is a customer experience issue.



Now you may continue with some strawmen arguments and personal attacks... You are usually very off with assumptions of what I really think. (which shouln't be surprising, as sometimes I am serious and sometimes I just troll for the t of it)
SlyWax
Sr. Member
****
Offline Offline

Activity: 248
Merit: 251



View Profile
August 18, 2013, 05:48:49 PM
Last edit: August 18, 2013, 06:04:04 PM by SlyWax
 #49

So RealSolid, how your system check the user password when he log in ?
He has to send a request to your password server.
So your password server is not off the internet.
He is just not directly on the internet.
So if a hacker compromise you site, he now have internet access to your password server.

Then you say "so what, the password should be unique to my site", but imagine the hacker just retrieve the password list and leave, cleaning all his trace.
Then he could empty the accounts on mcxnow even the cold storage ones.

So maybe there is a median solution here :
- Hash the passwords that are used to authenticate user loging in.
- Store an offline encrypted list of password, so you can do your manual password recovery stuff.

On a side note I agree with you that user have to trust the admin of a site, because whatever he says, he can watch your password if he wants to.
On the other side you could do the javascript hashing on client side and that would prevent the admin to have access to it.
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...
 
mr_random
Legendary
*
Offline Offline

Activity: 1330
Merit: 1001



View Profile
August 18, 2013, 05:50:41 PM
 #50


mcxNOW has no "Remote database", which means everything is incorporated on the one machine which doesn't have internet access. Secondly the reason hashing passwords is a "gold standard" is because everyone uses databases like SQL which have been hacked to death since the internet began. mcxNOW doesn't use these systems, it uses a custom database and the exchange server cannot be accessed on the internet. There is zero code to read passwords on the site which means it is impossible for an internet hacker to obtain passwords. Therefore the only way to get into the system is to be at the datacenter, then to understand the encryption, to reverse the binary, etc. This is beyond ludicrous to suggest it's a more probable event compared to any other system out there.


No it's beyond ludricous to suggest it's not possible there are holes in your security measures outside of a dodgy datacenter. It's laughable you think it's impossible there might be a hole somewhere you haven't thought of. The probability is non-zero, fact.

Multi-billion dollar companies with teams of the best minds in the industry have had their db's compromised by hackers, you're deluded to have your main argument as "welp we can't be hacked anyway LOL".

Meanwhile a typical exchange site that uses SQL can be broken from the internet. Yet if the SQL site uses password hashing it's somehow a "gold standard" compared to mcxNOW? Please. mcxNOW is *THE* standard because every single packet of information is controlled by the code from one person, I know everything that goes on within the exchange. There are no black boxes like others use in their php/sql/asp.net setup.
This is complete fluff in relation to my post. As far as 'gold standard', the SQL site that using password hashing and salting per password is doing a superior job to mcxnow in terms of password storage. Every single packet of information nonsense is simply irrelevant to what we are talking about here. Encrypted passwords could be retrieved in plaintext form by a hacker at your exchange Realsolid, however small the possibility, it's still a possibility. Honestly I'm not wanting to be rude here, but do you not understand this concept?

And email systems are ridiculously insecure. If an email is hacked from ANYWHERE then they can reset your exchange password and steal all your funds. Say you check your email at your mothers house and she has a virus. They log into your email, see you use mtgox and reset password. 24 hours later your account is drained. Your main PC doesn't even have to be compromised and email systems are among the highest compromised websites in existence. Most people probably aren't even aware their emails are hacked.

I addressed this point in my original message in anticipation of you making this weak argument. Yes you could check your email on a computer that has a virus. In the same way you could check your mcxnow account on a computer that has a virus. By extension that makes your own site 'ridiculously insecure'. If you have a keylogger on your machine you think the keylogger will collect the email password but never the mcxnow password? That makes no sense at all.

Your claim that email reset systems aren't insecure if "used properly" is easily extended to using a unique password at every site you use. It's really not that hard and the only reason you shouldn't be doing it is ignorance, not laziness.
The distinction between the two is if you implemented an email reset system properly the onus wouldn't fall on the customer but instead on the person who is responsible for running the exchange.

Just using a unique password would make this a zero probability.  This is such a non issue.

That doesn't make any sense in relation to what I wrote:

Quote
It is therefore a non-zero probability that a hacker could gain everyone's passwords by your poor decision to employ encryption; using hashing+salting would make this a zero probability.

If everyone used a strong, unique password (never going to happen) the hacker gaining access to all those passwords would still be a non-zero probability. I guess what you tried to say is, if everyone used a strong, unique password then it wouldn't matter if a hacker gained access to everyone's passwords - however people do re-use their passwords unfortunately, a good programmer would design for this and use the standard approach of hashing and salting - it's very, very little effort. This is all completely standard, textbook web programming stuff you'll find on any book or lecture on the subject.

Do not confuse me as someone who is claiming the exchange is insecure. I am simply explaining that their password storage procedure is crap.

As a separate note, ethically Realsolid should say on his sign up page that passwords can be decrypted to their plaintext format by the admin and are thus readable by him. Because that is the case here. It will also encourage and explain to users one reason why they have to use a unique, strong password just for mcxnow.


▄▄███████▄▄
▄██████████████▄
▄██████████████████▄
▄████▀▀▀▀███▀▀▀▀█████▄
▄█████████████▄█▀████▄
███████████▄███████████
██████████▄█▀███████████
██████████▀████████████
▀█████▄█▀█████████████▀
▀████▄▄▄▄███▄▄▄▄████▀
▀██████████████████▀
▀███████████████▀
▀▀███████▀▀
.
 MΞTAWIN  THE FIRST WEB3 CASINO   
.
.. PLAY NOW ..
mr_random
Legendary
*
Offline Offline

Activity: 1330
Merit: 1001



View Profile
August 18, 2013, 05:57:36 PM
 #51


Then you say "so what, the password should be unique to my site", but imagine the hacker just retrieve the password list and leave, cleaning all his trace.
The he could empty the accounts on mcxnow even the cold storage ones.


This is a good point. If RS has done things properly the cold storage funds won't be accessible and only the hot wallet would be affected by this. Although until RS realised/accepted that his db had been compromised, the hacker could just keep emptying the hot wallet everytime RS filled it back up.

▄▄███████▄▄
▄██████████████▄
▄██████████████████▄
▄████▀▀▀▀███▀▀▀▀█████▄
▄█████████████▄█▀████▄
███████████▄███████████
██████████▄█▀███████████
██████████▀████████████
▀█████▄█▀█████████████▀
▀████▄▄▄▄███▄▄▄▄████▀
▀██████████████████▀
▀███████████████▀
▀▀███████▀▀
.
 MΞTAWIN  THE FIRST WEB3 CASINO   
.
.. PLAY NOW ..
Shad3dOne
Sr. Member
****
Offline Offline

Activity: 261
Merit: 250


Interesting.....


View Profile WWW
August 18, 2013, 07:23:50 PM
 #52

I find password drama...interesting....

I wonder how bitcointalk.org stores and retrieves our passwords?

Domain for sale -> NXTcoin.com, 200 btc/2.9 M nxt. pm me
like craigslist but for btc! --> Visit BTClist.com
FederationCredits--> C6khbXzADRUeT9di2SpNubCt2UVTuayKMV What's this?
MCXnever
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 18, 2013, 08:48:49 PM
 #53

um hello this thread should never die
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
August 19, 2013, 02:13:33 AM
 #54

Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

On the server side (for storage) the password hash is encrypted with a UUID for salt so that even in the event of the DB being stolen rainbow tables will be of no use.

I wonder how bitcointalk.org stores and retrieves our passwords?

The password is passed in the clear (through SSL of course) to the server side where it is hashed iteratively and compared against the hash in the DB (thus the password cannot be retrieved - only hashes compared).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 19, 2013, 03:54:26 AM
 #55

So RealSolid, how your system check the user password when he log in ?
He has to send a request to your password server.
So your password server is not off the internet.
He is just not directly on the internet.
So if a hacker compromise you site, he now have internet access to your password server.

A comparison of password==password. There is _zero_ code to read passwords and deliver them back to the user on the site. This means an attacker would need to create this code to deliver it back to users. ie In a C++ executable they have never seen it's virtually impossible even if there was a way to insert code (a bug).

Then you say "so what, the password should be unique to my site", but imagine the hacker just retrieve the password list and leave, cleaning all his trace.
Then he could empty the accounts on mcxnow even the cold storage ones.

The mcxNOW database works on a single serve mechanism only. This means there is no code to get "all users". I designed the system on purpose to limit any abuse to a single account, not the system. To abuse a single account you will of course need to know a username and password. To abuse all accounts you will of course need to know all user names and passwords and it is impossible to get this information over the internet because I designed the system and there is no code to do such a thing for a hacker to abuse. Do you understand that for a hacker to abuse something there needs to exist code on the site to do the thing to abuse?

So maybe there is a median solution here :
- Hash the passwords that are used to authenticate user loging in.
- Store an offline encrypted list of password, so you can do your manual password recovery stuff.

On a side note I agree with you that user have to trust the admin of a site, because whatever he says, he can watch your password if he wants to.
On the other side you could do the javascript hashing on client side and that would prevent the admin to have access to it.
Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...
 

The point is there is no difference in my setup whether I hash passwords or don't. There is zero security benefit. Furthermore unlike other exchanges which have weak email password resets I do all password resets manually to protect my users, at the cost of my time. The security at mcxNOW is higher than every other exchange in my (and others) opinion, regardless of what a couple of PHP/SQL laymen think about how secure hashing+salting a password is.

The people here who talk up hashing passwords and in same breath recommend weak email reset systems make me laugh. Most banks keep your passwords in encrypted form, you better stop using your banks too!

https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 19, 2013, 03:56:47 AM
 #56

Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?


https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
MCXnever
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
August 19, 2013, 04:08:53 AM
 #57

Actually I'm wondering why there is no standard way of doing the hashing on the browser side, this could be a enhancement off security world wide...

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?


Yip just checked many banks do email password resets google it. If you don't have the link http://google.com Oh wait Google does email password resets. Let me check another super insecure company http://Amazon.com OMG password resets what is with the insecurity! What my bank doesn't do is give me my password over the phone..... weird I wonder why? I will also note my bank is not C++ and actually delivers on share dividends on time its a crazy concept.

Some use 2FA like most exchanges in crypto offer.... I say most coins-e and MCxnow dont. Pretty sure coinex and cryptsy do as well as every BTC exchange. Email alerts on login? Nope. Email withdraw notification? Nope. I guess these options cant be done in C++ or with your UBER L3EET skills.

But of course the RS is right he has to be speak against him in his little world he bans you belittles you. Then his small army of trolls comes after you. Grow up you little psycho.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
August 19, 2013, 04:30:48 AM
Last edit: August 19, 2013, 04:41:31 AM by CIYAM Open
 #58

Yet you do email resets. While you said you do offer options to "beef that up" the default situation is highly insecure. Please go find a bank that does automatic password resets via email with no other authentication. It's highly insecure yet accepted as ok by some here why?

I currently do not have any automatic email reset at all (have a look for yourself please - my system is open source after all https://github.com/ciyam/ciyam).

I do allow a manual reset (that has to be done myself) which then involves a GPG encrypted email being sent (assuming the user signed up with GPG) or at worst an email with a link to create a new password (the last would only be sent if I am satisfied the reset is genuine which can be done with questions *other* than what they think their password is).

Although using C++ does give some big advantages with regards to security it is still *never* a good idea to store encrypted passwords. You can have things like "password recovery question and answers" (regardless of whether you do resets manually or automatically) that do not need to involve needing to know an end-user's password.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
TheRealSolid
Member
**
Offline Offline

Activity: 94
Merit: 10


Operator of mcxNOW | Programmer of MicroCash


View Profile WWW
August 19, 2013, 04:46:54 AM
 #59

I currently do not have any automatic email reset at all (have a look for yourself please - my system is open source after all https://github.com/ciyam/ciyam). I do allow a manual reset (that has to be done myself) which then involves a GPG encrypted email being sent (assuming the user signed up with GPG) or at worst an email with a link to create a new password (the last would only be sent if I am satisfied the reset is genuine which can be done with questions *other* than what they think their password is).

Sorry I thought you did have auto password resets. Are you planning on adding that? What questions do you ask them? You're aware that if a session is stolen all info a user can grab from the site itself is useless to verify right?

Although using C++ does give some big advantages with regards to security it is still *never* a good idea to store encrypted passwords. You can have things like "password recovery question and answers" (regardless of whether you do resets manually or automatically) that do not need to involve needing to know an end-user's password.

You do realize the fact you store anything "personal" from the user, whether it's password or mothers maiden name, or first pet in recoverable form is pretty much the same? Just a different type of fish my friend.

For some reason some people think keeping personal private details about themselves in recoverable form is somehow more appropriate than a unique password. It's kind of interesting to me but I will probably move to a system like that instead because educating laymen is pretty foolish as we can see in this thread.

When a hacker breaks the database do you want your mothers maiden name, social security number, first pet all in the open too? That's ok but a unique password in the wild is just too insecure? I just don't get some people. Smiley

The first rule is to never get broken into and thats what my system is probably best at doing compared to anything else out there.

https://mcxnow.com - Fast and secure coin exchange.
Primecoin / Litecoin / Mincoin / Worldcoin / CopperLark
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
August 19, 2013, 04:55:24 AM
Last edit: August 19, 2013, 06:16:58 AM by CIYAM Open
 #60

When a hacker breaks the database do you want your mothers maiden name, social security number, first pet all in the open too? That's ok but a unique password in the wild is just too insecure? I just don't get some people. Smiley

As I also stated I encrypt sensitive information in the DB (including the password hashes) - and the key used (along with a UUID salt) is composed of parts that are all separate from the DB (and can include a compiled in UUID, a UUID in a separate file as well as a RAM only portion - meaning that only an uber-hacker who has root access, can decompile and has a memory dump of the running system would have any real chance of working out how to decrypt anything).

The problem is that users often re-use passwords so if someone managed to crack your encryption then they may well be able to do much more damage than just find what is in your DB.

In regards to your question about automatic password resets I have not yet made a decision (for now only manual resets will be possible). I think for GPG users though this would be safer than for others.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!